Run Timestral Locally on Windows 11, Mac and Kali Linux: Mistral's Time-Series Forecasting Models on a CPU (5M to 209M), Covariates, the $20M License, and vs Chronos-2 and TimesFM

Timestral is Mistral AI's first time-series model family, released on October 15, 2026: four open-weight models, from 5 million to 209 million parameters, that forecast numbers over time (sales, sensor readings, traffic, power use) instead of writing text. You download them from Hugging Face, install one Python package, and run them on an ordinary CPU, with no graphics card: the biggest one is an 837 MB file, and on a four-core laptop it forecasts the next 96 steps of a three-week series in about 3 seconds; the smallest does it in under half a second. Mistral's own leaderboard claims put the 209M model first among pretrained forecasting models on the three public benchmarks that matter, and the 28M model ahead of Chronos-2, a rival about four times its size. Here is the detail that most coverage skips: the license is MIT with one extra sentence: you may not use the weights if your company's global monthly revenue exceeds $20 million. For a shop, a startup or a research team that is a free model; for a large company it is a sales call. This page covers what Timestral does and does not do, the install on Windows 11, Kali Linux and a Mac, a working forecast with real timings for all four sizes, covariates (the feature that makes it more than a curve-fitter), how it compares with Chronos-2 and TimesFM, the license, and the cheapest way to run it on AWS.

Jake's phone repair shop has two years of daily sales in a spreadsheet and a question he asks every October: how many screens, batteries and cases to order before the festival rush. His developer friend Ethan had tried the forecasting tools in the spreadsheet (a trend line, a moving average) and neither knew that Saturdays are busy and that the week after a big phone launch is busier. Timestral is the first model Ethan tried that reads the whole history, returns a range rather than a single number, and runs on the shop's PC in a few seconds. This page is what he set up, including the two things that went wrong the first time.

New to running models on your own machine? Our free plain-English series covers the words used here (weights, parameters, virtual environments) in an hour. This page needs no GPU and no prior forecasting knowledge.

What Timestral is, in plain English

Most of the models in the news are language models: they read text and write text. Timestral is a time-series foundation model, a different kind of model with the same big idea. It was pretrained on an enormous collection of number sequences, so that when you hand it a new sequence it has never seen (your daily sales, a server's CPU load every minute, a city's electricity demand every quarter hour), it can continue the sequence without any training on your data. That is called zero-shot forecasting, and it is what makes these models practical for people who do not have a data scientist: you do not fit anything, you just ask.

Three properties define what you get back:

• Probabilistic. It does not return one number per future step. It returns 21 quantiles per step: the 1st, 5th, 10th, 15th and so on up to the 99th percentile. The 50th is the median, the "most likely" line; the 10th and 90th give you a range that the real value should fall inside about 80% of the time. For ordering stock, the range matters more than the line.
• Multivariate. It can forecast several related series at once (screens, batteries and cases together), and it can take covariates: extra columns that explain the target, such as "is this a holiday" or "price on that day," including values you already know for the future. That is the feature that separates it from a trend line, and it has its own section below.
• Long context. It reads up to 32,768 historical steps in one go, which is three years of hourly data or nine months of 15-minute readings. Internally it groups every 32 steps into a "patch," so 32,768 steps are 1,024 patches, and the forecast comes out in blocks of up to 1,024 steps; longer horizons are produced block by block, each block's median feeding the next.

The four sizes share one architecture and one training recipe; they differ only in width and depth. All four are CPU models in practice: the weights are small enough that a laptop processor runs them in seconds, and Mistral's own timing was done on a server CPU with eight threads, not a GPU. A GPU works too and is faster, but it is not the point.

Jake: "So it's an AI that's never seen my shop, and it can still tell me next month?"

Ethan: "It's seen a million shops' worth of shapes: weekly rhythms, slow climbs, spikes that fade. It matches your history to the shapes it knows. And it tells you how sure it is, which the spreadsheet never did."

The four sizes: files, speed on a laptop CPU, and which to pick

Timings below are from a four-core laptop processor with no GPU, after a warm-up call, forecasting 96 steps from a 2,016-step history (three weeks of 15-minute readings with a daily cycle). Mistral's published figures are for an 8-thread server CPU and a 1-day-ahead forecast from the same three-week shape, which is why they are faster. Downloads are the fp32 weights from Hugging Face.

