Mistral Launches Timestral Time Series Models: CPU Inference and a $20M License Threshold

Mistral's latest release doesn't write a single word. Timestral reads a column of numbers, tells you where it's likely headed next, and gives you a range. Mistral claims its largest version, at 209 million parameters, "ranks first on all three major public benchmarks" and "requires no GPU at inference time."

If you do capacity planning, cost forecasting, or anomaly alerting off a metrics table, this is a useful release. Then you open the license. The weights ship under what Mistral calls a "modified MIT license," and the modification is a revenue cap: if your company's global monthly revenue last month exceeded $20 million, you are not licensed to use it.

What Mistral released

Timestral is a family of four time series foundation models sharing a single architecture and training recipe. "Foundation model" here means zero-shot: you hand it history, it forecasts, with no prior training on your data. The GitHub README lists the checkpoints:

Model	Hub repo	fp32 weights
Timestral-5M	mistralai/Timestral-5M	21 MB
Timestral-28M	mistralai/Timestral-28M	111 MB
Timestral-123M	mistralai/Timestral-123M	490 MB
Timestral-209M	mistralai/Timestral-209M	837 MB

The 209M model card gives the basic shape of the model. It reads up to 32,768 historical steps and predicts up to 1,024 steps per forward pass. Each forecast outputs 21 quantiles, from 0.01 to 0.99, giving you an interval of possible values for each step. It accepts one or more series simultaneously, along with covariates — either known only in the past, or known in the future (holidays, planned promotions, scheduled deployments). Missing values are passed in as NaN.

On an 8-thread server CPU, forecasting one day ahead with three weeks of 15-minute granularity history, Mistral reports the 5M model takes 10 ms, the 209M takes 140 ms, and the 28M is five times faster than the 209M. The Mistral docs list Timestral 1.0 as a "public preview" with no API pricing, so for now you download and run it yourself.

What is a time series foundation model

A Time Series Foundation Model (TSFM) is the product of migrating the large model paradigm to numerical sequence forecasting. The traditional approach requires training ARIMA, Prophet, or gradient boosting models separately for each series, with feature engineering and hyperparameter tuning consuming most of the effort. A TSFM, by contrast, is pretrained on massive heterogeneous series (power loads, retail sales, network traffic, sensor readings, etc.), learning cross-domain temporal patterns so it can perform direct zero-shot inference on new series. This is conceptually aligned with the GPT series in NLP: the pretraining phase absorbs general regularities, and downstream tasks only need to supply context.

To judge whether a TSFM is practical, you typically look at three things: how much history the context window can hold, whether it outputs a probability distribution rather than a point forecast, and the extent of covariate support. Timestral delivers on all three: 32,768 steps, 21 quantiles, and two types of covariates (past-known and future-known). Understanding this background helps position it against comparable models like TimesFM, Chronos, and t0.

Benchmark claims and their source

All numbers below come from Mistral. The model card says the technical report is "coming soon," so until that report lands, you cannot inspect its methodology.

In the model card's comparison table, Timestral-209M scores 0.658 MASE on GIFT-Eval, versus 0.661 for t0-gamma, 0.667 for TimesFM-3, and 0.698 for Chronos-2 (lower is better). On fev-bench's SQL skill score, it records 50.39, versus 49.42 for t0-gamma and 47.28 for Chronos-2 (higher is better). It leads in every row, but its margin over second place is small.

For most teams, the small model is the more interesting part. The 28M scores 0.678 on GIFT-Eval MASE and 0.638 on TIME MASE, both ahead of Chronos-2's 0.698 and 0.662, but behind t0-gamma and TimesFM-3 on GIFT-Eval, and slightly behind t0-gamma's 0.637 on TIME. Mistral says Chronos-2 is roughly four times its size.

Mistral states these results come from a single checkpoint, no ensemble, submitted to the GIFT-Eval and TIME leaderboards, and that the majority of training data is synthetic, so "what we backtested was never seen during pretraining." This addresses the common concern in forecasting benchmarks — data leakage. The technical report still needs to back this up.

MASE, GIFT-Eval, and fev-bench

MASE (Mean Absolute Scaled Error) is one of the most commonly used accuracy metrics in forecasting. It divides the model's mean absolute error by the error of a naive baseline (typically seasonal naive), so a MASE below 1 means the model beats the baseline, and lower is better. The advantage of this design is cross-series comparability: series with different scales can be averaged directly after baseline normalization.

