Google’s TimesFM-3 can forecast several related signals in one pass and use future events such as promotions or weather as inputs. That makes it far more useful than a single-series demo. The catch is easy to miss: the new model’s default weights are licensed for non-commercial use.
TimesFM-3 finally models the business around the number
Google Research released TimesFM-3 on August 31, 2026. The 330 million-parameter model was pretrained on a mixture of real and synthetic data containing more than 1 trillion time points.
The practical change is multivariate forecasting. Earlier TimesFM releases focused on the history of one series. TimesFM-3 can jointly predict multiple targets, use covariates known only in the past, and include dynamic covariates whose future values are already known.
Think about a retailer forecasting ice cream sales. Yesterday’s sales matter, but so do cone sales, foot traffic, planned promotions, holidays, and the weather forecast. A model that sees those signals together can react to the event the business already knows is coming.
The inputs are more useful when you label what is knowable
| Input type | Retail example | Forecast-time rule |
|---|---|---|
| Target | Daily sales for each product or store | Future values are unknown and must be predicted |
| Past covariate | Recorded foot traffic or yesterday’s stock level | Only historical values are supplied |
| Past-future covariate | Promotion calendar, holiday, planned price, or weather forecast | Future values are known when the prediction is made |
| Multiple target | Related brands, stores, or product categories | The model predicts them jointly and can learn cross-series relationships |
This classification is not paperwork. If you put the realized future weather into a historical test instead of the forecast that would have been available that day, you leak information and make the model look better than it was. Every backtest should preserve the information boundary that existed at prediction time.
One forward pass changes the latency question
TimesFM-3 groups observations into patches of 32 time steps. It alternates causal attention across time with full attention across the different series. The first mechanism protects the time direction. The second lets a signal at one store, product, or sensor influence another.
The model then predicts the full requested horizon in one non-autoregressive pass. It does not have to produce one future patch and feed that prediction back into the next step. Google says this reduces latency, repeated computation, and accumulated forecasting error.
For every target and forecast step, the model produces a point forecast plus nine quantiles from the 10th to the 90th percentile. That is more useful than one neat line. An operator can compare a median estimate with a conservative stock plan or a high-demand staffing case.
Google’s benchmark win is a starting point
Google reports the best average rank among the pretrained foundation models it compared on GIFT-Eval, FEV-Bench, and TIME, for both point and probabilistic forecasting. The company’s plots also show an improvement when TimesFM-3 uses full multivariate inputs instead of treating every series separately.
Those are company-run results. They deserve a reproduction on your horizon, cadence, missing-data pattern, and business loss function. A lower statistical error does not automatically reduce stockouts, overtime, or missed service levels.
- Compare against a seasonal naive baseline and your current production model.
- Backtest by time, never by randomly mixing future and past rows.
- Score the quantiles for calibration, not only the point forecast for average error.
- Translate errors into a business cost such as waste, lost sales, or staffing hours.
- Repeat the test after removing each covariate to see which data actually earns its maintenance cost.
Our review of Flower Endeavor’s frontier benchmark claims reached the same conclusion from a different domain: a score is not a deployment plan. You still need operating limits, failure behavior, cost, and a result on your own distribution.
The code is Apache. The new weights are not
This is the boundary that changes what builders can ship. The TimesFM repository code is Apache-2.0, and Google says weights through TimesFM-2.5 use Apache-2.0. The TimesFM-3.0 PyTorch model card lists the new weights under the TimesFM Non-Commercial License v1.0.
The license prohibits using those weights for a commercial purpose. Download access is not production permission. If your forecast supports a paid product, an internal commercial operation, or a customer service, do not assume the repository license covers the model artifact.
| Path | What you can do now | What remains unresolved |
|---|---|---|
| Research evaluation | Run a time-split backtest with the TimesFM-3 weights under the published terms | Confirm your specific use fits the non-commercial license |
| Commercial production | Test architecture and workflow with an approved model or older permitted weights | Obtain a commercial route for TimesFM-3 before deployment |
| BigQuery | Use TimesFM-2.5 for current univariate AI.FORECAST work | Google says TimesFM-3 integration is coming in the following weeks |
| Hosted inference | Prepare data and evaluation harnesses | Hugging Face showed no inference provider serving the model when checked |
This split between open code and restricted weights is becoming a routine due-diligence problem. Our GLM-5.3 deployment analysis focused on storage and hosted cost. TimesFM-3 puts license permission ahead of infrastructure.
A useful pilot fits on one forecast table
Pick one decision with a measurable penalty. For a retailer, that could be daily unit demand across ten stores for the next 28 days. Keep the first test small enough that you can inspect every covariate and every surprising miss.
- Choose the target series and the decision that consumes the forecast.
- Record which covariates are known only historically and which are truly known ahead of time.
- Build rolling backtests that recreate each prediction date.
- Compare point error, quantile calibration, runtime, and business cost.
- Review the license with the intended user and revenue path written down.
- Promote the workflow only when both the evidence and permission are clear.
I would test TimesFM-3 now for research and evaluation. I would not put its default weights behind a commercial forecast endpoint until Google provides a permitted route or the license changes. The capability is interesting. The permission boundary decides whether it can become a product.
Read the primary material
- Read Google Research’s TimesFM-3 announcement and architecture explanation.
- Inspect the official TimesFM repository.
- Review the TimesFM-3.0 PyTorch model card and license label.
- Read the full TimesFM Non-Commercial License v1.0 before planning deployment.
Which decision would you use for the first backtest, and what business cost would a bad forecast create?
