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.

ModelRetail errorGrid errorCommercial useBest for
Timestral 209M0.700.36Under $20M/monthAccuracy with history
Timestral 5M0.700.42Under $20M/monthSmall CPUs
Chronos-20.700.37YesNo licence limit
TimesFM-2.50.700.48YesHistory only
TimesFM-30.690.39NoResearch
t0-gamma0.710.37YesThe safest ranges
LightGBM0.720.49YesNew products
AutoETS (spreadsheet)0.812.57YesA 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.

Daily mean GB national demand from September to November 2025, against forecasts made from summer-only history: the pretrained models and LightGBM repeat summer levels, and the theory model with structure from 2024 follows the autumn rise
Forecasts from a summer of history. Only the model that knew how demand responds to temperature followed the autumn rise.

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.

ModelTime per forecastTakes your drivers
Timestral 5M0.5 msYes
Chronos-22 msYes
Timestral 209M6 msYes
t0-gamma6 msYes
TimesFM-2.57 msThrough an add-on
TimesFM-311 msYes
AutoETS21 ms, with fittingNo
LightGBM84 ms, with fittingYes

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 percentileUnits shortUnits left over
Timestral 209M51,293611,897
LightGBM91,457405,405
Actual sales362,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

More articles

Keynote: Data Transparency, AI Use Cases, Data Sovereignty

Discover how AI drives business success with insights on data management, transparency, regulation, and actionable strategies for 2025.

Read more

101: Why Data Science?

This section introduces Data Science. It explains what it is and why we need it. We discuss some of the reasons for doing Data Science and provides famous examples from around the world.

Read more