GIFT-Eval and fev-bench are time series evaluation suites that have emerged in the past two years. GIFT-Eval aggregates thousands of real series from multiple domains, emphasizing generalization in zero-shot scenarios; fev-bench (Forecasting Evaluation Benchmark) examines numerical reasoning skills through tasks like SQL query generation, where higher scores are better. Note that the numbers on these leaderboards are sensitive to series selection, forecast horizon settings, and normalization methods, so Mistral's gap of 0.658 versus TimesFM-3's 0.667 on GIFT-Eval — a difference of a few thousandths — is not sufficient to draw conclusions before methodological details are published.

The MIT in "modified MIT"

The inference code is Apache 2.0. The weights are not. The README says the weights are "distributed separately on the Hugging Face Hub under a modified MIT license," and that license is where the trap lies.

The grant itself reads like MIT: use, copy, modify, merge, publish, distribute, sublicense, and sell. Then the license file adds that if your company (or your employer's company) "exceeded $20 million in global consolidated monthly revenue (or equivalent in other currencies) in the prior month," you are "not licensed to exercise any rights under this license." The restriction covers the model "and any derivatives, modifications, or combinations thereof." Companies past that line can apply to Mistral for a commercial license, which Mistral may grant at its sole discretion, or use Mistral's hosted service. The 5M model's license carries the same $20 million cap, so smaller checkpoints are not a way around the restriction.

My reading (I am not a lawyer):

1. It's measured monthly. A company near the line could be within the license this month and outside it next month.
2. It follows the weights into derivatives, modifications, and combinations, including fine-tuned copies.
3. It counts your entire employer's revenue, regardless of how small your team's budget is.

Mistral's announcement positions Timestral for on-premise, VPC, and air-gapped deployments. Read that alongside the revenue cap. The large enterprises most likely to need air-gapped forecasting are often precisely the ones with monthly revenue above $20 million, so they need a commercial license. This is my reading of the two documents, not something Mistral said.

Try it with a week of traffic

If you're below the revenue line, trying it is simple. The package is not on PyPI. The README installs from GitHub and requires Python 3.10+ and torch 2.4+:

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

Below is a capacity planning version of the README quick start. It takes hourly request counts and forecasts the next 168 hours with the 28M model:

import numpy as np
from timestral import TimestralForecaster


**Quantile outputs and capacity planning**

Timestral outputs 21 quantiles per forward pass, which corresponds to probabilistic forecasting rather than point forecasting. Quantile q means "the probability that the true value is less than or equal to this number is q." When you're doing capacity planning, the median (p50) tells you the typical load, while p90 or p99 tells you how much capacity you need to keep the overload probability within an acceptable range. The example code recommends provisioning servers at p90, precisely because even if the model is perfectly accurate, actual load will exceed the median half the time.

Another value of quantiles is that they give you interval width: the span between p10 and p90 is the 80% prediction interval, and a wider span means the model is less certain about that region. This is equally useful in anomaly alerting — if an observation falls outside p99, it's worth investigating. The cost of this output form is that the model must optimize quantile loss (pinball loss) rather than simple mean squared error, which makes training harder, but what you get in return is information directly usable for risk decisions.
# One value per line: hourly request counts, earliest first.
history = np.loadtxt("requests_per_hour.txt")

model = TimestralForecaster.from_pretrained(
    "mistralai/Timestral-28M"
)
week = model.forecast(history, prediction_length=168)

p50 = week.median
p90 = week.quantile(0.9)
print("peak p50:", p50.max())
print("peak p90:", p90.max())

Provision servers according to p90 rather than the median. Actual load will exceed the median half the time.

There are a few more options in the README worth knowing before you put this into a job. from_pretrained accepts a revision parameter, so you can pin a commit while the model is in public preview. local_files_only=True (or HF_HUB_OFFLINE=1) makes it read only from the local cache, suitable for machines in locked-down environments. Known future events go in known_covariates with shape (B, C_known, T + prediction_length); a row of only 0s and 1s is treated as an indicator, which is how you mark release days.

Where its boundaries are

The README is upfront about limitations. Context beyond 32,768 steps is truncated, keeping the most recent. Forecasts beyond 1,024 steps are done in chunks, "with the median of each chunk fed back as context," so the far end of a long forecast is built on earlier guesses. Covariates condition forecasts and are never forecast themselves. The project does not accept pull requests; issues are handled "on a best-effort basis."

I haven't run Timestral myself, so I can't tell you how it performs on your metrics. But a fair test is cheap: backtest it on a month of your own history, compare against whatever you use now, and then — before anyone builds on it — check whether your company is below the $20 million line.

Would the revenue cap on "MIT" weights stop you from adopting a model at work? Or does the free tier for smaller companies look like a fair trade?