Two things should shape your choice. The 5M and 28M models cost the same on a laptop: at that size the fixed overhead of a call dominates, so there is no reason to use the 5M except on hardware far smaller than a laptop. And the jump from 28M to 123M is roughly eightfold in time, so for anything a person is waiting on (a dashboard, a script that forecasts a thousand products) the 28M is the sensible default, with the 209M reserved for the forecast you act on. On the synthetic series used for timing, all four gave the same median to within a few hundredths, and the same 10th and 90th percentiles, which is reassuring for the small ones and a reminder that the benchmark gaps show up on hard, messy real data, not on clean sine waves.

Memory will not be your concern: the 209M model in fp32 is under a gigabyte of weights, and the working memory for a 32,768-step context is a few hundred megabytes. Any machine in our laptop tiers for local AI runs it, including the ones at the bottom of the list that cannot run a chat model at all.

Install Timestral on Windows 11, Kali Linux and a Mac

Timestral is a Python package that depends only on PyTorch, NumPy, safetensors and the Hugging Face hub library, so you have very little to install. It needs Python 3.10 or newer and PyTorch 2.4 or newer. Because no GPU is needed, install the CPU build of PyTorch, which is a fraction of the size of the CUDA build.

Kali Linux and other Linux

Kali refuses system-wide pip install with the "externally-managed-environment" error, so work in a virtual environment, as our guide to that error explains:

sudo apt update && sudo apt install -y python3-venv git
mkdir ~/timestral && cd ~/timestral
python3 -m venv .venv && source .venv/bin/activate
pip install --index-url https://download.pytorch.org/whl/cpu torch
pip install "git+https://github.com/mistralai/timestral.git"
python -c "import timestral, torch; print(torch.__version__)"

The package installs as timestral; the version that shipped with the launch is 1.0.0. The PyTorch CPU wheel is about 200 MB; the CUDA one, which you do not need here, is several times that.

Windows 11

Install Python 3.12 from python.org (tick "Add python.exe to PATH") and Git for Windows, then in PowerShell:

mkdir $HOME\timestral; cd $HOME\timestral
py -3.12 -m venv .venv; .\.venv\Scripts\Activate.ps1
pip install --index-url https://download.pytorch.org/whl/cpu torch
pip install "git+https://github.com/mistralai/timestral.git"

If PowerShell refuses to run the activation script, run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once and try again. The Git step matters: the package is installed straight from GitHub, so pip needs git on the PATH; without it the install fails with "git is not recognized."

Mac

The same Linux commands work in Terminal with the system Python 3 or one from Homebrew; drop the --index-url line, because PyTorch's default build for Apple silicon already runs on the CPU and can use the Metal GPU through device="mps". For a model this small the CPU is fine.

A second route for all three systems: clone the repository and run uv sync --frozen, which installs the exact versions in Mistral's lock file. Use it if you hit a dependency clash with something else in your environment.

Your first forecast: twelve lines, and what comes back

The first call downloads the weights (two files, config.json and model.safetensors) into the Hugging Face cache and keeps them for every later run. No account or token is needed; the repositories are public.

import numpy as np
from timestral import TimestralForecaster

model = TimestralForecaster.from_pretrained("mistralai/Timestral-28M", device="cpu")

# history: one series of 2,016 readings (3 weeks at 15-minute steps)
history = np.loadtxt("readings.csv", delimiter=",")

forecast = model.forecast(history, prediction_length=96)   # the next day

print(forecast.quantiles.shape)      # (1, 1, 96, 21): series, variates, horizon, quantile levels
print(forecast.quantile_levels)      # 0.01, 0.05, 0.1, ..., 0.9, 0.95, 0.99
median = forecast.median[0, 0]       # the central line, 96 values
low, high = forecast.quantile(0.1)[0, 0], forecast.quantile(0.9)[0, 0]
for step in range(3):
    print(f"step {step + 1}: {median[step]:.2f}  (80% range {low[step]:.2f} to {high[step]:.2f})")

What the shapes mean, because this is where your first confusion will happen. The history can be a one-dimensional array (one series), a two-dimensional one (several variates of one series, rows are variates), or three-dimensional (several independent series, each with its variates). Whatever you pass in, the quantiles come back four-dimensional: series, variates, horizon, 21 levels. For the one-series case above that is why the indexes read [0, 0]. Missing readings are allowed: put NaN where the value is unknown and the model treats it as a gap rather than a zero.

On the laptop, that script's forecast line takes 0.43 seconds with the 28M model and 2.9 seconds with the 209M, after a first call that is slower while PyTorch warms up. To forecast several related series together, stack them as rows: a (3, 2016) array of screens, batteries and cases returns a (3, 1, 96, 21) result, and the model uses the relationships between the rows.

