Timestral benchmarks on production telemetry.
Mistral released Timestral, a family of small forecasting models that read a stretch of history and predict what comes next. Models like this are usually measured on public datasets, which tells you something but not the thing we wanted to know: can one cope with a real production estate? So we tested Timestral performance against 19 series from the infrastructure that runs Coralogix, scored against 12 other forecasting methods.
The model
Timestral comes in four sizes, from 5 million to 209 million parameters. It takes a run of past values and returns a range of likely futures, with no per-series setup and no seasonality settings to choose. It runs on a laptop CPU in a fraction of a second, and the inference package installed and ran first time. Mistral's announcement, the code, and the models.
Why we used production telemetry
Scoring well on a public forecasting dataset clears a low bar. Those datasets are tidy and well behaved, and a model released this year may have trained on them, so a good result tells you less than it appears to. Forecasting is worth having because it sits underneath capacity planning and predictive alerting, and both of those run against production.
So we used our own estate: 19 series over roughly four months. The data is private, which means Timestral cannot have seen any of it in training. It is also awkward in the ways real telemetry is always awkward.
- The series behave nothing like each other. Measured as variability against their own average, they run from 9% at the steadiest to 207% at the most erratic. A smooth storage curve, a spiky alert rate and a noisy p99 latency all have to be handled by the same model with the same settings.
- Some have a working week in them and some do not. Nothing labels which is which.
- Collection has gaps, and some series count upward and reset to zero.
- Things happen that have never happened before. Our final week contained two of them.
Scores on this page use MASE: the forecast's error divided by the error you would get from simply repeating yesterday. Below 1 beats that guess, 0.5 is half its error, lower is better.
Production metrics
Hourly data from 25 June to 17 October 2026, with 12 to 16 weeks of history behind each forecast. We forecast every series 28 times a day ahead and 4 times a week ahead, against 13 methods, and gave Timestral no configuration at any point. Dividing each series by its own average before scoring strips out the real volumes and leaves the shape.
- Accuracy a day ahead, best size
- 0.333
- Error against repeating yesterday
- Half
- Series where a Timestral size won
- 19/19
- Real values inside the 80% range
- 80%
A day ahead, 532 forecasts
| Method | Score | 95% range | Avg rank |
|---|---|---|---|
| Timestral‑209M | 0.331 | 0.24–0.44 | 3.44 |
| Timestral‑123M | 0.333 | 0.24–0.44 | 3.41 |
| Timestral‑28M | 0.337 | 0.24–0.44 | 3.63 |
| Timestral‑5M | 0.358 | 0.27–0.46 | 4.19 |
| MSTL | 0.497 | 0.37–0.65 | 6.27 |
| AutoTheta | 0.628 | 0.46–0.78 | 7.37 |
| CES | 0.644 | 0.50–0.80 | 7.45 |
| Repeat yesterday | 0.654 | 0.48–0.82 | 8.44 |
| AutoARIMA | 0.664 | 0.48–0.84 | 7.88 |
| AutoETS | 0.909 | 0.63–1.27 | 9.80 |
The top three sizes are tied: their ranges overlap completely, so we cannot separate them on this data. The best of the older methods, MSTL, lands at 0.497.
How often the 123M model was closer, forecast by forecast
Timestral‑123M was closerthe other method was closer
- AutoETS94 / 6
- Repeat yesterday92 / 8
- Repeat last value90 / 10
- AutoARIMA87 / 13
- AutoTheta84 / 16
- CES84 / 16
- MSTL75 / 25
Out of 532 forecasts. The 95% ranges run from 91–97% against AutoETS down to 68–81% against MSTL.
It found the working week on its own
On message-queue-bytes-in and message-queue-messages-in, Timestral predicted the weekend dip and the weekday peaks without being told the data has a weekly cycle. Methods that need that cycle declared up front were 4 to 13 times further out on those two series.
Nine of the series around the 10 October cutoff, forecast seven days ahead. Timestral followed the shape of most of them closely, held the daily and weekly rhythm a week out, and kept the real value inside its 80% band about 80% of the time. The ones it missed are in the edge cases below.
historywhat happenedTimestral forecast80% range
A week ahead, 76 forecasts
| Method | Score | 95% range | Avg rank |
|---|---|---|---|
| Timestral‑209M | 0.589 | 0.43–0.82 | 3.34 |
| Timestral‑123M | 0.590 | 0.44–0.82 | 3.38 |
| Timestral‑28M | 0.605 | 0.44–0.84 | 3.45 |
| Timestral‑5M | 0.647 | 0.48–0.90 | 4.57 |
| MSTL | 0.737 | 0.55–1.00 | 5.25 |
| Repeat last week | 0.817 | 0.58–1.21 | 7.17 |
| AutoTheta | 1.045 | 0.80–1.35 | 7.80 |
| AutoARIMA | 1.052 | 0.78–1.38 | 8.03 |
| AutoETS | 1.653 | 1.24–2.27 | 10.08 |
AutoARIMA and AutoETS both pass 1.0 at this range, so a week out they do worse than repeating yesterday. Timestral holds at 0.590.
The uncertainty range is honest
Timestral returns a band it expects to contain the real value 80% of the time. The real value landed inside that band between 79.6% and 81.1% of the time, at both a day and a week ahead. A band that means what it says is what makes forecast alerting workable: set a threshold at the edge of it and it fires about as often as you expect.
Which size to run
The 28M, 123M and 209M models score the same within measurement error. Only the 5M trails, losing 61% of its head-to-head forecasts against the 123M. Since the 28M is four times faster than the 123M for the same accuracy, it is the one worth starting with.
Time per forecast on a laptop CPU
| Method | Seconds |
|---|---|
| Timestral‑5M | 0.010 |
| Timestral‑28M | 0.028 |
| CES | 0.077 |
| Timestral‑123M | 0.104 |
| Timestral‑209M | 0.155 |
| MSTL | 0.673 |
| AutoETS | 2.138 |
| AutoTheta | 5.385 |
| AutoARIMA | 46.012 |
AutoARIMA only saw the last 4 weeks of each series, to keep the run finishing at all, and still took 46 seconds per series. Timestral‑123M took a tenth of a second on the same machine.
Edge cases
- Anything without precedent. A sharp drop in
cache-memory-usedand a growing backlog inmessage-queue-consumer-lagarrived in the final week, and every method missed both. - Smooth upward lines. On a cleanly growing counter AutoARIMA and a straight line match or beat it. A week ahead, MSTL and a straight line took 3 of the 19 series between them.
- Noisy series. On p99 latency and load average every method is some distance out, and the gap between them narrows to very little.
- Counters that reset. A restart at zero drags the forecast down with it, costing one series 1.40% error against 0.21% once we trimmed the history. Feed rates or differences instead.
Questions people ask about Timestral
How accurate is Timestral on production metrics?
On 19 production observability series it scored 0.333 MASE a day ahead, about half the error of repeating yesterday's value, and 0.590 a week ahead. It placed first against 12 classical and baseline methods at both horizons. The best classical method, MSTL, scored 0.497 a day ahead.
Which Timestral model size should you use?
The 28M, 123M and 209M models score the same within measurement error, so the 28M is the practical choice at 0.028 seconds per forecast. Only the 5M trails, losing 61% of its head-to-head forecasts against the 123M.
How fast is Timestral on CPU?
Between 0.010 and 0.155 seconds per forecast depending on size, on a laptop CPU with no GPU. AutoARIMA took 46 seconds per series on the same machine, and that was with its history capped at 4 weeks.
Does Timestral need configuring for seasonal data?
No. It picked up the weekday peaks and weekend dip on our message queue series with no seasonality setting. Methods that need the cycle declared up front were 4 to 13 times further out on those series.
Are Timestral forecasts reproducible?
Yes. It produces its answer in a single pass with no sampling, so the same input gives bit-identical output. We reran 36 forecasts 10 times in fresh processes and every one matched exactly.
Where does Timestral struggle?
It cannot predict events with no precedent, it is matched or beaten by AutoARIMA and a straight line on cleanly growing counters, and its margin narrows to very little on noisy series such as p99 latency. Counters that reset to zero must be fed as rates or differences.
Method and caveats
Data
19 series at hourly resolution from 25 June to 17 October 2026, with 12 to 16 weeks of history behind each forecast. 28 starting points a day apart for the day-ahead task and 4 a week apart for the week-ahead task, none of them overlapping. Dividing each series by its own average removes the volumes and leaves the shape, which is all the scoring needs. Series names describe a role in general terms and nothing more should be read into them.
One figure on this page comes from an earlier warm-up run against the OpenTelemetry Astronomy Shop Demo rather than from production: the counter-reset example in the limits above. Everything else is measured on the production series.
Scores
MASE divides the forecast's average error by the average error of repeating yesterday, measured over the history. Below 1 beats that baseline. We report the geometric mean across series, with MASE floored at 0.01, because one p99 series sits in the top bucket of its histogram and makes the naive forecast exactly right, which would otherwise leave the geometric mean undefined. WAPE, used for the counter example, is total error as a percentage of the total true value. Ranges are 95% confidence intervals from a cluster bootstrap over series, 2,000 resamples.
The other methods
Classical models come from Nixtla statsforecast 2.1.1. Gaps were filled by linear interpolation for those models and passed through as missing to Timestral, which accepts them. AutoARIMA only saw the last 4 weeks of history, because fitting it on the full series did not finish in reasonable time. AutoETS chose non-seasonal models for these long hourly series and so forecasts a flat line beyond the first day. That is the library's own model selection rather than anything we configured.