Mistral Timestral Forecasts in 140 ms on CPU. Here's How to Run It in Python

Mistral's new forecasting model has 209M parameters, and Mistral says it forecasts a day of 15-minute data in 140 ms on an 8-thread server CPU. According to the model card, Timestral-209M also tops GIFT-Eval, TIME and fev-bench, ahead of TimesFM-3 and Chronos-2. It's zero-shot, so you don't train anything: hand it a series and you get 21 quantiles back. The question for anyone running Prophet, ARIMA or Chronos today is whether any of that holds up off the vendor's slides, and what the license lets you do with it.

I've spent a few evenings with the model card, the announcement, the repo and the license. Below is what the 140 ms CPU number actually covers and a Python snippet that forecasts a CSV with it. The launch post leaves out two things: Moirai is missing from the comparison, and the license has a $20M revenue clause.

Timestral specs: context length, horizon, size

Timestral was released on October 15, 2026, in four sizes (5M, 28M, 123M, 209M) that share one architecture and training recipe. These numbers are for the 209M checkpoint, taken from the Hugging Face model card and the README:

| Spec | Timestral-209M |
|---|---|
| Architecture | Patch-based transformer, 24 layers, embedding dim 768 |
| Patch size | 32 time steps |
| Max context | 32,768 steps (1,024 patches) |
| Horizon per forward pass | 1,024 steps; longer horizons run block by block, feeding each block's median back in as context |
| Output | 21 quantiles, 0.01 to 0.99 |
| Inputs | Univariate or multivariate targets, past-only and known-future covariates (numeric or categorical), NaN for missing values |
| Weights | 837 MB fp32 |
| Requirements | Python ≥ 3.10, torch ≥ 2.4 |
| License | Code Apache 2.0, weights "Modified MIT" |

Mistral says most of the training data is synthetic. They generated univariate processes with trend, seasonality and noise, then combined them into multivariate series with nonlinear dependencies. Pre-training ran on synthetic data only at context 8192, and post-training used a real/synthetic mix with a 4x longer context. The technical report is still "coming soon."

How Timestral compares with Chronos-2 and TimesFM-3

These numbers are from the model card. Lower is better for MASE and CRPS; higher is better for the fev-bench skill scores.

| Benchmark | Metric | Timestral-209M | t0-gamma | TimesFM-3 | Toto-2.0-2.5B | Chronos-2 |
|---|---|---|---|---|---|---|
| GIFT-Eval | MASE ↓ | 0.658 | 0.661 | 0.667 | 0.696 | 0.698 |
| GIFT-Eval | CRPS ↓ | 0.446 | 0.452 | 0.456 | 0.476 | 0.485 |
| TIME | MASE ↓ | 0.626 | 0.637 | 0.640 | 0.642 | 0.662 |
| TIME | CRPS ↓ | 0.522 | 0.534 | 0.536 | 0.539 | 0.556 |
| fev-bench | SQL skill ↑ | 50.39 | 49.42 | 48.99 | 44.42 | 47.28 |
| fev-bench | MASE skill ↑ | 39.49 | 37.99 | 37.82 | 32.54 | 35.50 |

How I read that table:

On GIFT-Eval MASE, Timestral leads t0-gamma by 0.003 and TimesFM-3 by 0.009. That's within the range where your own data will decide the winner. The margin over Chronos-2 and Toto is bigger and harder to wave away.
Toto-2.0 has 2.5B parameters and finishes behind the 209M model on every row. If you care about inference cost, that's the most useful line in the table.
Moirai isn't in it. The model card doesn't list it and the announcement doesn't mention it. If Moirai is what you run today, you'll have to check the GIFT-Eval leaderboard yourself or run a backtest.
These are all vendor-reported scores. The results were submitted to the GIFT-Eval and TIME leaderboards, and the second issue on the repo, opened the day after launch, is titled "Verify evals on Papers with Code". Until the tech report and independent runs exist, I'd treat "first on all three" as a strong claim that hasn't been checked yet.

The family table is more useful for picking a size. The 123M model scores 0.659 GIFT-Eval MASE against 0.658 for the 209M. Mistral says it's "within 0.2%" of the 209M at about three quarters of the latency. The 28M is about five times faster than the 209M and, per Mistral, already beats Chronos-2 on GIFT-Eval and TIME. If you're forecasting thousands of series every hour, start with the 28M.

