Mistral Timestral: Time-Series Foundation Models in 5M–209M Parameters Top GIFT-Eval, TIME and fev-bench

Mistral has released Timestral, its first family of time-series foundation models. The largest model, at 209M parameters, ranks first on all three of the field's main public benchmarks — GIFT-Eval, TIME and fev-bench — among pre-trained, zero-shot models, outperforming the previous state of the art with only two-thirds of the model parameters.

The results come from a single checkpoint, without ensembling, and have been submitted to the GIFT-Eval and TIME leaderboards. Timestral produces probabilistic, multivariate forecasts and supports both past-only and known-future covariates.

What Timestral is

Timestral is a time-series foundation model (TSFM) family released in four sizes: 5M, 28M, 123M and 209M parameters. All four share the same architecture and training recipe.

Attribute	Timestral
Type	Time-series foundation model (TSFM)
Parameters	5M, 28M, 123M and 209M
Context length	32,768 time steps
Output	Probabilistic forecasts, 21 quantiles
Inputs	Multivariate targets, past-only and known-future covariates
Deployment	On-prem, VPC or air-gapped
Licence	Modified MIT

The model is a numerical forecasting model, not a language model. Mistral positions it as something that can run inside existing monitoring pipelines or be paired with language models in multi-modal agentic workflows.

Benchmark results

Timestral ranks first across all five metrics among pre-trained, zero-shot models on the three main public forecasting benchmarks. Lower is better on GIFT-Eval and TIME; on fev-bench the reported metric is a SQL skill score, where higher is better.

GIFT-Eval: top ten of 83 comparable pre-trained and zero-shot entries.
TIME: top ten of the 35 leaderboard entries.
fev-bench: top ten of the 37 leaderboard entries, by SQL skill score.

Mistral reports that its 28M model beats Chronos-2, which is about four times larger, on GIFT-Eval and TIME. Its 209M model beats TimesFM-3 and Falcon-2.0 while using fewer parameters.

Model sizes and the accuracy-versus-size trade-off

Every Timestral size sits on the Pareto front of forecasting accuracy versus model size: for each model size, Mistral claims no public model forecasts better. Larger models improve forecast performance; smaller models are faster and cheaper.

Timestral does not need a GPU at inference. On a standard server CPU with 8 threads, forecasting one day ahead from three weeks of 15-minute history takes 10 ms with the 5M model and 140 ms with the 209M model.

The intermediate sizes trade accuracy for latency in a measured way: the 28M model is five times faster than the 209M model, and the 123M model comes within 0.2% of the 209M score at three quarters of its latency.

Why time-series foundation models matter

Classical models such as ARIMA and linear regression remain well-established tools for forecasting time series, but they are usually fitted to a single series and learn only from that series' history. Deep learning models such as PatchTST add the capacity to learn nonlinear patterns across many related series, but they are still typically trained from scratch on each dataset, so what they learn does not carry over to new domains.

Time-series foundation models bring the pre-training approach to time series. Trained on a large and diverse corpus, Timestral learns patterns that transfer across series, forecasting zero-shot on data it has never seen, even in domains where data is scarce.

Mistral frames the enterprise motivation around volume: time series is one of the most common data types in enterprise, from sensor telemetry to observability metrics. Forecasts built on it drive decisions in capacity planning, energy, supply chains, risk and maintenance. Industrial plants forecast process sensors against the production schedule, catch equipment drift before it fails, and plan capacity and spare parts across thousands of assets. Finance teams forecast flows, volumes and volatility to inform positions, hedging and treasury across thousands of accounts.

Industrial use case: what the model does on plant data

Mistral describes four capabilities that matter for an industrial plant with thousands of sensors across its equipment.

Multivariate forecasting. A pump's vibration, temperature and pressure do not move independently. A rise in one often explains or causes a change in another. Timestral models related series jointly, so it can use those dependencies instead of forecasting each sensor in isolation.

Probabilistic forecasting. A single predicted value may not show the full picture. Timestral predicts a full set of quantiles, so teams can see how wide the uncertainty is, set alert thresholds that reflect it, and plan maintenance around risk rather than a single number.

