Timestral Tested: How Much Data AI Demand Forecasting Needs
by Dr. Phil Winder , CEO
In October 2026, days after Mistral released Timestral, I tested it on an industrial client’s process data. The gold-standard measurements come from lab experiments, so the data are scarce. Pretrained forecasters do well with plenty of data, so I wanted to know how little is too little for Timestral, and what happens when tomorrow leaves the range of the history.
AI demand forecasting uses machine learning to predict how much of a product, a service or a resource people will want. Pretrained time-series foundation models such as Mistral’s Timestral, released on 15 October 2026, Amazon’s Chronos-2 and Google’s TimesFM make that forecast from history alone, with no training on your data. This is called zero-shot forecasting.
To find out, I tested these models against a spreadsheet-style forecast, LightGBM and a small model of how electricity demand works, on 300 retail products and on GB national demand. With plenty of history, Timestral’s retail error was 14% below exponential smoothing, the method in Excel’s FORECAST.ETS, and 3% below LightGBM. It needed about two days of half-hourly demand, or eight weeks of a product’s sales, to beat repeating the last value. However, it missed a seasonal change absent from its history, which a simple model of how demand works caught.
Timestral against a spreadsheet and LightGBM with plenty of history
When Timestral topped Hacker News on 19 October 2026, one forecaster summed up the doubt: “most of my cases are best with seasonal naive.” So I started with retail demand forecasting: every model got two years of weekly sales for 300 products from Online Retail II, a UK online gift retailer, and forecast eight weeks ahead. The table gives each model’s error relative to a simple rule, so lower is better and 0.70 means 30% less error: for retail the rule repeats the same week last year, and for the grid, day-ahead GB electricity demand, it repeats the same half-hour last week.
| Model | Retail error | Grid error | Commercial use | Best for |
|---|---|---|---|---|
| Timestral 209M | 0.70 | 0.36 | Under $20M/month | Accuracy with history |
| Timestral 5M | 0.70 | 0.42 | Under $20M/month | Small CPUs |
| Chronos-2 | 0.70 | 0.37 | Yes | No licence limit |
| TimesFM-2.5 | 0.70 | 0.48 | Yes | History only |
| TimesFM-3 | 0.69 | 0.39 | No | Research |
| t0-gamma | 0.71 | 0.37 | Yes | The safest ranges |
| LightGBM | 0.72 | 0.49 | Yes | New products |
| AutoETS (spreadsheet) | 0.81 | 2.57 | Yes | A same-day baseline |
The pretrained models tied with each other on retail, and every one of them beat both baselines. Timestral’s error was 3% below LightGBM’s and 14% below AutoETS, the stand-in for Excel’s FORECAST.ETS, and it stayed ahead of LightGBM however much history I gave it. That margin is as thin as the leaderboards suggest: GIFT-Eval has Timestral leading t0-gamma by half a percent, yet here t0-gamma came last of the pretrained models. On the grid, AutoETS dropped the daily cycle and did worse than repeating last week, while Excel’s own fixed structure, ETS(A,A,A), did far better.
Telling the models what the shop had planned made little difference. On 400 fresh-food series from FreshRetailNet-50K, discount, holiday and activity flags improved every model slightly, and Timestral without them still beat LightGBM with them. Flags can even break a pretrained model: when a November-December flag switched on that one product’s history had never seen, Timestral’s upper forecast leapt to 327,000 units a week for a product that sold a few dozen.
These results differ from the first independent retail test of Timestral, by Iyer and Dabbeeru on 18 October 2026, which put it behind a tuned ensemble on all four of their datasets. They scored the average of its quantiles, which its long upper tail inflates, and capped the history it saw. I scored the median on the full history, and the probabilistic forecasts meant what they said: the pretrained models’ 80% intervals contained close to 80% of actual sales, where Frank Chu’s test on 19 October 2026 had found Timestral’s interval missing most months of one airline series. Compare any product’s forecasts with its sales below.
How much history Timestral needs
Next I cut the history each model saw, for the grid to between six hours and seven days of half-hourly demand, and for retail to between one and eight weeks of sales.
With a day or less of half-hourly demand, every pretrained model did worse than repeating the same half-hour yesterday, Timestral by almost three times. With two days it beat both that rule and LightGBM and kept improving up to a week, though these tests do not explain why the step from one day to two is so sharp. The smaller 5M model needed three days.
A new product followed the same pattern over weeks: with one week of sales every pretrained model simply repeated last week’s number, and their 80% intervals missed most actual sales. Timestral was worse than repeating last week at two weeks, level at four and ahead at eight. A LightGBM trained on the shop’s other products beat it at four weeks and matched or beat it at eight, because it already knew how this shop’s products sell, and a September 2026 study of 12 foundation models found them barely better than simple rules on sparse demand. Below about two months of sales, knowledge from elsewhere beats a product’s own history.
Forecasting outside the range of your history
To see what happens when the future leaves the range of the history, I gave every model GB demand from June to August 2025, plus the measured temperature for the months ahead, and had it forecast to 30 November. Daily mean demand rose about 7 GW as the days cooled.

