TimesFM 3: forecasting as next token prediction

On Monday, 31 August 2026, Google Research released TimesFM 3, the third generation of its time series foundation model. It is 330 million parameters, trained on more than a trillion time points, and it forecasts zero shot: you hand it a history, it hands back a horizon, and at no stage does it train on your data.

The interesting part is not the accuracy claim, though the accuracy claim is strong. It is that the model is a decoder only transformer doing next token prediction. The machinery that predicts the next word in a sentence, pointed at numbers instead of language, is now the best published forecaster on three separate benchmarks. And the weights you would want to use are the ones you are not allowed to put in production.

Both of those facts are worth a business owner's attention, and they point in different directions.

1. What Google actually shipped

TimesFM 3 is the work of Ayush Jain and Rajat Sen at Google Research. The numbers, taken from the release rather than from commentary about it:

For scale, TimesFM 2.5 was 200 million parameters and TimesFM 2.0 was 500 million with a context of 2,048. So the line is not simply getting bigger. It got wider in what it can see, richer in what it can take as input, and it stayed small enough that the whole thing runs on hardware you already own. Three hundred and thirty million parameters is a rounding error next to a frontier language model. That matters commercially: this is not a model you rent by the token.

2. Why a forecaster looks like a language model

The design is worth understanding, because it explains both the capability and the failure modes.

TimesFM groups contiguous data points into patches of 32 time steps and treats each patch as a token. Each series is normalised on its own scale, so a warehouse moving four thousand units a week and a shop moving nine are the same shape to the model. Then it runs a transformer over that sequence of tokens. This is next token prediction. The only thing that changed is the alphabet.

Two attention mechanisms alternate through the stack. Causal attention runs along time within a single series, which is the ordinary sequence model behaviour: what happened before informs what comes next, and nothing looks forward. Full variate attention runs across series, so the model can see that your two product lines move together, or that depot demand tracks the weather station three towns over. That second axis is what makes version 3 different, and it is the part earlier versions did not have.

Decoding is the other departure. Rather than emitting one step, feeding it back in and emitting the next, TimesFM 3 uses a strategy Google calls Contiguous Patch Masking to produce the whole horizon in a single forward pass. Anyone who has watched an autoregressive forecast wander off after twenty steps, compounding its own errors, will recognise why that is worth doing.

And the output is nine quantiles rather than one number. The model does not tell you demand will be 4,120 units. It tells you there is a 10% chance it comes in under one figure and a 10% chance it comes in over another. That is the honest shape of a forecast, and it is the shape an inventory decision actually needs.

We have written before about training a foundation model on sequences that are not language, in that case card transactions. TimesFM is the same bet, made by a much larger team on a much broader corpus: that the architecture is general, and the tokens can be anything with order.

3. What is genuinely new: covariates

Multivariate forecasting is the headline, but covariate support is the feature that will change more spreadsheets.

A covariate is a signal that is not the thing you are forecasting but explains it. TimesFM 3 takes two kinds. Past covariates are known only historically, such as what the weather actually did. Future covariates are known ahead of time, such as a promotion you have already scheduled, a bank holiday, or a price change signed off for next quarter.

That second category is the one that matters. Google's own worked example is retail: a promotion calendar fed in as a future covariate, so the forecast knows the spike is coming rather than being surprised by it and then overcorrecting for a month afterwards. Every operations team we have worked with keeps that calendar somewhere. Until now, getting it into a forecast meant building a custom model. Now it is a column.

For anyone running the kind of demand and replenishment loop we described in the intelligent warehouse, this is the difference between a forecast that reacts and one that anticipates.

4. Reading the benchmark claim carefully

Google reports TimesFM 3 as the top ranked pretrained foundation model on three benchmarks: GIFT Eval, which spans 97 datasets across energy, retail, weather and finance; FEV Bench; and the Time Leaderboard. It leads on both point accuracy and probabilistic metrics, and it holds the lead even in univariate mode where its covariate advantage does not apply.

The named comparisons are Amazon's Chronos 2, an encoder only model of 120 million parameters, and Datadog's Toto 2.0 family, which runs up to 2.5 billion. TimesFM 3 sits between them on size and above both on rank, which is the genuinely impressive part of the result: it is roughly eight times smaller than the largest model it beats.

Now the caution. A benchmark rank is a statement about 97 public datasets, not about yours. Time series are unusually good at flattering a model on average and humiliating it on the one series that pays your wages. Intermittent demand, a product with nine months of history, a supply chain that changed shape in March: none of those look like the benchmark suite. Treat the leaderboard as a reason to run an evaluation, not as the evaluation.