Does Timestral really run on a laptop CPU?

The one hard latency number comes from the announcement: on "a standard server CPU with 8 threads," forecasting one day ahead from three weeks of 15-minute history took 10 ms for the 5M model and 140 ms for the 209M. The README says "CPU-friendly: no GPU needed for inference" but gives no memory figures or laptop timings.

So "runs on CPU" is well supported. "Runs on a laptop" means 837 MB of fp32 weights plus activations, which any recent dev machine can hold. Long contexts near 32K steps will cost more than that 140 ms figure, and nobody has published timings for them yet.

Forecast a CSV with Timestral in Python

Install from GitHub (there's no PyPI package mentioned):

bash

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

The API takes NumPy arrays or torch tensors shaped (T,), (B, T) or (B, V, T). It doesn't accept DataFrames yet; issue #1 asks for pandas/Polars support. That means you load the CSV with pandas yourself:

python

import numpy as np
import pandas as pd
import torch
from timestral import TimestralForecaster

# daily_sales.csv: columns "date", "sales"
df = pd.read_csv("daily_sales.csv", parse_dates=["date"]).set_index("date")
series = df["sales"].asfreq("D")  # regular grid; gaps become NaN, which Timestral treats as missing

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

forecast = model.forecast(series.to_numpy(dtype=np.float64, copy=True), prediction_length=28)

median = np.asarray(forecast.median).squeeze()
lower = np.asarray(forecast.quantile(0.1)).squeeze()
upper = np.asarray(forecast.quantile(0.9)).squeeze()

future_idx = pd.date_range(series.index[-1] + pd.Timedelta(days=1), periods=28, freq="D")
out = pd.DataFrame({"p10": lower, "p50": median, "p90": upper}, index=future_idx)
print(out.head())

The script picks the CPU when there's no CUDA device, and asfreq("D") turns any skipped dates into NaN so the model sees them as missing rather than as a shorter series. The copy=True is there because recent pandas can hand back a read-only array, and PyTorch warns about that when it wraps it in a tensor.

Everything Timestral-specific in that snippet (from_pretrained, forecast, .median, .quantile(), NaN for missing values) comes from the model card and README. The squeeze() calls are there because the README documents median and quantile(q) as shape (B, V, horizon), so even a 1-D input comes back with batch and variate axes.

A few more things from the README you'll want in production:

Run it offline: from_pretrained accepts revision= to pin a commit and local_files_only=True (or HF_HUB_OFFLINE=1) to read from cache. Do this in CI and in containers.
Covariates: past_covariates has shape (B, C_past, T). known_covariates has shape (B, C_known, T + horizon) and covers things like promotions, holidays or production schedules. Categorical codes go into categorical_known_covariates (the README suggests pandas.factorize).
Context is capped at 32,768 steps and the most recent ones are kept, so you can pass the whole history without trimming it yourself.

The Timestral license has a $20M revenue cap

The weights use a "Modified MIT" license. It keeps the MIT permissions and adds one condition: you lose the rights if your company's (or your employer's) global consolidated monthly revenue was over $20 million in the preceding month. Above that line you need a commercial license from Mistral or have to use its hosted services, and the restriction carries over to derivatives and fine-tunes, including ones made by third parties.

For a startup or a side project this doesn't matter. If you're a contractor building forecasting for a large retailer, it does. Read the license before you ship this inside a client's stack. The repo code is Apache 2.0, but the code isn't the part that produces the forecasts.

Should you replace Prophet with Timestral?

I wouldn't replace anything yet. I'd add Timestral as a challenger. Take a year of your own metrics and backtest Timestral-28M and 209M against whatever you run now, on rolling windows, using MASE and pinball loss. If it wins, you've dropped per-series tuning, and that's where most of the cost of a Prophet or ARIMA setup goes. If it loses on your two most important series, you've learned that in an afternoon instead of in production.

Two signs I'd watch before trusting it with alerts: the tech report and independent leaderboard runs. Neither exists yet, and the model is days old.

Would you trust a zero-shot foundation model over a tuned Prophet or ARIMA for your production metrics? If you've already backtested Chronos or TimesFM against your own data, tell me which one won and by how much. I'm especially interested in the cases where the boring model won.