Your horizon is not limited to 96. Ask for 1,024 steps and it comes back in one pass; ask for 1,500 and the model forecasts the first 1,024, appends that block's median to the history, and forecasts the rest, which took 9.5 seconds with the 209M model on the laptop. Long horizons widen the quantile range, as they should.

Jake: "So the middle line is the guess and the two outer lines are the 'it could be anywhere in here'?"

Ethan: "Right. Order for the middle line, keep cash for the top line, and if the real number lands outside the band more than one week in five, we've learned something about the shop the model hasn't."

Covariates: telling the model about holidays, prices and launches

A trend line sees only the past values. Timestral can also see covariates, extra columns that move with the target, and it handles two kinds:

• Past-only covariates (past_covariates, shape series by columns by history length): things you knew in the past but do not know for the future, such as yesterday's temperature or a competitor's price history.
• Known-future covariates (known_covariates, shape series by columns by history length plus horizon): things you know for the forecast window too, such as holidays, planned promotions, a phone launch date, or the day of the week. These are the powerful ones: the model can lift Saturday and the launch week because you told it where they fall.

import numpy as np, pandas as pd
from timestral import TimestralForecaster

df = pd.read_csv("daily_sales.csv", parse_dates=["date"])     # 730 rows: date, units, promo, launch_week
H = 60
future = pd.date_range(df.date.iloc[-1], periods=H + 1, freq="D")[1:]

model = TimestralForecaster.from_pretrained("mistralai/Timestral-209M", device="cpu")

# known-future covariates must cover history AND horizon; 0/1 columns are read as indicators
weekend = np.r_[df.date.dt.dayofweek.ge(5).astype(float), future.dayofweek.ge(5).astype(float)]
promo   = np.r_[df.promo.astype(float), np.zeros(H)]            # no promo planned
launch  = np.r_[df.launch_week.astype(float), np.zeros(H)]
launch[-H:][10:17] = 1.0                                        # a launch 10 days out

known = np.stack([weekend, promo, launch])[None, :, :]          # (1 series, 3 columns, 730 + 60)
f = model.forecast(df.units.to_numpy()[None, None, :], prediction_length=H, known_covariates=known)
plan = pd.DataFrame({"date": future, "p10": f.quantile(0.1)[0, 0], "median": f.median[0, 0], "p90": f.quantile(0.9)[0, 0]})
print(plan.head(14))

Rules you need to know: covariates condition the forecast but are never forecast themselves, and they never read the target values; a known-future row containing only zeros and ones is treated as an indicator; a categorical covariate (a product category, a region) goes in as integer codes, which pandas.factorize produces, and for a single target series the model target-encodes those codes per series. Covariates must line up exactly: a known-future array that is one row short of history plus horizon is the most common error on day one, and the message says so.

How good is it? Mistral's numbers, and Chronos-2 and TimesFM beside it

Mistral published leaderboard positions, not a table of raw scores, so here is what the claims are and what they are not. On the three public forecasting benchmarks the field uses, GIFT-Eval (83 entries), TIME (35) and fev-bench (37), the 209M model ranks first among pretrained, zero-shot models on all five headline metrics, from a single checkpoint with no ensembling, and it does so with about two-thirds of the parameters of the previous leader. The 28M model beats Chronos-2, Amazon's forecasting model that is roughly four times larger, on GIFT-Eval and TIME. The 209M beats TimesFM-3, Google's model, and Falcon 2.0 with fewer parameters. The 123M lands within 0.2% of the 209M's score at about three-quarters of its latency, which is why the size table above calls it the value pick.

Those are vendor-reported positions on public leaderboards, so you can check them yourself, and the leaderboards themselves are maintained by third parties. What you cannot read yet is the technical report, still to come, or an independent write-up comparing the four sizes on real business data. Until then, the honest guidance is the one above: the gaps are measured on hard, mixed datasets, and on your own data the right test is a holdout. Here is how you run it in ten minutes:

1. Cut the last four to eight weeks off your history and keep them aside as the answer key.
2. Forecast that window from the shortened history with each size you are considering, with the same covariates you would use for real.
3. Count how many true values fall inside the 10th to 90th percentile band. Around 80% means the model's uncertainty is honest; far more means the band is too wide to be useful, far fewer means it is overconfident on your data.
4. Compare the median's error between sizes. If the 28M is within a few percent of the 209M on your series, you have your answer and your speed back.

Where Timestral sits beside the others, in practical terms:

