HRRR weather model explained (for weather prediction markets)
▲ 6 r/PredictionSignal+2 crossposts

HRRR weather model explained (for weather prediction markets)

You've probably trading weather markets on Kalshi or Polymarket, for example, Los Angeles will reach 77°F today by checking a weather app, noting the temperature figure, and then making the trade on that basis. That's entirely reasonable since that's what everybody else does.

However, that figure didn't just show up out of nowhere; it is the end result of a lengthy sequence of numerical modelling and statistical adjustments, and most of the people trading on it have never examined the chain itself. In fact, it is precisely within that chain that the advantage lies.

>The HRRR (High-Resolution Rapid Refresh) is the convection-allowing model that NOAA uses, with a grid spacing of 3km extending over the continental United States. Since the larger global models (GFS, ECMWF) have a grid that is too coarse to depict thunderstorms accurately, they have to simulate them by means of cumulus parameterization.

The HRRR's grid, however, is fine-grained enough to eliminate the need for such simulation and instead carries out the convection directly. Because of this, it is the model that people actually pay attention to, even if they aren't aware of its name.

HRRR doesn't have a single forecast range; it has two, and the one you receive depends on the cycle in question. It is carried out every hour, 24 times each day.

Twenty of these hourly runs (01Z, 02Z, 03Z, and so on) only extend the forecast to 18 hours in the future, but four of them — at 00Z, 06Z, 12Z, and 18Z — operate in an extended mode that covers 48 hours.

The farther away from the actual time of the forecast you are, the more that run will be making guesses rather than carrying out observations. It's worth bearing in mind before you place too much trust in a 00Z run's view of tomorrow at 3 p.m.

Many model-based strategies are not actually responding to the forecast itself, but rather to the moment when a new run is released.

For example, if the 04Z cycle completes its calculations at approximately 05:21 UTC, the price remains unchanged as long as the market didn't notice anything new, and then it jumps immediately once the new run's data appears: whatever that may be, such as a revised Tmax, a bias correction, or a different call regarding cloud timing.

https://preview.redd.it/1rtw7q3t7djh1.png?width=1566&format=png&auto=webp&s=cfa06d96a9fa2cc0a8a83217688f8aff7fa6175d

and in UTC the same chart:

https://preview.redd.it/53i2vdrb8djh1.png?width=1603&format=png&auto=webp&s=cbc093845422c8a4c2757d7aa6f8069b4669f900

Two traders may be looking at the same forecast (which has been correctly adjusted) and yet end up with entirely different outcomes simply because one of them found out a few minutes earlier.

In a market where many people check the API or continually refresh the dashboard, the advantage of knowing the figure before everyone else goes beyond simply knowing it.

That's why repricing happens and why it's important to receive weather model calculations as soon as possible - it may provide you with a better entry price.

u/SeaSeason4698 — 7 days ago

Would a "model run just landed, here's the min/max for your city" alert be useful for weather market bots?

If you trade the daily high/low temperature markets on Polymarket or Kalshi, you already know the annoying part isn't finding a forecast — it's finding the right one for the station that actually resolves the market, and knowing when a new run just dropped.

We've been building out a catalog of the weather models that matter for this: NOAA's HRRR/GFS/NBM, ECMWF's IFS/AIFS, DWD ICON, Météo-France AROME/ARPEGE, UKMO, JMA, KMA, CMC, BOM, plus the newer AI-based ones (Google WeatherNext, ECMWF's AIFS).

For each one we track coverage area, resolution, forecast horizon, run frequency/schedule, and which airport stations it lines up best with for the US/global cities that show up on the prediction markets.

Question for anyone actually running bots against these markets: would it be useful to get a push/webhook the moment a model run finishes, with the min/max temp forecast already computed for your city — instead of pulling the raw grib/API output yourself and doing the extraction?

Basically "HRRR 18z just landed, KAUS forecast high is X, low is Y" seconds after the run completes, rather than polling.

Curious whether that's a real pain point for people or whether everyone's already got their own pipeline for it. Also open to "you're solving the wrong problem, the actual bottleneck is Y" type answers.

reddit.com
u/SeaSeason4698 — 19 days ago

Why weather market prices move even when nothing new is observed (model publication lag, explained)

If you trade weather markets (Kalshi, Polymarket, etc.), you've probably seen a temperature bucket's probability jump or crash with no new METAR and no obvious news. Here's the mechanism that's usually behind it.

https://preview.redd.it/opfarnbrqzeh1.png?width=1428&format=png&auto=webp&s=54ad94ece4c317b036492b6a0ddb30d288c3052d

Days out from resolution, forecast models have the edge — live obs only tell you now, models tell you where pressure systems, air masses, and precip are heading.

As resolution gets closer, that edge flips: fresh observations start describing the outcome directly, and the model's weight should drop.

The part most people miss: run time ≠ publication time

A model's labeled run time isn't when you actually get it. A GFS run stamped 12Z represents the atmosphere at 12:00 UTC, but it typically isn't usable until ~15:30–17:00 UTC. By the time it reaches you, the snapshot it's built on is already hours stale.

Rough cheat sheet:

