Timestral vs TimesFM 3: a real lead, smaller than the headlines

This is a reading of Mistral AI's Timestral release, its inference code on GitHub, and the per dataset results Mistral submitted to the GIFT-Eval leaderboard. The models are Mistral's work. The benchmark aggregates below are ours: we recomputed them from the raw submission files rather than copying them from a model card, and the script that does it is published so anyone can check. We have not run the model on our own data.

On 15 October Mistral released Timestral, its first family of time series foundation models. Most of the coverage since has said the same thing: a 209 million parameter model from Paris beats Google's TimesFM 3, and does it on a CPU.

It does. We recomputed the comparison from the leaderboard's own files and the lead is real, consistent and statistically clear. It is also about two percent. And eight days after Timestral's results were merged, a model submitted this morning ranks above it on one of the leaderboard's two orderings.

Both of those are true, and neither is the most useful thing to know. Six weeks ago we wrote that the licence was the real story with TimesFM 3, whose weights cannot be used in production. Timestral changes that story more than it changes the leaderboard. It also forecasts the tails of the distribution, which is where inventory decisions are actually made, and TimesFM 3 does not.

1. What Mistral shipped

Four sizes, one architecture, the same features at every size.

Both scores are relative to a seasonal naive forecast, so 0.446 means the model's probabilistic error is a little under half of the "same as last season" baseline. Lower is better. These are our recomputed figures, and they match Mistral's model card to the third decimal.

Every size forecasts several related series jointly, accepts covariates known only over the past, covariates known into the future, and categorical covariates, and returns 21 quantiles per time step, from the 1st to the 99th percentile. Context runs to 32,768 steps. The inference package needs only PyTorch, NumPy, safetensors and huggingface_hub, and runs on a CPU.

The code is Apache 2.0. The weights are not, and section 6 is about that.

2. How it works

Timestral is a patch based transformer, which puts it in the same family as TimesFM: the series is cut into patches of 32 steps and each patch becomes a token. The differences are in what the tokens are allowed to see and how the forecast comes out.

Decoupled Horizon Forecasting. Mistral's name for the decoding scheme. The sequence the model processes is the encoded context followed by a set of learned forecast query tokens, one per horizon patch. The query tokens read the causally encoded context and the quantile head reads them. Up to 32 patches, or 1,024 steps, come out of a single pass. TimesFM 3 also produces its horizon in one pass, through what Google calls Contiguous Patch Masking, up to 1,000 steps.

Past 1,024 steps it becomes autoregressive. The code is explicit: "Horizons longer than one decode block are forecast block by block, feeding each block's median back as context." That is the familiar failure mode of feeding a model its own guesses. It will not matter for a weekly demand forecast. It will matter if you ask for a year of hourly values.

Roles, not just channels. Each row is a target, a past only covariate or a known future covariate. Covariates pass information to targets and never read them, and only known future covariates see the horizon. That is a clean answer to the problem we described in QiYao-M: an external signal and your own history play different parts, and the architecture should say which is which. Categorical covariates, such as a store type or a promotion code, are target encoded per series before they go in.

Two passes by default. The forecaster's defaults include what the code calls clampsym: it forecasts the series and its negation, reflects the second forecast back, averages the two, and then clamps at zero any series whose history was never negative. Mistral ran the benchmarks with those defaults. That is a sensible test time augmentation, it roughly doubles inference work, and both halves can be switched off.

3. Is it more powerful than TimesFM 3?

Yes, measurably, by a small margin. We took the 97 dataset configurations in GIFT-Eval, scored each model against seasonal naive on each one, and compared Timestral-209M with TimesFM-3 configuration by configuration.

The interval excludes no difference, and winning nearly three quarters of the datasets is not luck. One caution on that interval: the 97 configurations are not independent, because one dataset appears at short, medium and long horizons, so the true uncertainty is somewhat wider.

Where the lead comes from is more useful than its size.

The gain is concentrated in energy and in multivariate series, where joint forecasting has something to work with. On transport TimesFM 3 is better by 3.6%. On sales the two are level, on only four configurations, which is far too few to settle anything. If your business forecasts retail demand, the benchmark has almost nothing to tell you about which of these two to use.

The size ladder is the other striking result. Timestral-123M is within half a percent of the 209M on both metrics. And the 5M model, at 21 megabytes, scores CRPS 0.479: better than Amazon's Chronos-2 at 0.485 and Google's own TimesFM 2.5 at 0.490, and close to Datadog's 2.5 billion parameter Toto 2.0 at 0.476. A model five hundred times smaller is within a percent of it.

4. Number one, for about a week

Mistral's claim was first place among pretrained and zero shot models on GIFT-Eval. When its results were merged on 16 October, that was true on both of the leaderboard's orderings.

This morning H2O.ai's TimeH2O-v1 was merged. On the geometric mean of scores it now leads, at CRPS 0.441 against 0.446. On average rank across datasets, Timestral-209M is still first, at 24.8 against 25.7. Head to head, Timestral is better on 48 of the 97 configurations. Which model is "number one" depends on how you fold 97 numbers into one, and the honest answer is that they are level. Elsewhere on the board, JP Morgan's Morpheus-2.0 has a better point accuracy than either, at MASE 0.646, though it publishes neither weights nor replication code.

Three other things a reader should hold next to the ranking:

