Google TimesFM-3 Now Reads Weather and Promotions, but Deployment Remains Restricted

Google TimesFM-3 now processes multiple related data streams, known future events, and 330 million parameters in a single forecasting model. That change addresses a major limitation in Google's previous approach. Earlier versions primarily projected one series from its own history.

A retailer can now combine sales with foot traffic, related products, weather forecasts, holidays, and scheduled promotions. Google says the model can use those relationships without task-specific fine-tuning. Its example anticipates an estimated 20 percent sales increase on promotion days.

The broader contest is no longer about generating a plausible line from past values. Google, Amazon, Datadog, Salesforce, and other developers are competing to build reusable forecasting models for messy operational data. Google TimesFM-3 enters that contest with strong benchmark claims, yet its pretrained weights remain restricted to noncommercial and nonproduction use.

Google TimesFM-3 Moves Beyond One Series at a Time

The central change is native multivariate forecasting, which lets one model connect a target with related signals before projecting its future.

Google Research announced TimesFM-3 on August 31, 2026. The company describes it as a zero-shot time-series foundation model. Zero-shot means it can approach a new forecasting dataset without first receiving task-specific training on that dataset.

A time series is simply a sequence of measurements arranged by time. Daily store sales, hourly server load, monthly revenue, and glucose readings are common examples. Forecasting models study earlier measurements and estimate what comes next.

Previous TimesFM releases made that process easier by supplying a pretrained model for many kinds of temporal data. However, the main model still treated each target series independently. Its direct view of the problem stopped at that series' own history.

TimesFM-2.5 could add covariates through a separate XReg regression path. Covariates are outside variables that help explain movement in a target. That addition was useful, but Google did not pretrain TimesFM-2.5 as a native multivariate forecaster.

TimesFM-3 changes the foundation itself. According to the model announcement, Google pretrained it to process targets and supporting variables together. The model can forecast several related targets simultaneously while examining connections among them.

Google divides those inputs into three useful groups. Multiple targets cover the related measurements being forecast, such as sales across several ice cream brands. Past covariates include signals available only for previous periods, such as recorded store traffic.

Past-future covariates extend across both the historical period and the forecast horizon. These inputs include events whose future values are already known. A promotion calendar, holiday schedule, planned discount, or external weather forecast can fit this category.

That distinction matters because business forecasts rarely depend on history alone. A weekly pattern cannot know that a retailer scheduled a discount next Tuesday. It also cannot infer an incoming heat wave unless another input represents it.

Google's illustrative retail example shows the difference. A univariate projection repeats a weekly sales pattern because it sees only earlier sales. TimesFM-3 forecasting also receives the future promotion schedule, so its output rises on the scheduled days.

Google says the example produces an anticipated sales increase of roughly 20 percent on each promotion day. That number illustrates the mechanism rather than proving a universal retail effect. Actual sales responses will depend on the product, store, discount, season, and customer behavior.

The release therefore concerns more than adding extra columns to a prediction request. Google trained the model to recognize relationships across columns before seeing a particular customer's dataset. That is the promise behind Google multivariate forecasting in zero-shot form.

Why Forecasting Models Need Known Future Events

A forecast becomes more useful when it can distinguish recurring history from a future intervention that managers have already planned.

Many operational decisions change the outcome being predicted. Retailers alter prices, marketers schedule campaigns, factories plan maintenance, and hospitals change staffing. A model that ignores those actions can produce a technically consistent forecast that is operationally irrelevant.

Consider a grocery chain planning inventory for frozen desserts. Historical ice cream sales can reveal seasonality, weekday patterns, and long-term growth. Related cone and syrup sales can expose demand relationships that one product series misses.

Recorded foot traffic adds evidence about earlier store activity. Weather forecasts offer information about conditions during the forecast period. Promotion schedules tell the model exactly when the retailer expects an intervention.

TimesFM-3 can examine those streams together. It does not need to pretend the planned promotion is an unexpected future surprise. It can compare earlier promotion periods with future scheduled dates and adjust the forecast accordingly.

The same structure applies outside retail. A cloud operator might forecast demand using workload history, release calendars, and maintenance schedules. An energy planner could combine load measurements with temperature forecasts and known industrial shutdowns.

Manufacturers might project sensor readings alongside production schedules. Healthcare analysts could connect measurements from several devices with known treatment events. Financial teams could examine related operating metrics instead of extrapolating one accounting line.

These cases are not identical, and a reusable model must handle large differences in scale. Website traffic can reach millions while a device sensor records small decimal values. TimesFM-3 normalizes each series so those scales do not dominate the model's internal comparisons.

Google says it pretrained the system on more than one trillion time points from real and synthetic sources. The listed sources include GIFT-Eval pretraining data, Wikipedia page views, Google Trends queries, and augmented synthetic sequences.

The model contains 330 million parameters. That makes it larger than TimesFM-2.5, which used 200 million parameters, but smaller than many general-purpose language models. Parameter count alone does not determine forecasting accuracy or deployment cost.

The more important distinction is what the model learned during pretraining. Google multivariate forecasting asks the network to transfer relationship patterns, not merely shapes within a single series. That raises the possibility of faster experiments on datasets with many connected variables.

