Mistral's new forecasting models can run on a CPU, yet a company may need a commercial agreement before it ever loads the weights. Timestral's published weight license doesn't authorize use when the user's company or employer exceeds $20 million in global consolidated revenue in the preceding month. That makes the employer's revenue a deployment question even for a small internal experiment.
Released on October 15, Timestral is Mistral's first family of time-series foundation models. It predicts numerical sequences, such as sensor readings or demand, with versions ranging from 5 million to 209 million parameters. The practical attraction is local forecasting without a GPU. Whether you can use the downloadable models depends on a separate set of terms.
The license follows the company
The Modified MIT license applies its threshold to company or employer revenue, rather than revenue earned from the model. It also covers derivatives, modifications and combined works. Above the threshold, the text points users toward requesting a commercial license, which Mistral may grant at its discretion, or using its hosted services. It provides no automatic entitlement to a commercial agreement. The measurement period is monthly, and the wording specifies the preceding month. A developer reading this as an annual revenue limit would be applying a different threshold from the one in the file.
The inference repository has a different license: Apache 2.0. That distinction matters when evaluating the release. You can inspect the forecasting code under those terms while the weights retain their own conditions. A permissively licensed Python package doesn't settle permission to deploy the model it loads.
A forecasting job that fits on a server CPU
Mistral's launch measurements describe an eight-thread server CPU forecasting one day ahead from three weeks of observations sampled every 15 minutes. The company reports 10 milliseconds for the 5M model and 140 milliseconds for the 209M model. Those are vendor measurements for a specified workload. They don't establish the latency of a service that must also fetch and prepare data.
The smallest model still accepts up to 32,768 historical steps and produces 21 quantiles, according to its model card. Its eight-layer transformer groups observations into patches of 32 steps. Choosing it doesn't shorten the documented maximum history window, although the published scores show an accuracy cost compared with larger versions. You can therefore test a smaller model against your latency budget without first changing the shape of the forecasting task.
The repository's weight table lists FP32 downloads of 21 MB, 111 MB, 490 MB and 837 MB for the four sizes. Those are weight-file sizes, not total process memory requirements. The downloads give a developer a concrete starting point for deciding which checkpoints to evaluate on existing hardware.
Useful inputs need honest timestamps
Timestral accepts multiple related target series together, plus additional inputs called covariates. The documented interface distinguishes inputs available only in the historical window from inputs known across the forecast horizon. For a capacity-planning experiment, a scheduled shutdown could belong in the latter group. Next week's measured demand couldn't. Preparing those two kinds of data correctly is part of the forecasting job.
The attention-mask implementation enforces a corresponding separation inside the model. Covariate rows cannot read target rows, and rows with access to future covariate values cannot read causal rows. The code's stated purpose is to prevent a future-aware input from relaying a target's own future back into its forecast. That is a useful property to inspect when reproducing results.
Those masks can't tell whether your input file contains information that would have been unavailable at prediction time. As an evaluation rule, freeze each input at the historical forecast date. The distinction in the mask code makes that responsibility explicit: permission to read a future covariate assumes you've supplied an appropriate one.
Read the forecast as a range
The 209M model card describes probabilistic output across 21 quantiles, including the median and the 0.01 and 0.99 levels. A developer can retrieve a central prediction or examine the spread around it. For an alerting experiment, that gives you more to evaluate than a single predicted line. It still leaves the task of checking whether those ranges match observed outcomes.
The forecaster enables symmetric averaging by default: it forecasts the original context and a negated version, reflects the second result, then averages them. It also clips predictions at zero for series whose observed context is entirely non-negative. These are inspectable inference choices that affect the output you receive.
For example, a history containing only positive values triggers the non-negative clipping rule even if your application permits future negative values. Both defaults are arguments to the forecast method. Keep them in the record of an evaluation so a later comparison uses the same procedure. Turning a setting off creates a different experiment. Missing data also has an explicit representation: NaN values or a supplied observation mask. If you replace a missing reading with zero before calling the model, you've changed the input from an absent observation to a numerical value.
Long forecasts have another boundary. The model card specifies up to 1,024 steps in a single forward pass. Beyond that, the software works block by block and appends each block's median forecast to the context. Later blocks therefore depend on earlier predictions. A long requested horizon shouldn't be mistaken for the same calculation repeated against observed history alone.
The benchmark margin varies with model size
Mistral claims first place among pretrained, zero-shot models on GIFT-Eval, TIME and fev-bench in its launch results.
In Mistral's published comparison, Timestral-209M records a GIFT-Eval MASE of 0.658, against 0.661 for t0-gamma and 0.667 for TimesFM-3. Lower is better on this error metric. The result supports a lead within that comparison, with a small numerical gap to the nearest entry shown. It doesn't tell you how often any model wins on your particular series.
The family's results also make the smaller checkpoints worth testing. GIFT-Eval MASE is 0.705 for 5M, 0.678 for 28M and 0.659 for 123M, compared with 0.658 for 209M. The near tie between the two largest versions is a reason to measure both on your data. These are Mistral's reported results; this article hasn't independently reproduced them.
What you would actually deploy
The checkpoint loader accepts either a local directory or a Hugging Face repository. It loads two files, config.json and model.safetensors, and supports a pinned revision. Once the files are available locally, the loader can use the cache without network access. That makes a fixed local evaluation possible without downloading a checkpoint anew for every run.
The same loading code defaults to CPU and float32, and says inference was validated in float32. Keep that detail alongside the checkpoint revision when recording results. A change in precision would need its own accuracy and latency checks before you treated it as an equivalent deployment. The loader restricts its Hub download to those two checkpoint files and loads weights with strict state-dictionary matching. Local inference has a visible path through the source, which helps when you need to establish exactly which artifact an evaluation used.
Maintenance has a defined boundary, too. Mistral's contribution policy accepts bug reports and questions but declines pull requests. The team says it handles issues on a best-effort basis and fixes security vulnerabilities and major bugs. If your evaluation finds a problem, the requested report includes a reproducer, input shapes and checkpoint details. Plan around that support arrangement when deciding how much local maintenance you can take on.
Mistral says a technical report with full results will follow. Watch for the additional evidence needed to reproduce its comparisons, then test the smallest checkpoint that meets your own forecast-error and latency requirements. The CPU claim is straightforward to measure. The published weight terms belong in that evaluation before the model becomes an internal dependency.