• The training data is not described. Mistral's model cards say a technical report is coming. Until it arrives, "zero shot" and "no test data leakage" are Mistral's declarations on the submission form. The leaderboard records them and cannot verify them. That is true of every entry, TimesFM 3 included.
• The fev-bench and TIME results are self reported. We recomputed GIFT-Eval because the files are public. We did not recompute the other two.
• The margins are small enough to move. A two percent lead on a public benchmark is about the size of the differences we found in QiYao-M and in the agentic entries above both models. The field is crowded at the top and getting more so every week.

None of this is a criticism of Mistral. It is what a leaderboard is: a ranking of the last few weeks, on someone else's data.

5. The difference that matters more: the tails

Here is the feature comparison that the benchmark tables miss.

TimesFM 3 returns nine quantiles, the 10th to the 90th percentile. Timestral returns 21, the 1st to the 99th.

That sounds like a detail. In inventory it is the decision. A retailer that wants a 95% or 99% chance of not running out of a product sets stock to the 95th or 99th percentile of demand over the lead time. With TimesFM 3 that number is outside what the model reports, so somebody extrapolates it, usually by assuming a distribution shape the model never said anything about. With Timestral it is a column in the output.

The same applies anywhere the cost of being wrong is lopsided: capacity planning, staffing, energy procurement, cash buffers. A median forecast is a planning number. The tails are where the money is, and Timestral is the first model of this class we have read that forecasts them directly.

6. The licence, which still decides most of it

Six weeks ago the TimesFM 3 story was that the best published forecaster could not be put in production. That has not changed for the open weights: they remain under Google's non commercial licence. What has changed is that TimesFM 3.0 has been in preview in BigQuery since 12 October, so a Google Cloud customer can now use it under Google's service terms rather than the weight licence.

Timestral's weights are under what Mistral calls a Modified MIT licence. As quoted in several independent write ups and in a public GitHub issue that examined it, the modification is a revenue line: the rights do not extend to a company, or a user's employer, whose consolidated monthly revenue exceeded 20 million US dollars in the previous month, and the restriction carries to derived models, including fine tuned ones. Above the line, the route is a commercial licence from Mistral or Mistral's hosted services. We could not open the licence file itself from our environment, so read the Timestral-209M licence before relying on this paragraph.

Read straight, that splits the market in two.

Below the line, which is almost every business that reads this library, Timestral is a better model than TimesFM 3 that you are allowed to run in production, on your own hardware, over data that never leaves your building. TimesFM 3 is a better model you are not allowed to run, or a managed service on one cloud.

Above the line the comparison inverts. The enterprise that would most like to self host a forecaster needs a contract either way: with Mistral for the weights, or with Google for BigQuery. At that point the deciding questions are procurement ones, such as which cloud the data already sits in, not benchmark ones.

7. The CPU claim

Mistral reports that on an eight thread server CPU, forecasting one day ahead from three weeks of 15 minute history takes about 10 milliseconds with the 5M model and 140 milliseconds with the 209M. We have not measured it. It is plausible for models this size, and it is worth noting that the default two pass augmentation is part of what is being timed or not timed, which the announcement does not say.

The commercial point does not depend on the exact figure. A forecaster that runs in a fraction of a second on a CPU can sit inside the system that uses it: next to the database, inside a nightly job, on an edge device in a warehouse. That is the same argument we made about small models in agent systems: most of the cost and most of the operational risk of a model is in how it has to be served, not in the weights.

8. Side by side

9. What we would do

If you forecast anything that matters to the business, the order of work is the same as it was for TimesFM, with one step added.

1. Compute the seasonal naive baseline. Both models are scored against it on the leaderboard for a reason. If nobody has computed it on your data, nothing else is a comparison.
2. Check the licence against your revenue before anybody spends a week on evaluation.
3. Backtest at the horizon you order against, on your own history, holding out the most recent period. Score the quantile you actually plan to, not only the median.
4. Look at your domain, not the average. If you are in transport, TimesFM 3 won that slice. If you are in retail, the benchmark is close to silent.
5. Try the 28M or 123M first. The 123M gives up half a percent. The 28M, a 111 megabyte file, scores better than TimesFM 2.5 and Chronos-2, which have 200 and 120 million parameters.

And make the comparison repeatable, because the answer will change. Two serious forecasters shipped six weeks apart, and a third overtook one of them within days. That is the case we made in every company needs a model testing manager: somebody has to own the question of which model runs which workload here, with evidence, and re-run it when the next one lands.

10. Sources

1. Mistral AI, Timestral: Mistral's time-series foundation models, 15 October 2026, for the release, the fev-bench and TIME claims and the CPU timings.
2. mistralai/timestral on GitHub, the inference package, for the architecture, decoding, covariate handling, defaults and the code and weight licence statements.
3. Salesforce AI Research, GIFT-Eval, for the per dataset results of every model compared here, read at commit cfaefe0 on 23 October 2026, and Mistral's results submission.
4. Mistral AI, the Timestral-209M model card and its licence.
5. Google Cloud, TimesFM 3.0 in BigQuery, for the managed preview.
6. Our TimesFM 3: forecasting as next token prediction, for the TimesFM 3 specification and licence, and our recomputation script.

We recomputed the GIFT-Eval figures and they can be checked with the script above. We did not recompute fev-bench or TIME, we did not run either model on our own data, and we could not open the Timestral licence file or Mistral's announcement page directly from our environment, so the licence terms and the CPU timings are as reported in the sources named. The leaderboard changed on the day of writing and will change again.

This note sits in our Research track, alongside the foundation models, benchmark and operations threads. Applied forecasting work lives in Operations, and the full library is at Research.