It also changes what teams must prepare. A model cannot benefit from a promotion schedule that nobody recorded accurately. Weather data must align with the correct locations and time intervals. Targets and covariates need consistent timestamps.

Future covariates introduce another dependency. The output can only be as dependable as those future inputs. A forecast based on an inaccurate weather projection or an abandoned promotion plan inherits that error.

Teams must also avoid supplying information that would not have been available when the forecast was made. This problem is called data leakage. Leakage makes historical evaluations look better by allowing a model to see evidence from the future.

The strongest use case is therefore not automatic prediction from every available column. It is controlled forecasting with variables that have clear meanings and availability rules. TimesFM-3 reduces modeling work, but it does not remove data governance.

How TimesFM-3 Forecasting Works in One Pass

Google redesigned the forecasting path so time relationships and cross-series relationships alternate inside the same transformer.

The model begins by grouping 32 consecutive time points into a patch. Patching converts a long numerical sequence into a shorter series of tokens. It resembles the way some vision transformers process image patches instead of individual pixels.

Each target or past-only covariate receives tokens made from its historical patches. Past-future covariates use a lookahead construction. Their tokens include the current patch and future patches containing already known signals.

Those tokens enter a decoder-only transformer with 20 layers, a model dimension of 1,280, and 16 attention heads. These specifications appear on the official model card. The architecture alternates two forms of attention.

Causal temporal attention moves horizontally across time within one series. Causal means each token can inspect earlier information but not unknown future targets. This restriction helps prevent future target values from leaking into the prediction.

Full variate attention moves vertically across different series at the same time position. It allows sales tokens to examine promotion, weather, traffic, or related product signals. The model alternates these temporal and cross-series operations through its transformer stack.

That alternating pattern defines the central TimesFM-3 forecasting mechanism. One operation learns what changed over time. The next examines how the variables move together.

Google also changed how the model generates the horizon. Earlier TimesFM versions predicted one output patch and then used that result while generating the next. That autoregressive loop can accumulate errors and add latency across long horizons.

TimesFM-3 instead places masked tokens across the requested future horizon. Masked tokens act as empty positions that the network must fill. The model generates the complete forecast through one forward pass rather than an output-by-output loop.

Unknown future targets and past-only covariates remain masked. Known future signals, including scheduled promotions and holidays, stay visible. This arrangement lets the model fill the target horizon while consulting events that planners already know.

The approach draws on contiguous patch masking, a training method that hides consecutive sections of a sequence. The model learns to reconstruct those sections from their surrounding context. Google applies that principle to an entire forecasting horizon.

A single point estimate would hide substantial uncertainty. TimesFM-3 therefore produces nine quantiles at every future step, covering the 10th through 90th percentiles. Quantiles describe a range of plausible outcomes rather than one certain answer.

A retailer could use the median estimate for a base inventory plan. Lower and upper quantiles can support conservative and aggressive scenarios. The gap between them also reveals where the model expresses greater uncertainty.

Those intervals are useful only when they remain calibrated on local data. A nominal 90th percentile should behave like one during repeated real forecasts. Teams need backtesting to determine whether the reported uncertainty matches their operating environment.

Google provides code through the public TimesFM repository. The project supports univariate inputs, multiple targets, past-only covariates, and past-future covariates. PyTorch weights are available separately through Hugging Face.

The repository also includes an MLX backend for Apple silicon. Its documented examples support multivariate targets and both covariate types. That option lowers the barrier for local experimentation, although the pretrained weights still carry a restrictive license.

This architecture does not reason about business causality in the human sense. If discounts and sales historically move together, the model can use that relationship. It does not establish that a particular discount caused the increase.

Correlation can also fail after business conditions change. A promotion may underperform because a competitor cuts prices or inventory runs out. Forecast users still need operational context that no input series captures completely.

Strong Benchmarks Do Not Settle the Deployment Question

Google's reported rankings make TimesFM-3 a serious baseline, but they do not guarantee better forecasts on every private dataset.

Google evaluated the model on GIFT-Eval, FEV-Bench, and TIME. These public suites test forecasting across different datasets, frequencies, horizons, and metrics. The company reports that TimesFM-3 achieved the best average rank on all three.

The comparisons included Amazon's Chronos-2, Datadog's Toto 2.0 family, and Google's TimesFM-2.5. Google reports that TimesFM-3 performed strongly even in univariate mode. Adding cross-series information and covariates improved its average rank further.

The repository describes FEV-Bench as 100 real-world forecasting tasks. It describes TIME as 50 domain datasets and 98 evaluation tasks. GIFT-Eval supplies another broad cross-domain comparison among foundation models.

Breadth helps reduce dependence on one favorable dataset. Point and probabilistic metrics also test different qualities. Point metrics score central predictions, while probabilistic metrics examine the quality of forecast distributions.

However, the publicly summarized results use average ranks rather than one universal improvement percentage. Rank shows relative placement across tasks. It does not tell a buyer how much accuracy will improve on a particular sales catalog or server fleet.