Categorical covariates. Some covariates take values from a set of categories rather than continuous numbers, such as the day of the week, or a machine's state (running, idle, under maintenance). Encoding these as numbers would impose an order or scale they do not have. Timestral takes them as categorical inputs directly.

Known-future covariates. Some drivers of sensor behaviour are known in advance, such as production schedules, planned shutdowns and weather forecasts. Timestral can condition on them, so a scheduled load increase is expected rather than flagged as a surprise.

From model to system

Mistral describes a multi-step agentic workflow in which Timestral runs alongside language models:

Timestral runs continuously on the plant's sensor streams, detecting anomalies as they occur.
When it flags an anomaly on a pump, an agent embeds the signals and compares them against embeddings of past sensor data to find similar historical failures.
The agent starts sub-agents to run a root cause analysis, drawing on plant context such as maintenance records, shift logs and operator notes, equipment manuals, past work orders, and readings from related equipment.
The agent drafts a suggested diagnosis based on the findings, with supporting evidence and possible next steps.

The stated outcome is that the plant manager gets a diagnosis and a plan backed by the sensor data, rather than just an alert.

Key technical contributions

Mistral attributes the results to four combined ideas, each of which it says will be described in detail in a forthcoming technical report.

1. Decoupled Horizon Forecasting (DHF). Causal decoders trained with contiguous patch masking, as in Toto 2.0 and TimesFM-3, mask out the values to be forecast, so those values look like missing data and are also lost as context for later forecasts. DHF separates the two: the full history stays in the sequence, and learned forecast tokens read the history before them. Every observed value therefore serves as both target and context, true gaps stay flagged as missing, and training horizon lengths and missing-data augmentation can be tuned independently of each other.

2. Covariate-aware attention. Each input series is assigned a role: target variate, past-only covariate or known-future covariate. Known-future covariates are visible across the whole window while targets stay causal, and information flows only from covariates to targets. This lets Timestral use a holiday calendar or a weather forecast without leaking a target's own future into its forecast.

3. Synthetic-first data. The majority of the training data was synthetic. Mistral first generated univariate processes with coherent temporal dynamics, including trends, seasonality and diverse noise patterns. It then used a multivariate synthesizer to construct multivariate series by introducing nonlinear dependencies between those processes.

4. Two-stage training. Timestral is first pre-trained at scale on purely synthetic data with context size 8192, then post-trained on a mix of real and synthetic data with a 4x longer context. The training objective is a pinball loss over 21 quantiles, a discrete approximation of CRPS.

Adaptation and deployment via Mistral Forge

Public benchmarks measure general performance, but production data can differ significantly in behavior and structure, and it can shift over time as markets change regime, equipment degrades and demand patterns move. Mistral argues the lasting value lies in adapting the model to in-domain data and retraining it as the distribution moves.

Timestral is available through Mistral Forge, the same training pipeline Mistral uses for its language models. Forge supports:

Zero-shot inference out of the box.
Architectural extensions, such as domain-specific covariates.
Fine-tuning on proprietary data, specialising to a domain while preserving general performance.
Control over the training data, including adjusting the training mix, replaying pre-training data, and generating synthetic samples for the target domain. Mistral states that full control over the data ensures nothing it backtested was seen during pre-training.

The full pipeline can be deployed on clients' hardware, including air-gapped environments.

Availability

Mistral has published a GitHub repository at github.com/mistralai/timestral so users can run Timestral on their own data. A technical report with the full results is to follow. Mistral also invites contact for more specialised forecasting problems and research collaboration.

What the Hacker News discussion questioned

The 98-comment thread on Hacker News was largely split between enthusiasm for the engineering and scepticism about whether a general time-series foundation model is the right abstraction at all.

The case against a single time-series bucket

The most detailed critique came from a commenter who works primarily in audio and vision ML and questioned whether "time series" is a meaningful single category:

My field is primarily audio/vision ML so I don't have any particular domain expertise, but I don't get how you can lump all "time-series" together in one big bucket. My naive understanding is that the way to improve the accuracy is to gain as much joint information as possible.

The same commenter argued that known-future covariates should be the foundation of the system rather than an optional enhancement, using electricity price forecasting as the example:

To me this should be the entire basis of the system, not a condition to improve forecast quality? Like if you're modelling electricity consumption, if all you have is a window of N previous samples, you're going to get completely beaten by a comparatively simple system that knows the time of day, that there's holidays coming up, the weather forecast, etc.

