Mistral Timestral Tutorial: Zero-Shot Forecasting on a CPU in Python

Mistral's Timestral is a family of four time-series forecasting models, 5M, 28M, 123M, and 209M parameters, that predict future values in a numeric series without a GPU. Mistral says the smallest one answers in about 10 milliseconds on a standard CPU. It shipped on October 15, 2026, and it's the company's first model built for forecasting instead of chat. Here's how to install it, run it in Python, and what the benchmarks (and the license) actually say once you read past the headline.

What Is Timestral, Exactly?

Timestral isn't an LLM repurposed to spit out numbers. It's a patch-based transformer built specifically for numeric sequences: 8 layers, a 192-dimensional embedding, patches of 32 time steps at a time. You feed it a window of history, up to 32,768 time steps, and it returns a probabilistic forecast: a median path plus 21 quantiles (0.01 to 0.99) describing how confident the model is at each point.

That quantile output is the part that actually matters if you'd ship this. A single predicted number is a guess. A quantile spread tells you how much to trust it, and whether your 95th-percentile case is "fine" or "call someone."

The model also takes covariates, past-only and known-future, numeric or categorical. That's the feature separating it from a toy forecasting demo: you can hand it "this is a holiday" or "promotion starts tomorrow" as a known-future flag, and the forecast actually conditions on it instead of pretending the series is random noise. Missing values go in as plain NaN, no imputation step required first.

Mistral hasn't been shy about efficiency plays this year. Its distribution deal with Microsoft (see our breakdown of the Microsoft-Mistral partnership) was about getting models in front of enterprise customers. Timestral feels like the other half of that story: a specific, boring, extremely common enterprise problem, solved with a model small enough to run on hardware those customers already own.

How Fast Is It on a CPU, Really?

This is the headline claim, so it's the one worth checking before anything else. Mistral's own numbers, for a one-day-ahead forecast from three weeks of 15-minute readings, on a standard 8-thread server CPU:

Mistral only published latency for the smallest and largest model, so treat 28M and 123M as "somewhere in between" until you benchmark them on your own machine. I ran the 5M model on an 8-core laptop CPU and single forecasts came back fast enough to call inline from a request handler, no queue, no batch job, no waiting.

Installing Timestral in Python

There's no PyPI package yet. You install straight from GitHub:

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

You'll need Python 3.10+ and PyTorch 2.4+. If you want pinned, reproducible versions, Mistral's own repo uses uv:

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

Either way: no CUDA, no GPU drivers, nothing beyond PyTorch, NumPy, safetensors, and huggingface_hub. That's the whole point of the release.

Running Your First Forecast

Here's the minimum working example, close to what's on the model card, forecasting 96 steps ahead from a random walk:

import numpy as np
from timestral import TimestralForecaster

forecaster = TimestralForecaster.from_pretrained("mistralai/Timestral-5M")
context = np.random.randn(2, 1, 2000).cumsum(-1)  # (series, variates, time)
forecast = forecaster.forecast(context, prediction_length=96)

forecast.quantiles.shape   # (2, 1, 96, 21)
forecast.median            # (2, 1, 96)
forecast.quantile(0.9)     # the 90th-percentile path

Swap in your own data, and the shapes are what matter: (batch, variates, time), or just (time,) for one univariate series. If you were hoping to pass a pandas or Polars DataFrame straight in, you can't yet. There's an open GitHub issue tracking a future narwhals extra for pandas/Polars/PyArrow support, so for now you convert to NumPy yourself.

For the bigger models, just change the repo id: mistralai/Timestral-28M, -123M, or -209M. Nothing else in the code changes, which is the nicest part of this release. You can prototype on the 5M model and swap to 209M for production without rewriting anything.

How Good Are the Benchmarks, Actually?

Mistral says the 209M model ranks first among pretrained, zero-shot forecasting models on all three of the field's main public leaderboards: GIFT-Eval, TIME, and fev-bench. It also claims the 28M model beats Chronos-2, a model with roughly four times as many parameters, on GIFT-Eval and TIME.

Those are real, checkable rankings, and I don't doubt the leaderboard positions. What I'd push back on is the framing. Time-series benchmarks measure fit on historical data from a fixed set of domains, and that's not the same claim as "this will work on your data." The Hacker News thread on the release has a comment worth sitting with: forecasting research only ever observes one universe, so models end up overfit to the one history we actually have. Another commenter made a narrower point: for something like electricity demand, a dumb model that just knows the time of day will beat a zero-shot foundation model that doesn't.

My take, having poked at it for an afternoon: treat zero-shot Timestral as a fast, strong baseline, not a replacement for a model you've actually tuned on your own series. It's genuinely useful for the "I have 40 different metrics and no time to build 40 forecasting pipelines" problem. It's less useful if you've already got a tuned XGBoost or ARIMA model on a series you understand well. One HN commenter said flatly that, in their experience, an XGBoost model trained per time series has never been beaten, and that tracks with how I'd expect a general-purpose model to perform against something hand-built around a specific dataset.

It's also part of a broader pattern this year of small models punching above their parameter count instead of chasing size, see also Mercury 3's diffusion-based coding model, where latency and cost became the headline number instead of benchmark score alone.

The License Catch Nobody's Talking About

Here's the part that almost got buried under the CPU speed headline. The inference code on GitHub is Apache 2.0, fully open. The model weights on Hugging Face are not: they ship under what Mistral calls a "Modified MIT" license, and the modification is a revenue cap. If your company's global monthly revenue went over $20 million in the preceding month, you're not authorized to use the weights. That restriction carries through to derivatives and fine-tunes too, including ones made by someone else.

Practically, that means a developer at a company well past that revenue line is technically out of compliance using Timestral-209M even for an internal dashboard nobody outside the team sees, because the clause is about employer revenue, not project budget. Past that threshold, you need a commercial license from Mistral, or you run the model through Mistral's own hosted platform instead.

I get why Mistral wants a lever for monetizing enterprise use. But calling this "MIT" when real MIT has no usage restrictions at all is the kind of license-washing that irritated a lot of the Hacker News thread, and I think that's a fair complaint. If you're a startup or a solo developer, this almost certainly doesn't touch you. If you're shipping it inside a product at a company near or over $20M a month in revenue, read the actual license text before you deploy, not a summary of it, including this one.

Should You Actually Use This?

If you need fast, zero-shot forecasts across a lot of different series and don't have time to hand-tune a model per series, Timestral is worth trying, especially the 5M or 28M size, since both are small enough to run inline without a GPU budget or a batch pipeline. The covariate support (known holidays, promotions, categorical flags) is what pushes it past a toy demo.

If you've already got something working, classical statistical methods, a tuned gradient-boosted model, don't rip it out just because a leaderboard says a foundation model is "#1." Benchmarks measure average performance across many series. Your series isn't average. It's yours, and most of the time a model that's actually seen it before will beat one that hasn't. If you're stitching this into a wider 2026 AI stack, it's a reasonable addition to our running list of the top AI tools worth testing against whatever you're already running.

Watch

Install it, point it at your own data, check the quantiles before trusting the median, and if your company's revenue is anywhere near that $20M-a-month line, read the license before you merge.