Google also published the result itself. Independent replication will matter, especially for multivariate inputs and known future covariates. Teams need results based on their own forecast horizons, missing-data patterns, and decision costs.

Pretraining introduces another uncertainty. The model saw more than one trillion time points, including public web signals and synthetic data. That breadth can improve transfer, yet similarity between pretraining data and a downstream dataset can influence zero-shot performance.

A 2025 study on forecasting generalization found that earlier time-series foundation models weakened under some distribution shifts. Its tests used TimesFM 2.0, not TimesFM-3, so they do not invalidate Google's new results.

The study still identifies a relevant deployment risk. On one small electricity dataset, a specialized model with 49,500 parameters outperformed the much larger earlier TimesFM model after adaptation. Bigger pretraining did not erase the value of local specialization.

TimesFM-3 may handle such cases better because its architecture and training have changed. Google says its univariate mode already improves on earlier releases. Still, a new benchmark lead does not repeal the problem of domain shift.

Retail data illustrates that challenge. A model trained on broad temporal patterns may handle normal seasonality well. It can still struggle after a store relocation, assortment overhaul, competitor entry, supply disruption, or sudden change in customer behavior.

Covariates help when they represent the shift. They offer little protection when the relevant event remains unrecorded. They can also mislead the model when historical relationships stop holding.

The comparison with task-specific forecasting therefore remains the main contest. Foundation models promise faster deployment and wider reuse. Specialized models promise closer adaptation to one company's demand patterns, constraints, and loss function.

Accuracy is only one part of that decision. Teams must measure inference latency, infrastructure requirements, failure behavior, calibration, and monitoring effort. They must also decide whether a forecast can be explained well enough for inventory or financial approvals.

TimesFM-3 supplies probabilistic outputs, but quantiles are not explanations. An analyst still needs to determine why the model reacted to weather or a promotion. Controlled ablation tests can help by removing one input and measuring the change.

Backtesting should reproduce the information available at each historical cutoff. Future weather inputs should come from forecasts issued at that time, not from observations recorded afterward. Promotion schedules should reflect their earlier versions, including later cancellations.

Teams should also compare against simple baselines. Seasonal naive forecasts, linear regressions, gradient-boosted trees, and established specialized models can remain competitive. A foundation model earns its place only when it improves the operational outcome.

The Noncommercial License Creates the Immediate Pressure Point

Developers can inspect TimesFM-3 today, but most companies cannot place its default pretrained weights into a production workflow.

Google released the repository's source code under Apache 2.0. However, the TimesFM-3 pretrained weights use the separate TimesFM Non-Commercial License v1.0. The repository says those weights are restricted to noncommercial and nonproduction use.

That split matters. Source availability lets researchers inspect the implementation and run experiments. It does not grant a retailer permission to use the default weights for live replenishment or revenue planning.

Earlier TimesFM weights through version 2.5 remain under Apache 2.0. Teams can therefore encounter different rights within the same project. They need to check the license attached to the exact checkpoint they plan to use.

The restriction also shapes competitive pressure. Amazon, Datadog, Salesforce, Nixtla, IBM, and other organizations are developing reusable forecasting systems. Availability, integration, support, and licensing can outweigh a narrow benchmark lead.

Google says BigQuery integration will arrive in the coming weeks. That rollout is the first important signal to watch. It should clarify how customers access TimesFM-3 and what commercial terms govern hosted use.

BigQuery already exposes the AI.FORECAST function for TimesFM-based univariate forecasting. A native multivariate release could bring the new model closer to existing enterprise data. SQL access would also reduce the integration work required from forecasting teams.

The second signal is independent benchmark replication. Researchers should confirm results across all three evaluation suites and test difficult distribution shifts. Public comparisons should also report actual metric differences alongside average ranks.

The third signal is production evidence. Case studies should show whether covariates improve decisions such as inventory allocation, staffing, capacity planning, or anomaly preparation. Useful reports will include baseline comparisons and error costs, not only model accuracy.

A production service would strengthen Google's claim that a general forecaster can move beyond research experiments. Continued license restrictions without a commercial route would weaken that conclusion. Developers could study the model while choosing another system for deployment.

Independent results could also change the competitive picture. Consistent gains on unseen business datasets would support Google's zero-shot strategy. Mixed outcomes would reinforce the case for treating TimesFM-3 as a starting baseline rather than a final forecasting system.

The model's release still marks a meaningful technical step. Google's previous foundation model could not natively combine several targets with historical and known future signals. TimesFM-3 makes those relationships part of pretraining and inference.

That capability brings foundation forecasting closer to actual planning problems. Businesses do not experience sales, weather, traffic, discounts, and holidays as isolated timelines. Their forecasting systems should not have to ignore those connections.

Yet the future remains outside the model's control. Weather forecasts change, promotions get canceled, and customer behavior shifts. Nine quantiles can express uncertainty, but they cannot convert incomplete inputs into certainty.

For developers, the sensible next action is a controlled offline evaluation. Compare Google TimesFM-3 with the current production baseline, preserve historical information boundaries, and test forecast calibration. Then watch BigQuery for the commercial path that the downloadable weights do not currently provide.