They also raised the question of whether a 5M-parameter model can have useful inductive biases about covariate labels at all:

A 5M model has no idea what a "bank holiday" is, it just sees an arbitrary class go from 0 to 1, and won't have any useful inductive biases as to what it means or how to link them to other pieces of information.

The case for TSFMs as labour-saving infrastructure

A counterargument focused on the operational reality of forecasting at scale — many series, each with too little history to support its own model:

Sure, you could train a XGboost model on a time series with holiday or event covariates, but what if you have 10k different series to forecast for? You could train 10k different models, one for each series, but then they have very little history to learn from. Alternatively, you could train a single generic model to cover all 10k, but then you have to deal with scale mismatch between series in addition to the feature dev overhead between series. A TSFM saves a ton of work in modeling each of these series and could potentially generalize better to more accurate forecasts.

Evaluation is the hard part

Several commenters argued that forecasting is difficult to evaluate objectively, because there is only one observed history to test against:

I dont know how one can objectively evaluate forecasting. We observe just one universe. We overfit our models to this one observation we have. Which is why at the end of the day why nobody trusts or blames the forecasting models, specially in all or nothing types of decisions.

A separate comment proposed a concrete testing methodology — synthetic data-generating processes with controlled signal-to-noise ratios:

To meaningfully test a forecasting model, use a data-generating process with a high signal-to-noise ratio where a classical method (empirical conditional distributions, i.e., counting) can capture most of the signal. Then check whether the model captures that signal too. If you only test on high-noise processes, any model looks comparable to SOTA.

Benchmark presentation drew criticism

One commenter took issue with how the results were visualised:

crazy how they make an improvement of 0.03 look like a 5x difference

Licensing and open weights

The spec table lists Timestral under a Modified MIT licence, but at least one commenter read the terms as restrictive:

It's quite impressive that they get performance so close to the leader t0-gamma but unfortunate about the restrictive license

Another commenter framed the release as a step toward open competition in the space, referencing Nixtla's tooling:

I remember using that and was quite good so happy that there is more open competition now in the space

A separate comment asked directly how Timestral compares to Nixtla's TimeGPT, linking to the Nixtla repository.

Observability: is a black box enough?

A signals-processing R&D engineer asked what kind of dynamical-system observability Timestral provides, contrasting three modelling approaches: fitting a known model structure with unknown parameters, model-free basis-function search, and a pure input/output black box. They noted that the first approach yields insight into how variables are coupled and how strongly, which supports business decisions about adjusting parameters. After reviewing the spec table, the same commenter concluded:

Edit: Looks like it's a pure black box which you can run on premise.

Scepticism about the customer story

One commenter dismissed the appeal of time-series foundation models as marketing-driven and pointed to the absence of a named reference customer:

Meh....time series data is fundamentally different from textual data. I see why a time series "foundation model" seems appealing, especially to the marketing folks at Mistral. Real-world usability is very limited, which is probably the reason why the blog post features an imaginary customer rather than an actual reference.

Where the model fits in the sequence-model landscape

One commenter suggested that large language models are, at an abstract level, a more general class of time-series model — "like a general purpose sequence model." Another noted long-standing interest in the area, saying they had been bullish on time-series forecasting since 2006 and that Spacetimeformer was a major leap forward that was overshadowed by language-model progress.

Mixed reactions on Mistral itself

The thread also contained broader commentary on Mistral as a company. One commenter praised the release as "some great european sovereignty," while another criticised Mistral's other model releases and argued that Europe needs to review how it grows and retains technical talent. A third commenter said they were migrating to Timestral for macro forecasting work. Several comments in the thread were flagged by moderators, and some read as satirical or promotional rather than technical.

The practical question

A recurring sentiment, stated most plainly by one commenter, was that the model is interesting but hard to place:

I like that it's something different but I'm struggling to think of a way to use this.

A contrasting view came from a commenter who noted how much the tooling has changed: building and deploying a forecasting model took months five years ago, whereas now a comparable result can be produced in minutes with LLM assistance, plus fine-tuning on proprietary data. Their stated wish was for an open-weight model with this level of performance.