Model Coverage Runs (UTC) Usable after Max age before replacement
HRRR CONUS, 3km Hourly ~50–90 min ~2h
RAP N. America, 13km Hourly ~1–2h ~3h
NAM N. America, 12km 00/06/12/18 ~2.5–4h ~8–10h
GFS Global, 13km 00/06/12/18 ~3.5–5h ~9.5–11h
GEFS Global ensemble 00/06/12/18 ~4–6h ~10–12h
ICON-D2 Germany, ~2km Every 3h ~2–3h ~5–6h
ICON-EU Europe, ~7km 00/06/12/18 ~3–4h ~9–10h
ICON Global Global, ~13km 00/06/12/18 ~4–5h ~10–11h
ECMWF IFS Open Global, 0.25° 00/06/12/18 ~7h ~13h
ECMWF AIFS Global AI forecast 00/06/12/18 several hours varies by delivery
GDPS Global, ~15km 00/12 ~5–7h ~17–19h
GEPS Global ensemble 00/12 ~6–8h ~18–20h
ARPEGE Global/Europe 00/06/12/18 several hours varies by API
AROME France and nearby Multiple daily runs ~2–4h depends on run frequency
UKMO Global Global, ~10km Every 6h several hours varies by DataHub
METAR/SPECI Airport obs Every 30–60 min within minutes ~30–60 min

Third-party APIs and mirrors add even more delay on top of this.

Runs also publish progressively, not all at once

init → first forecast hours → short-term horizon → more hours → full run available

This staggered release is a big source of "why did the market just move" moments. Example:

  • Previous run: max temp 24.2°C
  • New run: max temp 22.8°C

Once traders/bots ingest the update: 24°C probability drops, 22–23°C probability rises. It looks sudden because a lot of participants pull the same run in a short window — but the market didn't move on its own, people (and bots) reacted to a recalculated forecast.

Caveat: not every move is a model. Big trades, a fresh METAR, surprise cloud/precip, order book shifts can all produce the same chart shape. But if a bucket moves right around a known publication window, a newly completed model run is the strongest candidate.

TL;DR: models are your best tool far from resolution — but track publication time, not run time, and expect stepped, not smooth, forecast updates. Weight models down as observations start speaking for themselves.

Disclaimer: I work on METAR.ws — we push METAR observations and model data over WebSocket with minimal latency, built specifically for weather-market trading bots. Open beta is running now.

reddit.com
u/SeaSeason4698 — 29 days ago
▲ 18 r/PredictionTrading+1 crossposts

Three data sources every weather trading bot needs (and what each one actually does)

For Polymarket/Kalshi/Coinbase weather prediction markets with hourly-based METAR reports (Buenos Aires, São Paulo, etc), you need three layers:

1. Model forecast — pre-positioning
GFS via Open-Meteo is the free baseline. Use it before the day starts to estimate which bucket is most probable. Limitation: 13km resolution misses localized fog and boundary-layer events.

Always check if there is a more precise local model, usually provided by the national meteorological service.

Example:

For Argentina, SMN runs WRF-ARW v4.0 at 4 km resolution, with 45 vertical levels and up to 72h lead time, freely available as NetCDF on AWS. For SAEZ this is often more useful than raw GFS because it resolves the local boundary layer and regional terrain/coastal setup better.

2. Nowcast API — intraday trend
Between hourly METAR reports, there's a 59-minute window with no new official data. Commercial APIs like AccuWeather can fill part of that gap, but don’t assume a fixed hourly cadence. Treat their observation time as the source of truth: sometimes the current-condition value updates near the top of the hour, sometimes later, and in some locations it may be a blend/modelled current condition rather than the exact settlement station. The value is directional, not authoritative.

This is not the settlement source. Its value is directional: is temperature rising or falling? Is it tracking with the model or diverging? A 5°C gap between the nowcast and the GFS trajectory at 10:55 is a strong signal that something the model missed is happening at the surface.

Use the nowcast for: intraday divergence detection, especially fog, low cloud, or sea-breeze events.

3. METAR reports
The only layer that actually closes the contract. Integer °C at the scheduled reporting minute.

Real example: June 6 at SAEZ. For the 34.79S, 58.52W grid point, SMN WRF F017 from the 00Z run had its maximum at 17:00 UTC / 14:00 ART. GFS was around 19.3°C, while nowcast signals showed fog/low cloud and much cooler surface temperatures earlier in the day. METAR later reported 17°C at 15:00. The edge was not “nowcast replaces METAR”; it was that layers 2 and 3 showed the model trajectory was off well before settlement.

Side note: I'm building METAR.ws — WebSocket push delivery for METAR/SPECI. Still in beta, waitlist open if anyone's interested.

u/SeaSeason4698 — 3 months ago
▲ 7 r/Polymarket_Traders+1 crossposts

Built a WebSocket push service for METAR weather data — looking for beta testers who trade weather markets

Hey, I'm building METAR.ws — a WebSocket API that pushes airport weather observations (METAR/SPECI) straight to your bot. Instead of polling NOAA or scraping aviation portals, you subscribe to a station and get a push when a new report drops.

Targeting people building bots on weather-adjacent markets (temperature buckets, flight category, visibility, etc. on Polymarket/Kalshi).

Still early — no pricing yet, just trying to validate whether this saves time for people actually trading these markets. If that's you, I'd love feedback!

u/SeaSeason4698 — 3 months ago