Forecast users should take the feeds instead of running the model
WeatherNext contains the code and model guides for WeatherNext 2, WeatherNext Cyclones, GraphCast, and GenCast. The current family produces global, medium-range atmospheric forecasts, while cyclone variants add tracking workflows. Google publishes daily model outputs through Google Cloud, Earth Engine, BigQuery, Vertex AI, WeatherLab, and Open-Meteo. An application that needs forecast values can avoid weights, accelerators, weather-data preparation, and autoregressive rollouts by using one of those feeds.
Researchers get 4 operational WeatherNext 2 weight files trained through 2024, several cyclone checkpoints tied to prior seasons, and lighter Mini variants at 1-degree resolution. The main models operate at 0.25-degree resolution, roughly 30 km. The repository warns that Mini is not expected to match the larger versions. That makes the smaller checkpoint useful for learning the pipeline, but a Mini run should not be presented as reproducing operational results.
Full WeatherNext 2 inference expects TPU or H100 memory
The recommended environment is TPU because the implementation is optimized for it. The Colab notebook defaults to WeatherNext Cyclones Mini on a free v5e-1 runtime. Larger checkpoints need a v5p accelerator there. On GPU, users must switch the attention implementation, and the README says non-Mini models require an H100 for enough VRAM. Mini should manage inference on a P100. That hardware line rules out casual use on many laptops and CPU servers.
Running the model also requires weights from a Google Cloud bucket and initial atmospheric state such as HRES conditions. Full training uses ERA5, best accessed in Zarr form through WeatherBench2, while operational fine-tuning data comes from its HRES collection. The 886 MB environment from our install contains neither those datasets nor accelerator capacity. Data is governed by separate terms, including ECMWF and Copernicus conditions, which need review before redistribution or production use.
What happened when we ran it
Our fresh Debian sandbox installed commit 9c034db in 167 seconds, adding 91 Python packages and consuming 886 MB. The repository itself was 9.5 MB with 94 files and roughly 22,432 lines of source. The build then completed successfully in 6 seconds. That is a heavy environment around a relatively small checkout, which is expected for JAX, scientific data, and model tooling but still matters on ephemeral machines.
No test script or target was available, so our harness skipped tests. Pip-audit reported 0 known vulnerabilities among the installed packages. The scan found 0 CI workflow files, no Dockerfile, and no tests directory. Those are concrete limits on what this run verified: package installation and build worked, but we did not execute a forecast, load a checkpoint, compare output, or confirm behavior on TPU or GPU.
A successful 6-second build says nothing about forecast skill
Weather prediction quality depends on checkpoint, initialization data, lead time, variable, region, and evaluation method. Our build did not reproduce claims in the papers or blogs, and the lab block contains no model benchmark. The right local acceptance test is a dated forecast initialized from known data, compared with a reference dataset using a declared metric. Cyclone track evaluation needs its own rules and should not be inferred from a temperature or geopotential result.
The absence of a test target also makes environment drift more expensive. Open issues 212 and 213 document GraphCast notebook breaks after xarray 2026.4.0 changed timedelta decoding and dataset construction behavior. Issue 215 reports a dependency conflict in a demo install. These reports concern older model paths rather than proof that WeatherNext 2 is broken, but they show why the README advises pinning a release and why notebooks need reproducible dependency versions.
Version 0.3.0 is research code with explicit limits
Release v0.3.0 was published August 6, 2026 and added WeatherNext 2 support. The README says APIs may change without notice, calls the repository an experimental research project, and states that it is not an officially supported Google product. Code and notebooks use Apache 2.0, while other materials use CC BY 4.0. Training data and third-party inputs retain their own terms, so the repository license is not the whole data-usage answer.
GitHub showed 7,596 stars, 77 open issues and pull requests combined, and a last push on August 11, 2026. The issue queue includes detailed model questions and environment failures, but the combined count is not a defect count. Activity near the v0.3.0 release is a better health signal than older GraphCast notebook reports alone. Still, users should expect research-level support and perform their own pinning, verification, and scientific review.
Official warnings remain the decision source
The README says the models were not produced with or endorsed by a government meteorological agency and do not replace official alerts, warnings, or notices. That is the most important product boundary on the page. WeatherNext output can support research, comparisons, and downstream experiments; it should not become the sole trigger for evacuation, navigation, emergency response, or other safety decisions. Published feeds do not remove that responsibility.
WeatherNext is a strong repository for researchers who want the actual family code and can supply accelerators, weights, and weather data. Our 167-second install and missing test target make it a poor impulse dependency for a normal application. Use the direct feeds when forecasts are an input to software. Use the repository when model behavior itself is the subject, and keep official meteorological guidance above every generated result.