Microsoft Aurora: a foundation model for the Earth system, packaged as a pip install

The gap Aurora fills: one pretrained backbone for several Earth system tasks

Most machine learning weather models are trained for one variable set on one grid. Aurora is presented as a foundation model: it is first trained generally, then adapted to specialised atmospheric forecasting tasks with relatively little data. The README names four such specialised versions: medium-resolution weather prediction, high-resolution weather prediction, air pollution prediction, and ocean wave prediction. The repository topics line up with that scope, listing atmospheric chemistry, ocean waves and tropical cyclone tracking alongside weather prediction. The intended audience is atmospheric researchers and machine learning practitioners who want a pretrained starting point rather than a training pipeline they have to build from scratch. The README is explicit that the goal in publishing the code is to facilitate reproducibility of the paper and to support further research into foundation models for atmospheric forecasting. That framing matters more than any feature list, because it tells you which questions the maintainers optimised for and which they did not.

How the model is invoked: Batch objects in, Prediction objects out

The public surface shown in the README is small. You construct a model, load a checkpoint, build a Batch, and call forward. The Batch carries four things: surf_vars, static_vars, atmos_vars, and metadata. Surface variables in the example are 2t, 10u, 10v and msl, each shaped as a tensor with a batch dimension, a time dimension of two steps, and a spatial grid. Static variables are lsm, z and slt, with no batch or time dimension because they describe the surface rather than a moment. Atmospheric variables are z, u, v, t and q, and they carry an extra level dimension set to four entries. The metadata object holds latitude, longitude, a timestamp tuple, and the atmospheric levels themselves, given as 100, 250, 500 and 850. That division is the architecture in miniature: the model is told where the grid points are and which pressure levels exist, and it returns a prediction object whose surf_vars dictionary you index by variable name. The example prints prediction.surf_vars["2t"]. Nothing in the README describes the internal network, the training data mixture, or the tokenisation of the grid, so anyone wanting those details has to go to the paper or the documentation site.

Installation and the first run, including the 500 MB download

Two install paths are documented. With pip: pip install microsoft-aurora. With conda or mamba: mamba install microsoft-aurora -c conda-forge. The README then gives a complete runnable snippet using AuroraSmallPretrained, imported from aurora together with Batch and Metadata. You instantiate the model, call model.load_checkpoint(), and the README warns that this will incur a 500 MB download. The example feeds random tensors rather than real data, which makes it a smoke test for the install rather than a forecast. The grid in that snippet is deliberately tiny: 17 latitude points from 90 to -90, and 32 longitude points built with torch.linspace(0, 360, 32 + 1)[:-1], a pattern that drops the duplicated endpoint at 360 degrees. The timestamp is a single datetime, 1 June 2020 at 12:00. For a real run on ERA5, the README points to a full-fledged example page in the documentation rather than reproducing it inline. Treat the snippet as a way to confirm that torch, the package and the checkpoint download all work before you spend time on data preparation.

The limitation the maintainers state themselves: no guarantee of accuracy

The Responsible AI section is unusually direct and is the most useful part of the README for an adoption decision. It states that Aurora is based on neural networks, so there are no strict guarantees that predictions will always be accurate. It goes further: altering the inputs, providing a sample that was not in the training set, or even providing a sample that was in the training set but is simply unlucky may result in arbitrarily poor predictions. It also notes that the model may inherit biases present in any of the training data sets. The out-of-scope list rules out direct operational decision-making without expert review, applications requiring guaranteed forecast accuracy, and non-environmental prediction tasks. The use-of-this-code note says the code has not been developed or tested for non-academic purposes and should only be used as such, at your own risk. There is also a truncated sentence in the supplied README beginning "the models published here are streamlined versi", which suggests the published checkpoints differ from the full research models, but the material does not say how. If that distinction matters to your work, it is the first thing to check in the documentation.

Where Aurora sits next to a numerical weather prediction pipeline

The obvious alternative is a conventional numerical weather prediction system, the kind built on physical equations and data assimilation rather than learned weights. The difference in approach is not subtle. A numerical model integrates the governing equations forward from an analysed initial state, and its behaviour is bounded by known physics plus the quality of that initial state. Aurora instead maps an input Batch to an output Prediction through a network trained on data, which is why the README can say that an unlucky sample may produce arbitrarily poor predictions: there is no physical constraint forcing the output to stay plausible. The trade is speed and adaptability against guarantees. A foundation model can be adapted to a new forecasting task with relatively little task-specific data, which is hard to do with a physics-based system. The README itself frames Aurora as one piece of a weather prediction pipeline and says a series of additional verification tests are needed before it becomes operationally useful. That is a fair description of the boundary. If you need a forecast you can act on without review, this is the wrong tool, and the maintainers say so.

Versions, maintenance and what the licence metadata does not tell you

The release history shows v2.0.0 in July 2026 and v2.0.1 in August 2026, following v1.8.0 in October 2025, with the default branch receiving commits as recently as August 2026. A major version bump between 1.8 and 2.0 means anyone pinned to the 1.x line should read the release notes before upgrading, because the README does not document a migration path or a deprecation policy. There is a CI workflow referenced by a badge, and a CONTRIBUTING.md, so the project accepts outside contributions. On licensing, the repository metadata reports NOASSERTION, which means GitHub could not classify the licence automatically. The README does not restate the terms; it points to LICENSE.txt. For commercial use the README directs you to email AIWeatherClimate@microsoft.com. The supplied material does not contain the licence text, so no claim can be made here about redistribution, modification or commercial terms. Read LICENSE.txt before you build anything on top of this, and treat the commercial contact address as a signal that the terms are not simply permissive.

Adopt, wait, or look elsewhere

Aurora is a reasonable choice if you are an atmospheric researcher who wants a pretrained checkpoint to adapt, or if you need to reproduce results from the Nature paper. The install is one command, the API is a handful of classes, and the documentation site carries a fuller ERA5 example than the README does. It is a poor choice if you need forecasts feeding an automated pipeline, if you need guaranteed accuracy, or if you need a licence you can read off the repository page rather than out of a text file. The first thing to verify is LICENSE.txt, because NOASSERTION in the metadata means the terms are genuinely unresolved until you read them. The second is the note about the published models being streamlined versions, since that affects whether your results will match the paper. The third is whether the four specialised checkpoints cover your variable set at all: the README lists weather at two resolutions, air pollution and ocean waves, and nothing beyond that.

Editorial conclusion

Adopt Aurora if you are doing atmospheric research and want a pretrained checkpoint you can adapt with limited task-specific data, or if you need to reproduce the Nature paper. Do not adopt it for operational decision-making: the README states the code has not been developed or tested for non-academic purposes and that outputs are not meant to be used directly to plan operations. Before you commit, open LICENSE.txt, since the repository metadata reports NOASSERTION and the README only points at that file.

Official sources

1. Issues
2. microsoft/aurora on GitHub
3. Project website
4. README
5. Releases