Three Models, Three Different Answers
Pull a forecast from a weather API and compare it to what the National Weather Service is showing — if the numbers don’t match, the model underneath is usually why. HRRR, NAM, and GFS are all running in production right now, ingested and processed in most serious weather data pipelines, including ours. They don’t agree with each other, and they’re not supposed to. They’re solving different problems.
Knowing which model is doing the heavy lifting for a given request changes how much you should trust the output — and what you should tell your users when the forecast is genuinely uncertain.
GFS: The Workhorse for Long-Range, Global Coverage
The Global Forecast System, run by NOAA/NCEP, operates on a roughly 13km horizontal grid and produces forecasts out to 16 days (384 hours), updated four times daily at 00Z, 06Z, 12Z, and 18Z. Because it’s global, it’s the only realistic option for locations without dense local observational networks — mid-ocean coordinates, Central Africa, the middle of the South Pacific.
That 13km grid is also the ceiling on its spatial precision. A 13km grid cell covers roughly 170 square kilometers. If your app is trying to differentiate weather between two neighborhoods on opposite sides of a ridge, GFS physically cannot resolve that — the model doesn’t know the ridge is there in any meaningful detail.
GFS is also what most pipelines default to beyond 48 hours, because HRRR only runs to 18 hours (48 on its extended runs) and NAM caps at 84. For day 4+ forecasts, GFS is often all you have.
The honest caveat: skill degrades sharply after day 7. NOAA’s own verification statistics show anomaly correlation dropping significantly in the day 8–10 window. If you’re surfacing a 14-day forecast, the back half should carry a very wide implied confidence interval — whether or not you expose that explicitly in your UI.
NAM: The Regional Middle Ground
The North American Mesoscale model runs on a 12km grid for its parent domain, with a 3km nest for CONUS, out to 84 hours, updated four times daily. NAM is better than GFS at capturing mesoscale features — sea breezes, orographic lift, lake-effect snow bands — because it’s tuned specifically for North America and its resolution can actually represent terrain rather than averaging it away.
For construction scheduling, event planning, or agriculture use cases needing a 2–3 day window with real spatial specificity, NAM is usually the better call over GFS. The 3km CONUS nest picks up elevation gradients that GFS smears. That matters in the Appalachians, the Colorado Rockies, or anywhere along the Pacific coast where marine layer behavior changes quickly over short distances.
NAM’s weakness: it accumulates error over its 84-hour run faster than GFS does over the same window. Higher-resolution models amplify small initialization errors — that’s the mechanism, not a bug you can patch out. So in the 60–84 hour range, NAM and GFS often diverge, and NAM isn’t automatically the winner just because it’s finer-grained. Resolution and accuracy are not the same thing.
HRRR: High Resolution, Short Window, Convective Detail
The High-Resolution Rapid Refresh model runs at 3km resolution across CONUS, updating every hour, with forecasts out to 18 hours (48 hours for the extended run, issued four times daily). It’s the only operational model that re-initializes its boundary conditions every hour from fresh surface observations and radar — which is what makes it genuinely better than NAM or GFS for short-range convective forecasting, not just nominally higher-res.
At 3km, the model can actually represent individual thunderstorm cells, convective initiation near terrain features, and the timing of storm passage in ways that 12–13km models can’t. If someone is asking whether it will rain in the next three hours at a specific location, HRRR is the model you want powering that answer.
Our GRIB2 ingestion pipeline processes HRRR output across tens of thousands of locations, and the hourly update cycle is the hardest part to operationalize in practice. You’re continuously ingesting new model runs while serving requests from the most recent complete run — the overlap logic and staleness handling requires real care. The payoff is real, though: for sub-6-hour precipitation timing, HRRR outperforms both NAM and GFS by a meaningful margin, particularly in summer convective season across the Great Plains and Southeast US.
The hard constraint is geography. HRRR covers CONUS plus parts of Alaska. If your users are in Europe, Australia, or anywhere outside that footprint, HRRR doesn’t exist for them — you’re back to GFS or regional models like ECMWF’s HRES.
ECMWF: The Benchmark Everyone Compares Against
Worth naming separately because it’s not NOAA-operated and its full-resolution output isn’t freely available the way GFS, NAM, and HRRR are. The European Centre for Medium-Range Weather Forecasts runs their IFS at roughly 9km globally, and by independent verification it consistently outperforms GFS in medium-range skill, particularly in the 5–10 day window. The Copernicus ERA5 reanalysis product is publicly available for historical work, but real-time IFS data at meaningful resolution costs money.
We ingest ECMWF output as part of our pipeline. For global medium-range forecasts, it’s the best single model available — but “best” means probabilistically better on average, not always right. No deterministic model is.
What This Means in Practice
When you build on top of a weather API, you inherit whatever model-blending or selection logic sits underneath. That’s worth understanding explicitly rather than treating the forecast as a black box. A few concrete implications:
- Short-range hyperlocal forecasts (0–6 hours, CONUS): You want HRRR underneath. If the API doesn’t confirm it’s using HRRR for this window, the precipitation timing is probably softer than it needs to be.
- 2–3 day regional forecasts, North America: NAM’s 3km nest is the right tool, especially near terrain or coastlines. GFS at 13km will miss mesoscale features.
- Beyond day 5, or anywhere global: GFS or ECMWF. Skill is genuinely degraded — don’t surface “82% chance of rain” for day 9, because that precision isn’t real.
- Aviation use cases: HRRR for CONUS terminal weather, GFS or ECMWF for route planning at cruise altitude and long-haul international legs. NAM’s 3km output is useful for convective avoidance planning in the 24–48 hour window.
The Blending Problem
Most production weather APIs don’t serve raw model output — they blend model output with observations, apply bias corrections, and sometimes weight multiple models together. That’s generally a good thing; it produces better-calibrated output than any single model alone. But it also shifts the question from “which model should I trust” to “which blend approach is this API using and how transparent are they about it.”
We apply bias corrections and composite scoring across data sources rather than serving a single model’s raw output. That adds accuracy in normal conditions. It also means our output isn’t directly comparable to a raw GFS or HRRR GRIB2 file — if you’re trying to replicate our numbers for verification, that’s the first thing to account for.
One Practical Starting Point
If you’re building a new integration and aren’t sure which time horizon matters most, pull forecast data for a location with known terrain variability — Denver, or the eastern slope of the Cascades near Seattle — and compare the API output against NOAA’s model viewer for the same point at the same valid time. The gaps you see will tell you more about what’s happening underneath than any documentation will.