Mistral's Timestral tops time-series forecasting, but its license shuts out big companies

At 209 million parameters, a model that runs on a CPU now tops, by Mistral's own published results, all three public time-series forecasting leaderboards: GIFT-Eval, TIME and fev-bench. It's Timestral, Mistral's first family of forecasting models, released in October 2026 with weights on Hugging Face and inference code under Apache 2.0. If your day is spent staring at CPU, latency and queue-depth graphs, it's a serious contender to replace the trusty predict_linear in capacity planning. The catch is the license: it shuts out any company making more than $20 million a month.

01What Timestral brings

There are four models sharing one architecture and training recipe: 5M, 28M, 123M and 209M parameters. All of them forecast zero-shot, meaning no training on your data: you hand over the history and get a forecast back.

Under the hood it's a transformer working on 32-step patches, with attention both along time and across variates. Two details matter for production. First, it doesn't return a single number but a distribution: 21 non-crossing quantiles, so the 1%–99% band comes straight out of the model. Second, covariates only see the future if you declare them as "known": a deployment or campaign calendar can condition the forecast without the model trying to predict it.

The gap between sizes is small. On GIFT-Eval, MASE (mean absolute scaled error, lower is better) goes from 0.705 for the 5M model to 0.678 for 28M and 0.658 for 209M. The 123M model lands at 0.659, practically matching the largest one with about 40% fewer parameters.

02How to try it

The package depends only on PyTorch, NumPy, safetensors and huggingface_hub. The README install needs Python 3.10+ and torch 2.4+:

pip install git+https://github.com/mistralai/timestral.git

Or, to use the versions pinned in its uv.lock:

git clone https://github.com/mistralai/timestral.git && cd timestral
uv sync --frozen
source .venv/bin/activate

The minimal call loads the model from Hugging Face and asks for a 96-step forecast:

import numpy as np
import torch
from timestral import TimestralForecaster

model = TimestralForecaster.from_pretrained(
    "mistralai/Timestral-209M",
    device="cuda" if torch.cuda.is_available() else "cpu",
)

context = np.random.default_rng(42).standard_normal(1000).cumsum()
forecast = model.forecast(context, prediction_length=96)

median = forecast.median
lower, upper = forecast.quantile(0.1), forecast.quantile(0.9)

For many series at once, the context is a (series, variates, time) array and gaps are marked with NaN, which is exactly what metrics with missed scrapes look like.

03Timestral vs Chronos-2 and TimesFM 3.0

The two industry references are Amazon's Chronos-2 and Google's TimesFM 3.0. Mistral publishes the head-to-head numbers on its model card; license and context figures come from each model's own card:

Against TimesFM 3.0 the accuracy edge is marginal (1.3% lower MASE on GIFT-Eval), but Google's license rules out any commercial use, so for most teams it isn't a production option anyway. The comparison that really matters is Chronos-2: Timestral cuts GIFT-Eval error by 5.7% and accepts four times as much history. With hourly data that shows: 8,192 hours is about 11 months, while 32,768 covers more than three and a half years of seasonality.

Chronos-2 still has two things going for it. Its Apache 2.0 license comes with no strings attached, and it's integrated into AutoGluon. Timestral has only just shipped and its technical report is still listed as "coming soon".

04Where it fits for an SRE team

Today, capacity forecasting usually means a linear regression over the last few weeks or fixed threshold rules. A zero-shot model with quantiles changes two things.

In capacity planning, the question shifts from "when do I hit 85% CPU?" to "how likely am I to hit it next week?". If the 0.99 quantile crosses the threshold, you have time to scale ahead; if even the 0.9 quantile stays well clear, you can hold off on buying reserved capacity.

In anomaly detection, the band between the 0.01 and 0.99 quantiles works as a dynamic threshold that already bakes in daily and weekly seasonality, with no hand-tuned rule per service. Add known-future covariates and a spike you expected from a campaign or a month-end close no longer pages anyone.

The small models make it practical to run as a periodic CPU job across hundreds of series, without asking the platform team for a GPU.

05The fine print: the license

This is the caveat that matters. The timestral package code is Apache 2.0, but the weights ship under a "Modified MIT License" with one extra condition: you may not exercise any rights under it if your company's (or your employer's) consolidated monthly revenue exceeded $20 million in the previous month. That's roughly $240 million a year, and the restriction also covers derivatives and versions published by third parties. Above that line, the options are asking Mistral for a commercial license or using its hosted services.

For a startup or a mid-sized company it's effectively a permissive license. For an engineer at a large company, even trying it on a laptop with production metrics is a use the license doesn't cover.

06Verdict

If your company sits below the revenue cap, Timestral is the best open option for forecasting metrics right now: more accurate than Chronos-2, with far more history and sizes that fit in a CPU job. I'd start with the 123M model, which performs almost exactly like the largest one.

If you're above it, Chronos-2 remains the default: 5.7% more error on GIFT-Eval is a fair price for an Apache 2.0 license with no conditions. TimesFM 3.0, being non-commercial, stays in the research lab.

07Sources

• Timestral-209M model card (Mistral AI, Hugging Face)
• Timestral weights license (Mistral AI)
• mistralai/timestral (GitHub)
• Chronos-2 model card (Amazon, Hugging Face)
• TimesFM 3.0 model card (Google, Hugging Face)