TimesFM 3.0 adds multivariate forecasts but changes the licensing decision

TimesFM 3.0 adds multivariate forecasts but changes the licensing decision

TimesFM 3.0 adds native multivariate forecasts, but its downloadable weights are not licensed for commercial production use. The Google Research, GitHub project identifies 3.0 as its latest model. Google describes a 330-million-parameter model pretrained on more than one trillion real-world and synthetic time points, with support for related targets, past-only covariates and known-future covariates. These are the current model’s documented capabilities, separate from the commercial-use rights for a downloaded checkpoint. (Google Research’s TimesFM-3 announcement)

The change gives a team two decisions to make. First, does modelling related series or future inputs improve the forecast on its own data? Second, which deployment path permits the intended use? A research checkpoint can be technically suitable while its licence rules out the production workload.

Separate the model generations

The original TimesFM was a decoder-only forecasting model that represented a series as patches and generated forecasts without training a new model for each dataset. The paper is the source for that initial method, with input patches of 32 points and output patches of 128 points. (Das et al., ICML 2024) The ICML 2024 poster presents the original model’s results against its contemporary baselines; it does not report a current model ranking.

The original Google Research blog describes training on 100 billion real-world time points. Those figures describe the first generation. Google’s current 3.0 announcement reports a different corpus and architecture.

The Google Research, Hugging Face card identifies the timesfm-2.5-200m checkpoint and shows an optional continuous quantile head, with context and horizon as configuration fields. These are useful version-specific inputs to an evaluation. They should not be applied to 3.0 by assuming that the package name defines a single unchanging model.

What native multivariate forecasting changes

Google describes 3.0 as jointly forecasting multiple related series, rather than treating each target independently. Its transformer alternates causal attention across time with attention across variates. Known-future covariates can remain visible in the forecast horizon, while unknown target values are masked. The model generates the horizon in one forward pass and predicts nine quantiles per target at each horizon step. (Google Research’s TimesFM-3 announcement)

A retailer could, for example, evaluate sales forecasts with a planned promotion schedule as a known-future input. The useful distinction is whether that schedule would actually have been available at the forecast origin. A historical backtest that passes a revised promotion plan or a realized future measurement can introduce leakage even when the model architecture uses causal temporal attention.

Freeze the information available at each forecast date before comparing errors. Keep target histories, past-only covariates, known-future inputs and related series separate in the data contract. Then test whether each additional input produces a useful change in the metric that drives the decision.

Read benchmark comparisons as versioned experiments

Google reports strong TimesFM 3.0 results on GIFT-Eval, FEV-Bench and TIME, including separate univariate and multivariate modes. Those vendor-reported results are evidence about the configurations tested. A team should still reproduce a fixed comparison on its own horizon, data splits and covariate availability.

Chronos-2 offers a concrete example of the time boundary. Its paper describes group attention for sharing information among related series, variates and covariates, and its evaluated comparison set includes TimesFM-2.5. It does not establish a current ordering against TimesFM 3.0. (Shchur et al., Chronos-2)

Moirai 2.0 is another distinct experiment. Its paper describes a decoder-only model trained on 36 million series, using quantile forecasting and multi-token prediction. That supports including the identified checkpoint in a relevant evaluation; it does not support a general claim about its position on every multivariate or long-horizon workload. (Aksu et al., Moirai 2.0)

Keep the comparison artifacts stable: checkpoint, input interface, horizon, sampling or decoding settings, metric and compute environment. A chart that compares TimesFM 2.5 with Chronos-2 cannot be silently relabelled as a TimesFM 3.0 result. A univariate score also cannot settle a question whose intended benefit is cross-series information or known-future covariates.

Check the licence before choosing the deployment

The project distinguishes its Apache-2.0 source code, Apache-2.0 weights through version 2.5, and the separately licensed downloaded 3.0 checkpoint. The TimesFM 3.0 license permits non-commercial, non-production use and excludes commercial or production deployment without a separate licence. The permission check also applies before a benchmark. Non-production tests whose results inform a commercial purchase or production decision are outside this non-commercial grant.

The public Uber timesfm-fork establishes that an external fork exists. It does not establish the version used in an internal deployment, workload volume or commercial rights for downloaded 3.0 weights. Public code, a familiar repository owner and a benchmark score do not replace the licence text.

For commercial production, the current BigQuery TimesFM documentation explicitly says that use within BigQuery is governed by Google Cloud terms and allows commercial use; the downloaded-weight restriction applies to self-hosted downloads. The same page documents AI.FORECAST, AI.EVALUATE and AI.DETECT_ANOMALIES and distinguishes multivariate tutorials marked preview. Check the feature’s status and applicable service terms for the intended deployment.

The Google Cloud TimesFM launch announcement describes a 2025 integration milestone. It is a dated product announcement rather than authority for today’s status of every model generation and function. Implement against current documentation and the model actually exposed by the service.

Measure uncertainty as well as point error

A quantile head provides estimates to evaluate; it does not demonstrate that their empirical coverage is correct on a new dataset. In Beyond Accuracy, Adler, Chang, Draxler, Abdi and Smyth study calibration properties of time-series foundation models, including how prediction heads affect calibration. The paper gives a reason to measure interval coverage alongside point error, without treating its results as a guarantee about TimesFM 3.0. (Adler et al., Beyond Accuracy)

TimesFM fits the foundation model thesis: a pretrained model can be evaluated on a new series before task-specific training. To make that evaluation useful, record:

• forecast origin dates and the horizon;
• which inputs were genuinely available at each origin;
• related-series grouping and handling of missing values;
• point-error and interval-coverage metrics;
• checkpoint, runtime and inference settings; and
• the licence and deployment route for each candidate.

Use rolling holdouts that resemble the operational decision window. Compare the model with a baseline the service could actually run, and retain results by workload rather than only an aggregate rank. When quantiles drive inventory, risk or staffing choices, a plausible point forecast with poorly calibrated intervals can still make the system unsuitable.

For a non-production evaluation, downloaded 3.0 weights can help answer whether multivariate structure and future inputs are useful. For production, that technical result must be paired with terms that permit the workload, such as the documented BigQuery route or a separately obtained licence. Neither decision can be inferred from the older checkpoint’s licence or its place in a historical benchmark.