Through October and November every pretrained model forecast another August, doing about as well as simply repeating the last week of August, and LightGBM given the temperature did no better. A small model of how demand works, its structure learned from 2024, had less than a third of their error, and forecasting one day at a time from the same summer gave the same answer.
Every model that takes covariates had the temperature, so the gap is knowing what cold does to demand. A pretrained model learns that from the history it is given, and a summer has no cold days. The theory model had learned from 2024 that GB demand rises about 627 MW for every degree below 14.5 °C, knowledge from outside the test window. Its 80% interval was too narrow, but the pretrained models’ intervals rarely contained the real demand: they were confident about the wrong level. The retail equivalent, untested here, is a product’s first Christmas or its first week at a new price.
A forecasting model built on how demand works
One theory says GB electricity demand follows a daily shape that differs on weekdays and weekends and drifts with day length, and rises as heating comes on below a threshold temperature. I fitted that structure once, on 2024, and tested it on 2025, although in practice a prior, an educated guess at the parameters, often stands in for historical data. Because it learns almost nothing from recent history, it did as well with six hours of history as with a week, and Timestral 209M needed at least a full week to beat it.
Our industrial work leans on the same idea, because data there is hard to get: theoretical models constrain trained models and stop them overfitting the data.
Learning only from data has a second trap: a forecaster learns what moved together, including the operators. When someone adds more of an input because the output is drifting, the history shows that input rising as the output falls. A crude model learns the relationship backwards. In a controlled distillation column, for the same reason, a modeller would “discover” that more reflux worsens separation. Retail has the trap in price, which a business cuts when demand is weak, so a model fitted to sales can learn a demand curve that slopes the wrong way, which is why AI pricing optimisation starts by modelling demand.
Another solution to this problem, once the feedback loop is known to exist, is to treat it as a Markov decision process. You can then “cancel out” the effect of the decision on the data.
The pretrained model still has a place beside a model of the process: forecast what the process model gets wrong, add inputs one at a time, and a gain shows something real is missing and which input carries it. The pretrained model finds the signal, not the law. Where every data point costs an experiment, we build models that give a range from a few runs, Gaussian processes among them, the work behind our AI consulting for manufacturing.
Which pretrained forecasting models a business can deploy
Timestral’s weights are free to use unless your company’s global consolidated monthly revenue exceeds $20 million, fine-tuned versions included; above that you need a commercial licence from Mistral, so the licence settles the shortlist before accuracy does. TimesFM-3’s downloadable weights and Salesforce’s Moirai 2.0 are non-commercial, with TimesFM-3 usable in production through Google Cloud. Chronos-2, TimesFM-2.5 and t0-gamma are Apache 2.0.
| Model | Time per forecast | Takes your drivers |
|---|---|---|
| Timestral 5M | 0.5 ms | Yes |
| Chronos-2 | 2 ms | Yes |
| Timestral 209M | 6 ms | Yes |
| t0-gamma | 6 ms | Yes |
| TimesFM-2.5 | 7 ms | Through an add-on |
| TimesFM-3 | 11 ms | Yes |
| AutoETS | 21 ms, with fitting | No |
| LightGBM | 84 ms, with fitting | Yes |
These timings are for one retail product on a shared Apple M1 laptop, so treat them as indicative. Mistral quotes 10 ms and 140 ms for its 5M and 209M models forecasting a day ahead on a server CPU, and Timestral runs the model twice per forecast by default, once on the mirror image. As of 20 October 2026 fine-tuning was offered only through Mistral Forge, and there was no PyPI package.
Testing methodology
- Data: Online Retail II (CC BY 4.0), weekly units per product, without cancelled orders or the orders they reverse (one cancelled 74,215-jar order would otherwise dominate). GB national demand from NESO, whose yearly files run 21 days behind, plus its Demand Data Update for October 2026 (supported by National Energy SO Open Data, NESO Open Data Licence). Daily GB temperature from Elexon BMRS (contains BMRS data © Elexon Limited copyright and database right 2026, BMRS Data Licence). FreshRetailNet-50K (CC BY 4.0) for promotions. Kaggle competition data, which may not be redistributed, and Open-Meteo’s free API, which is non-commercial, stayed out.
- Models: seasonal naive, AutoETS, ETS(A,A,A), Croston, TSB, LightGBM (mlforecast, lags and calendar features), Timestral 5M and 209M (commit a534bdb), Chronos-2, TimesFM-2.5 and 3, t0-beta and t0-gamma, all pretrained models zero-shot on the CPU, and the theory model.
- Scores: rolling-origin backtests on median forecasts (retail: eight weeks ahead from five dates between June and October 2011, 1,332 forecasts; grid: 28 day-ahead forecasts across 2025), MASE and weighted quantile loss (10% to 90%) relative to seasonal naive, as GIFT-Eval reports them. Retail uses ratios of mean MASE, because a geometric mean flatters models forecasting small sales for products that sold nothing. 95% intervals resample whole products, or days for the grid, where they are optimistic.
- Temperature: measured, so every model given it knew the weather in advance. A real forecast would do worse.
- Leakage: as of 20 October 2026 Mistral had not said which real series Timestral saw, and the GitHub issue asking for its training cutoff was open. Only 6% of 401 evaluation datasets had never appeared in a model’s training data, and Online Retail II has been public since 2019. Five day-ahead grid forecasts for 15 to 19 October 2026, after every model’s release, were too few to separate the models: every interval included the naive forecast’s score.
- Not measured: forecasts that add up across products and stores, promotions beyond one dataset, and fine-tuning.
General chatbots such as ChatGPT stayed out: chat-tuned GPT-4 forecast worse than GPT-3, partly through how it splits numbers into tokens and partly through badly calibrated ranges, and stripping the language model from published LLM forecasters did not make them worse.
The code, every forecast and the results are MIT-licensed at winderai/demand-forecasting-benchmark. One product takes this much:
import pandas as pd
from timestral import TimestralForecaster
weekly = pd.read_parquet("data/prepared/retail_weekly.parquet")
sales = weekly[weekly["unique_id"] == "85123A"].set_index("ds")["y"] # white hanging heart T-light holder
history = sales[:"2011-10-09"]
model = TimestralForecaster.from_pretrained("mistralai/Timestral-209M")
forecast = model.forecast(history.to_numpy(), prediction_length=8)
print(pd.DataFrame({
"p10": forecast.quantile(0.1)[0, 0].numpy(), "median": forecast.median[0, 0].numpy(),
"p90": forecast.quantile(0.9)[0, 0].numpy(), "actual": sales["2011-10-16":][:8].to_numpy(),
}, index=sales["2011-10-16":][:8].index).round(0))
When to use a pretrained forecaster and when to build a model
You can use a pretrained forecaster when:
- you have at least two days of half-hourly history, or about eight weeks of weekly sales
- you have many series and no time to model each one
- next month should look like last month
Score it against repeating the last value, the forecast you get for free: forecast value added asks the same of every step in a forecasting process, and in one study of eight supply-chain companies 52% of forecasts were worse than a random walk. Its 1% and 99% quantiles also make a cheap check on a new sensor.
Build a model of how the system works, or one trained on your other products, when:
- history is short or expensive: a new product, a new plant, a lab experiment
- future demand depends on different conditions: a season missing from the data, a promotion, a new control setting
- you’re interested in causation
- you want a real-life explanation of the forecast
Whichever you choose, an inventory forecast is only the start of a decision. Ordering stock at each model’s 90th percentile, two models whose errors differed by 3% left very different shelves:
| Ordering at the 90th percentile | Units short | Units left over |
|---|---|---|
| Timestral 209M | 51,293 | 611,897 |
| LightGBM | 91,457 | 405,405 |
| Actual sales | 362,575 units |
Which is better depends on what a lost sale costs against a unit left on the shelf: the 90th percentile is right only when running short costs nine times as much as overstocking. Forecasts for products, stores and regions also have to add up, which none of these models does.
That is the work in an AI demand forecasting project: your drivers, a model of how your demand works where the data runs out, and the step from a range to an order, a price or a rota. We built example forecasting models for Grafana’s machine learning platform, predicted aircraft taxi times for an aviation client and reviewed the ordering step in inventory control with reinforcement learning, the subject of the O’Reilly book I wrote. A data science consulting proof of concept typically costs £15,000 to £40,000 over two to four weeks (what AI consulting costs breaks that down). If you want to know how little data is too little for yours, ask us.
From a summer of history, every pretrained model forecast another August in November. A model grounded in experience knows that winter is coming.
Frequently asked questions
Timestral is Mistral AI’s family of four time-series foundation models (5M, 28M, 123M and 209M parameters), released on 15 October 2026. They forecast one or many series without training on your data, accept past-only and known-in-advance inputs such as promotions or temperature, and return 21 quantiles per step, so every forecast has a range. They read up to 32,768 steps of history and forecast up to 1,024 per pass.
With enough history, a pretrained model such as Timestral, Chronos-2 or TimesFM is the best free first forecast. In Winder.AI’s October 2026 test on 300 products from a UK online retailer, Timestral 209M’s error was 30% below a same-week-last-year forecast, 14% below exponential smoothing and 3% below a fitted LightGBM, level with the other pretrained models. With under about eight weeks of a product’s sales, a model trained on the business’s other products did better, and when the future left the range of the history, a model built on how demand works did far better.
In Winder.AI’s October 2026 tests, about two days of half-hourly history for GB electricity demand and about eight weeks of weekly sales for a retail product. With one day of half-hourly demand its error was 2.7 times that of repeating the same half-hour yesterday, and with one or two weeks of sales it did no better than repeating last week.
For the baseline, often yes: in Winder.AI’s October 2026 test on 300 retail products, Timestral’s error was 14% below exponential smoothing, the method behind Excel’s FORECAST.ETS, with no tuning. It does not add what the spreadsheet’s owner knows (planned promotions, totals that must add up across products and stores, how much to order), and it cannot see a change its history never showed: given a summer of GB electricity demand, every pretrained model tested forecast summer levels for November.
No. In Winder.AI’s October 2026 tests on an Apple M1 laptop CPU, Timestral 209M forecast eight weeks of a weekly product in about 6 ms and the 5M model in about 0.5 ms. Mistral reports 10 ms (5M) and 140 ms (209M) for a day-ahead forecast on an 8-thread server CPU. The 5M model’s weights are 21 MB.
Only for smaller companies. Timestral’s code is Apache 2.0, but its weights use a modified MIT licence that gives no rights if your company’s (or employer’s) global consolidated monthly revenue exceeds $20 million for the preceding month, fine-tuned and derived versions included; above that you need a commercial licence from Mistral. Chronos-2, TimesFM-2.5 and t0-gamma are Apache 2.0, and TimesFM-3’s downloadable weights are non-commercial.
A pretrained-model baseline on your own history costs almost nothing in compute and takes about a day. A proof of concept with Winder.AI, adding your own drivers, a model of how your demand works where the data runs out, and the step from forecast to decision, typically costs £15,000 to £40,000 over two to four weeks. See our data science consulting page.