5. The licence is the real story

Here is what most coverage of the release will bury.

The TimesFM source code is Apache 2.0, and the model weights up to version 2.5 are Apache 2.0 as well. The TimesFM 3.0 weights are not. They ship under a licence identified as timesfm-non-commercial-license-v1.0, and commercial or production use of the default pretrained weights is not permitted. You can download the model from Hugging Face today, benchmark it, write it up, and show your board a chart. You cannot put it behind a customer facing forecast.

That leaves a business with three honest options.

Use the managed 2.5. BigQuery exposes TimesFM through AI.FORECAST and AI.EVALUATE, both generally available, with AI.DETECT_ANOMALIES in public preview, currently running TimesFM 2.5 with context windows from 64 to roughly 15,000 points. AlloyDB has AI.FORECAST in preview through a Vertex endpoint. This is a genuinely underrated capability: a forecast, with intervals, from a SQL statement, over data that never leaves the warehouse. No training run, no model serving, no MLOps.

Wait for 3.0 to land in BigQuery. Google says the integration is coming in the next few weeks. When a model arrives as a managed service the licence question becomes Google's contract rather than your legal risk, which is usually the point of a managed service.

Evaluate now, decide later. Pull the weights, run them against your own history alongside your current method, and have the answer ready for the day the licence or the managed endpoint catches up. This is the option most teams should take this month, because the work is the evaluation, not the deployment.

6. The baseline nobody wants to run

Before any of that, run the baseline.

A seasonal naive forecast says next week looks like the same week last year. It takes one line of SQL, costs nothing, and beats a carelessly applied foundation model more often than anyone wants to admit. It is the number the new model has to beat, and if nobody computes it, the comparison being made is between a sophisticated forecast and a feeling.

Backtest properly while you are at it. Hold out the most recent period, forecast it without letting the model see it, and score the result the same way for both methods. If the foundation model wins by two percent on a metric nobody in the business uses, that is not a reason to change anything. If it wins by fifteen percent on forecast error at the horizon your buyers actually order against, that is a different conversation, and it usually converts straight into working capital.

7. Where forecasting meets regulation

One thing to keep straight, because forecasting is one of the places the two subjects touch.

Forecasting warehouse demand, delivery volumes or server capacity is not on the EU AI Act's Annex III high risk list, and no amount of caution changes that. Using an AI system to assess someone's creditworthiness, or to price life and health insurance risk, can sit inside it, with those obligations applying from December 2027. The model is the same transformer in both cases. What decides the compliance position is the decision the output feeds, not the architecture producing it. We set out the full classification walk in the EU AI Act 2026 guide, and the short version is that a forecast becomes regulated when it starts deciding things about people.

8. What we take from it

Three things.

The architecture question is closing. A decoder only transformer with attention across variates is now the strongest published approach to a problem that had its own specialised literature for forty years. That is the same pattern we have watched in language, vision and, as we argued in Brain blueprints of AI, in most places sequence models have been pointed.

Small models are winning a real category. Three hundred and thirty million parameters, beating a model eight times its size, running on ordinary hardware, with no per token cost. Not every useful AI system is a frontier model behind an API, and the ones that are not tend to be far easier to put into an operation.

And the constraint that decides adoption is rarely the one in the announcement. The benchmark table will get the attention. The licence file is what determines whether you can ship. That gap between what a model can do and what a business is permitted to do with it is where most AI projects quietly stall, which is why we read the licence before the leaderboard.

If you are working out whether a forecasting foundation model beats what you run today, the evaluation is a week of work and worth doing properly. Talk to us, or see how we build systems for businesses.

9. Sources

1. Google Research, TimesFM 3: a zero shot foundation model for multivariate forecasting, 31 August 2026.
2. google-research/timesfm on GitHub, for the code licence, the weight licences per version and the release notes.
3. google/timesfm-3.0-pytorch on Hugging Face, for the model card and the licence identifier.
4. Google Cloud, TimesFM models in BigQuery and AlloyDB, for AI.FORECAST, AI.EVALUATE and AI.DETECT_ANOMALIES.
5. Amazon Science, Chronos 2: from univariate to universal forecasting.
6. Datadog, Toto 2.0: time series forecasting enters the scaling era.

This paper describes a model released the day before publication, and the licensing and availability position is moving. Confirm the current licence and the BigQuery version before making a deployment decision on it.

This note sits in our Research track, alongside the foundation models and operations threads. Applied work lives in Operations, and the full library is at Research.