The real news isn’t just that Microsoft open-sourced the code and checkpoints of its most advanced weather model. It’s that it did so while simultaneously pushing a cloud-first operational model, forcing everyone from research centers to energy utilities into a strategic fork: evaluate Aurora 1.5 locally, bearing the cost and complexity of GPU inference, or rely on Azure’s managed services.

Aurora 1.5 isn’t a single Large Language Model but a foundation system designed for the entire Earth system. Compared to the original Aurora — published in Nature in 2025 after its 2024 debut — this version adds 22 weather variables (bringing the total to 26), ranging from solar radiation and cloud cover to precipitation and humidity fields. Temporal resolution drops to one hour, and, crucially, it introduces one of the community’s most requested features: probabilistic ensemble forecasting, which generates multiple scenarios to quantify uncertainty rather than offering a single deterministic prediction.

On the performance side, Microsoft Research’s numbers are striking. The new ensemble approach outperforms ECMWF’s state-of-the-art dynamical model on 88.9% of evaluated targets and cuts tropical cyclone track error by roughly one-third — a figure made concrete with Hurricane Helene. So far, so good. But the real question is: who can replicate these results without going through Microsoft’s cloud?

The trap of “fully open”

The open-source release on GitHub and the model checkpoints on Hugging Face are genuine, and that shouldn’t be minimized. Yet Aurora 1.5 illustrates how open-source in the foundation model world is becoming a double-edged sword. On one hand, companies like BKW — a Swiss energy utility — are already leveraging the model alongside Microsoft Weather’s operational services to manage renewable generation, which is inherently dependent on weather conditions. Here, ensemble inference is a game-changer: it estimates the probability distribution of wind or solar output rather than a single point figure, reducing risk in dispatch decisions.

On the other hand, ensemble inference multiplies the computational load. Each ensemble member is an additional simulation, and Aurora 1.5 uses stochastic perturbations in the latent conditioning pathway along with autoregressive fine-tuning on high-resolution ECMWF data. This requires GPUs with significant VRAM and an optimized serving pipeline. Unsurprisingly, Microsoft offers native integration with Azure AI Foundry and Planetary Computer Pro, effectively building a smooth path from open research to cloud credit consumption.

Who loses and who wins

For national meteorological centers accustomed to running physics-based models on dedicated supercomputers, the arrival of an open foundation model could be an opportunity to cut operational costs. But it also threatens their gatekeeper role over weather information. If a utility or an agricultural trader can run Aurora 1.5 on their own hardware, perhaps enriched with local data through fine-tuning, the state agency’s added value shifts elsewhere — perhaps toward validation and certification rather than forecast production.

Then there’s the data sovereignty issue. Sectors like agriculture, transport, and emergency planning handle information that many governments consider strategic. Offloading inference to a foreign cloud API — even an hyperscaler’s — can clash with regulatory constraints (think GDPR for geospatial data or national resilience mandates). In this scenario, self-hosting Aurora 1.5 becomes a requirement, not an option. But that demands adequate local compute capacity, and the absence of public hardware benchmarks turns capacity planning into a leap of faith.

Beyond weather: the signal for on-premise deployment

Terradot’s use of Aurora to estimate CO₂ removal via enhanced rock weathering, and the UK Met Office’s exploration of data-driven climate models, signal that Earth system foundation models are expanding well beyond nowcasting. Each new use case brings an implicit question: must inference remain tethered to the cloud, or is local execution required for latency, confidentiality, or total cost of ownership reasons?

The answer isn’t binary, and Microsoft knows it. The company built a multi-layered ecosystem: pure open source for research and independent validation, managed services for smooth operational use, and an integration layer with Azure Agent skills that eases adaptation to new domains. For those evaluating on-premise deployment, the game is TCO: buying and maintaining a dedicated GPU cluster carries a capital cost justified only by very high inference volumes, but if data cannot leave the corporate perimeter, the scales tilt toward self-hosting. Aurora 1.5 doesn’t solve this trade-off — it puts it under a spotlight.