The license: MIT, plus one sentence about $20 million

The code on GitHub is plain Apache 2.0. The weights are under what Mistral calls a modified MIT license, and the modification is one condition: you are not authorized to use the model if your company's global consolidated monthly revenue exceeded $20 million (or the equivalent in another currency) in the preceding month. The condition follows the weights into any derivative, fine-tune or combined work you build, whoever distributes it. Above the line, Mistral offers a commercial license through its sales team, at its discretion. The rest is standard MIT: keep the attribution and permission notice in copies, no warranty.

For Jake's shop, a freelancer, a startup, a university or a hobbyist, that is a free and permissive license with no revenue reporting, no attribution in the product and no restrictions on commercial use of the forecasts. If you are inside an enterprise it is a licensing conversation before deployment, which is also how Mistral positions the on-premises, VPC and air-gapped deployments and the fine-tuning service it calls Mistral Forge.

Running Timestral on AWS: a small CPU instance is enough

Timestral is not on Amazon Bedrock and has no SageMaker JumpStart listing as this is written; our plain-English SageMaker guide explains what those are if the names are new. Because it is a CPU model, your AWS route is the simplest one there is: a small EC2 instance, the same install commands as Kali, and a script on a schedule. With the US East (N. Virginia) on-demand Linux prices as of late September 2026:

A nightly job that forecasts a thousand products with the 28M model finishes in minutes on the smallest of those, so your realistic monthly bill is cents if the instance stops when the job ends, and a few dollars if it stays on. The shape of that job:

1. Launch the instance with Amazon Linux 2023, install git and python3, and run the same virtual-environment commands as on Kali.
2. Run one forecast by hand so the weights land in the Hugging Face cache on the instance's volume, then set HF_HUB_OFFLINE=1 in the job's environment so it never waits on a download.
3. Have the script read your series from S3 or a database, write the median and the 10th and 90th percentiles back, and exit.
4. Schedule it with cron or an EventBridge rule, and stop the instance when you are not running it; the hourly meter is the only real cost here.

If you already use SageMaker, the same package runs in a notebook or a processing job on a CPU instance; the SageMaker pricing guide has the per-hour numbers for those.

Timestral not working? Troubleshooting by symptom

"externally-managed-environment" when installing on Kali or Debian

Create a virtual environment first and install inside it; the system Python is managed by apt and refuses pip by design.

"git is not recognized" or "No such file: git" during pip install

The package installs from GitHub, so git must be on the PATH. Install Git for Windows or apt install git, open a new terminal, and run the pip command again.

PyTorch download is huge or fails

You are getting the CUDA build. Add --index-url https://download.pytorch.org/whl/cpu to the torch install; the CPU wheel is a fraction of the size and is all Timestral needs.

"torch 2.x is required" or an import error from timestral

Timestral needs PyTorch 2.4 or newer and Python 3.10 or newer. Check both with python -c "import sys, torch; print(sys.version, torch.__version__)" and upgrade inside the environment.

The first forecast takes a minute

That is the download of the weights (21 MB to 837 MB) plus PyTorch's warm-up. The second call is the real speed. Run the download once on a good connection; the files stay in the Hugging Face cache.

A shape error mentioning covariates

Known-future covariates must cover history plus horizon, and past covariates exactly the history; the series dimension must match the target. Build the arrays with explicit shapes and print them before calling forecast.

The forecast is a flat line

The history is too short or too noisy for the model to find a rhythm, or the values are all identical. Give it more history (it reads up to 32,768 steps) and check for a column that was read as text, which arrives as NaN everywhere.

Results differ slightly between the four sizes

Expected. The sizes are different models trained with the same recipe. On clean series they agree closely; on hard series the larger ones are more accurate, which is what the leaderboards measure.

Can it run offline or air-gapped?

Yes. Copy the cached model folder (config.json and model.safetensors) to the machine and point from_pretrained at the directory, or set HF_HUB_OFFLINE=1 with the cache in place.

Timestral: frequently asked questions

Jake's October order came out of a sixty-day forecast with the launch week marked as a known covariate. He ordered for the median and kept cash for the 90th percentile. Two weeks later the launch-week spike landed inside the band, a little above the line, and Ethan showed him the three lines on the shop screen. "The spreadsheet never drew the band," Jake said. "The band," said Ethan, "is the part worth having."

Revision note. Written October 16, 2026, the day after release, with all four sizes timed on a laptop CPU. "Forewarned is forearmed," the proverb says; a forecast with a band is the warning worth having.