OlmoEarth v1.1: A more efficient family of Earth observation models

OlmoEarth v1.1: A more efficient family of Earth observation models We released OlmoEarth (v1) in November 2025. Since then, partners have applied it across a wide range of tasks, from tracking mangrove change to classifying drivers of forest loss to producing country-scale crop-type maps in days, scaling deployments to national, continental, and global areas. Every release moves us closer to our mission: bringing state-of-the-art AI to organizations and communities working to protect people and our planet. When OlmoEarth processes satellite imagery to make predictions across tens to hundreds of thousands of square kilometers, efficiency shapes what’s possible. Over the full lifecycle of running OlmoEarth – data export, preprocessing, inference, and post-processing – compute is by far the highest cost. A more efficient model means we can support more partners on the OlmoEarth Platform, and that anyone running OlmoEarth on their own can leverage this technology faster and at lower expense. That’s why we built OlmoEarth v1.1: a new family of models that cuts compute costs by up to 3x while maintaining OlmoEarth v1's performance on a mix of research benchmarks and tasks we’ve constructed with partners. Increasing efficiency by decreasing sequence lengths The OlmoEarth models are transformer-based models, one of the dominant architectures in machine learning today. To process remote sensing data, we first convert it into a sequence of tokens the model can ingest. Two important levers control efficiency in transformer-based models: model size (this is why we release a family of models, so users can pick the size that fits their compute budget) and token sequence length. Compute costs scale quadratically with the token sequence length, so even small reductions can meaningfully cut the cost of running the model. MACs, or multiply-accumulate operations, estimate the computation needed for one model forward pass; lower MACs generally mean cheaper, faster inference. The y-axis is inverted because lower average rank is better. Labels show model family and size. All plotted points use the pasted MAC/rank values. Designing the token This raises an important question for transformer-based remote sensing models: what should a token represent? Take Sentinel-2 imagery, a common modality we process. A Sentinel-2 input will be some tensor with a height and width (H, W representing the latitudinal and longitudinal pixels), a temporal dimension T, and 12 Sentinel-2 channels ([H, W, T, D=12]). Currently, we split the data into resolution-based patches. Concretely, this means that we will pick some spatial patch size p, and split our overall Sentinel-2 image into patches of size p x p: For each patch, we create a token per timestep per resolution. So a Sentinel-2 input with 2 timesteps yields 6 tokens per patch (2 timesteps x 3 resolutions, 10m, 20m, and 60m). In total, a[H, W, T, D=12] Sentinel-2 input will yield H/p x W/p x T x 3 tokens. Using a unique token per resolution is a common technique when processing Sentinel-2 data—Galileo and SatMAE both take this approach, and SatMAE shows significantly better results when doing it. However, it is not universal:…