Time Series Foundation Models Explained: Timestral vs TimesFM-3 in Production

Every operations team forecasts something. A plant forecasts how its pumps and compressors will behave over the next shift. A retailer forecasts demand. An energy company forecasts load. For decades, each of those forecasts meant building a model for one dataset, then maintaining it as the data changed.

Time series foundation models take a different approach. They are pre-trained on very large collections of time series and can forecast data they have never seen, with no training on your side. In the space of six weeks, two of the most capable arrived:

• TimesFM-3 from Google Research, released on August 31, 2026.
• Timestral from Mistral AI, released on October 15, 2026.

This article uses the two models as case studies for three shifts in forecasting:

1. From single series to multivariate forecasting.
2. From point predictions to probabilistic forecasts.
3. From research models to deployable systems, where hardware, context length, licensing and data governance matter as much as accuracy.

Throughout, we follow one example: predictive maintenance on an industrial pump.

From ARIMA to foundation models

Classical methods such as ARIMA and exponential smoothing fit one model per series. They are fast, interpretable and hard to beat on simple seasonal signals, but every series needs its own model. Deep learning models such as DeepAR or PatchTST learn across many series, but they are usually trained from scratch for each dataset.

Foundation models bring the pre-training approach of LLMs to numbers. TimesFM-3 was pre-trained on more than a trillion time points, and most of Timestral’s training data is synthetic. You pass recent history and get a forecast back, zero-shot. These models are also far smaller than an LLM: 5 million parameters for the smallest Timestral, 330 million for TimesFM-3.

That size reflects a different task. A time series model produces calibrated predictions over thousands of readings, cheaply and repeatedly. An LLM is better at what comes after: relating a forecast to maintenance notes and explaining it. Production systems work best when each task goes to the model built for it, the argument we made in Stop Using Your LLM for Everything.

What changed in 2026

Forecasts became multivariate. A pump’s vibration, bearing temperature and discharge pressure do not move independently: a rise in one often explains or precedes a change in another. Multivariate models forecast related series jointly and learn those dependencies, instead of treating each sensor in isolation.

Covariates became native inputs. The forecast can use signals that are not themselves forecast. Both models accept past-only covariates and known-future covariates. Timestral also accepts categorical inputs, such as a machine’s planned state, directly. Google does not document categorical covariates for TimesFM-3, though Amazon’s Chronos-2 supports them as well.

Forecasts became probabilistic. Instead of saying bearing temperature will be 78 °C tomorrow, the model returns a distribution of likely values. That changes what an alert can say. If the 90th-percentile forecast crosses the alarm limit in 18 hours while the median stays below it, you have an early, quantified warning that a single number would hide.

Two ways to forecast the future: TimesFM-3 vs Timestral

Both models split each series into patches of 32 time steps, attend across time and across series, and forecast many steps in one pass. Where they differ is in how they represent the future they are asked to predict.

TimesFM-3: masked placeholders for the horizon

TimesFM-3 is a single 330M-parameter model and the first natively multivariate TimesFM. Up to version 2.5, each series was forecast from its own history only.

Its layers alternate between causal attention along time and full attention across series, and known-future covariates carry their upcoming values. To forecast, it appends masked placeholders for the whole horizon and fills them in one pass. Google calls this Contiguous Patch Masking. It replaces the patch-by-patch generation of earlier versions, which added latency and compounded errors.

Timestral: separate tokens that read the history

Timestral is a family of four models, 5M, 28M, 123M and 209M parameters, sharing one architecture and training recipe. Mistral’s main contribution is Decoupled Horizon Forecasting (DHF). Mistral argues that masked horizon values look like missing data and waste context, so DHF uses separate learned forecast tokens that read the intact history instead.

Each input also gets a role, so a production schedule can inform the forecast without leaking a target’s own future. Training was synthetic-first, followed by a mix of real and synthetic data with a context four times longer. Mistral’s technical report is still to come, so the details here come from its launch post and repository.

Benchmarks: how much better are they?

At launch, Google reported TimesFM-3 as the top foundation model on the three main public benchmarks: GIFT-Eval, fev-bench and TIME. Six weeks later, Mistral’s published evaluation put Timestral-209M slightly ahead of TimesFM-3 on every reported metric, with fewer parameters.

Read these numbers with care. The margins are small: 1.4 to 2.6% on the error metrics and 1.4 points on fev-bench. Timestral’s lead over the runner-up in Mistral’s tables, The Forecasting Company’s t0-gamma, is 0.003 on GIFT-Eval MASE.

The figures are also self-reported, Mistral’s technical report is not out yet, and the leaderboard moves fast: TimesFM-3 held first place for only six weeks. Small gaps on aggregate benchmarks don’t tell you which model will win on your data.

The more robust finding is about size. In Mistral’s results, Timestral-123M comes within 0.2% of the 209M model, and Timestral-28M beats Amazon’s Chronos-2, a model about four times larger, on GIFT-Eval and TIME. For many workloads, a small model is enough.

The wider field

Timestral and TimesFM-3 are two important recent releases, not the whole state of the art. Two others are worth knowing:

• Chronos-2 from Amazon is a 120M-parameter model with native multivariate and covariate support, including categorical covariates. It has a context of 8,192 steps and Apache 2.0 weights.
• Toto 2.0 from Datadog comes in sizes from 4M to 2.5B parameters, also under Apache 2.0. It is evaluated heavily on observability data.

What foundation models still don’t solve

Foundation models have not made forecasting a solved problem. The Toto 2.0 paper is candid about this. Classical methods still keep advantages that foundation models lack, such as clean extrapolation on simple signals, and long-horizon forecasting remains a gap.

In practice, a seasonal model can still win on a steady, repetitive signal. And any model can struggle after a regime change, such as a pump after a bearing replacement, that looks unlike anything in its context.

Can you actually deploy them?

Accuracy decides little if the model cannot run where your data lives, on your hardware, under a license you can accept.

Hardware and latency. Timestral is designed to run without a GPU. On an 8-thread server CPU, Mistral reports 17 ms with the 5M model and 113 ms with the 209M model for a one-day forecast from three weeks of 15-minute data. The 28M model is 3.6 times faster than the 209M.

TimesFM-3’s open checkpoint runs with PyTorch on GPU, or natively on Apple silicon. On an M4 Max, Google reports about 11 ms for a single series with 512 points of context. These figures come from different setups and are not directly comparable.

Context length. For a sensor sampled every 15 minutes:

• 2,048 points, BigQuery’s limit for TimesFM-3, cover about 21 days.
• 32,768 steps, Timestral’s trained length, cover about 341 days.

If the patterns you care about repeat over weeks or seasons, that difference matters more than any benchmark score.

Licensing. This is where the two models differ most. TimesFM-3’s downloadable weights are released under a non-commercial license, so production use means BigQuery. Timestral’s modified MIT license is free only for companies with up to $20 million in monthly revenue, and that limit applies to fine-tuned versions too. A model can be small, downloadable and run on a laptop, yet still be unusable for your company. The four routes below show what each option allows.

TimesFM-3 in BigQuery

For teams on Google Cloud, BigQuery is the simplest route: no model to host, and forecasts from SQL. For multivariate forecasting, the AI.FORECAST function takes target, past-covariate and future-covariate columns. Here it forecasts the pump’s three sensors for the next 24 hours:

SELECT *
FROM AI.FORECAST(
  TABLE `plant.pump_sensors_hourly`,
  model => 'TimesFM 3.0',
  timestamp_col => 'reading_ts',
  target_cols => ['vibration_mm_s', 'bearing_temp_c', 'discharge_pressure_bar'],
  past_covariate_cols => ['motor_current_a'],
  future_covariate_cols => ['planned_load_pct', 'planned_stop'],
  id_cols => ['asset_id'],
  horizon => 24,
  confidence_level => 0.9
);

One detail is easy to miss: past and future rows go in the same input table. Rows for the forecast horizon contain only timestamps and future covariates, with target and past-covariate columns set to NULL. Google’s multivariate tutorial shows the full setup. Because TimesFM-3 has no categorical input, a planned stop is encoded as a 0/1 indicator column.

From forecast to decision: a predictive maintenance pipeline

A forecast says what is likely to happen. It does not say why. When the upper band of the pump’s bearing temperature crosses its alarm limit, at least five different things are going on, and a good system keeps them apart:

1. The forecasting model predicts a likely range for each sensor.
2. The monitoring rule flags that the P90 forecast crosses a limit.
3. Maintenance records suggest what happened in similar situations before.
4. An LLM summarizes the evidence and proposes checks, clearly marked as hypotheses.
5. An engineer confirms the cause and decides what to do.

Mistral describes the same division of labor for Timestral in industrial settings: the forecasting model detects, an agent searches past failures and maintenance records, and a person gets a draft diagnosis backed by data. The step that must not be skipped is the last one. A threshold crossing is a signal to investigate, not proof of an impending failure.

Where Eden AI fits

Eden AI does not run the forecast; that stays on your infrastructure or in Google Cloud. It handles the two steps that follow, through one API key:

• Finding precedents. The rerank endpoint finds the past incidents most similar to an alert.
• Drafting the report. An LLM of your choice writes it, and switching models means changing one string.

Through the EU endpoint, both requests go only to providers cleared for EU data residency. A model that doesn’t qualify is refused rather than silently routed elsewhere. Our guide to keeping AI requests and data in Europe has the details.

The flow below forecasts three pump sensors jointly on a CPU, using the production schedule and planned machine state as known-future inputs. It calls Eden AI only when a forecast crosses an alarm limit.

import json
import numpy as np
import requests
from timestral import TimestralForecaster  # pip install git+https://github.com/mistralai/timestral.git

EDEN = "https://api.eu.edenai.run/v3"
HEADERS = {"Authorization": "Bearer YOUR_EDENAI_API_KEY"}
SIGNALS = ["vibration_mm_s", "bearing_temp_c", "discharge_pressure_bar"]
ALARM = {"vibration_mm_s": 7.1, "bearing_temp_c": 85.0, "discharge_pressure_bar": 8.5}

# 1. Forecast the next 24 hours of three sensors jointly, on CPU
model = TimestralForecaster.from_pretrained("mistralai/Timestral-28M", device="cpu")

history = np.load("pump7_sensors.npy")        # (3, 2016): three sensors, 3 weeks at 15 min
planned_load = np.load("pump7_load.npy")      # (2112,): production schedule, history + 24 h
planned_state = np.load("pump7_state.npy")    # (2112,): 0 running, 1 idle, 2 maintenance

forecast = model.forecast(
    history[None],                                         # (1, 3, 2016)
    prediction_length=96,                                  # 96 x 15 min = 24 h
    known_covariates=planned_load[None, None],             # (1, 1, 2112)
    categorical_known_covariates=planned_state[None, None],
)
median = np.asarray(forecast.median)[0]       # (3, 96)
p90 = np.asarray(forecast.quantile(0.9))[0]   # (3, 96)

# 2. Alert rule: keep only sensors whose P90 forecast crosses its alarm limit
flagged = []
for i, name in enumerate(SIGNALS):
    hours_above = float((p90[i] > ALARM[name]).sum()) * 0.25
    if hours_above > 0:
        flagged.append({
            "signal": name,
            "last_value": round(float(history[i, -1]), 2),
            "median_peak_24h": round(float(median[i].max()), 2),
            "p90_peak_24h": round(float(p90[i].max()), 2),
            "alarm_limit": ALARM[name],
            "hours_p90_above_limit": hours_above,
        })

if not flagged:
    raise SystemExit("No forecast crosses an alarm limit: no report needed.")

# 3. Find the most similar past incidents (records from your maintenance system)
incidents = [
    {"id": "WO-2291", "text": "Pump 7: bearing temperature rose over two days, lubrication found degraded."},
    {"id": "WO-2410", "text": "Pump 7: vibration spike after impeller cleaning, resolved by rebalancing."},
    # ... more work orders and incident notes for this asset
]
query = "Pump 7: " + ", ".join(f"{f['signal']} forecast above alarm limit" for f in flagged)

ranked = requests.post(f"{EDEN}/rerank", headers=HEADERS, json={
    "model": "cohere/rerank-v3.5",
    "query": query,
    "documents": [r["text"] for r in incidents],
    "top_n": 3,
}).json()
similar = [incidents[r["index"]] for r in ranked["results"]]

# 4. Ask an LLM for a draft report that separates evidence from hypotheses
system = (
    "You draft maintenance reports for engineers. Use only the forecast facts and incident "
    "records provided. Never present a root cause as confirmed. Respond in JSON with the keys: "
    "summary (string), similar_incidents (list of incident ids), "
    "hypotheses (list of strings, each starting with 'Unconfirmed:'), "
    "suggested_checks (list of strings) and needs_human_review (true)."
)
response = requests.post(f"{EDEN}/chat/completions", headers=HEADERS, json={
    "model": "mistral/mistral-large-latest",
    "response_format": {"type": "json_object"},
    "messages": [
        {"role": "system", "content": system},
        {"role": "user", "content": json.dumps({"asset": "pump_7", "forecast": flagged, "incidents": similar})},
    ],
}).json()

report = json.loads(response["choices"][0]["message"]["content"])

# json_object guarantees valid JSON, not these fields: check them in code
required = {"summary", "similar_incidents", "hypotheses", "suggested_checks", "needs_human_review"}
missing = required - report.keys()
if missing:
    raise ValueError(f"Report is missing fields: {missing}")
report["needs_human_review"] = True  # enforced by the pipeline, not left to the model
print(json.dumps(report, indent=2))

The LLM runs only on alerts, so cost follows real events, and raw sensor history never leaves your systems. Two safeguards live in the code rather than in the prompt:

• Human review is always set. The pipeline enforces it instead of relying on the model.
• The report’s fields are checked. JSON object mode guarantees valid JSON, not specific fields. On models that support it, JSON schema mode constrains the structure itself.

The report step rarely needs the largest model available. Our guide to SLMs vs LLMs in production covers how to choose.

How to evaluate a forecasting model before you trust it

Public benchmarks average hundreds of datasets, and your pumps may behave differently. Test on your own history before any forecast drives maintenance or purchasing.

1. Backtest from many starting points. Forecast from dozens of past cut-off points, using only data available at the time, and compare with what actually happened.
2. Beat simple baselines. Compare against a seasonal naive forecast (“same time last week”), your current method and at least one Apache 2.0 foundation model.
3. Score the uncertainty, not just the median. Actual values should fall inside the P10–P90 band about 80% of the time; measure it with CRPS or weighted quantile loss. If alerts use the P90, its calibration matters more than median accuracy.
4. Stress the weak spots. Break results down by horizon. Include periods after maintenance, sensor replacements or process changes, where zero-shot models can fail quietly.
5. Check leakage and cost. A known-future covariate must really be known at forecast time: a production plan is, but measured load is not. Measure latency at your real volume, across all assets.

Timestral’s small models run on a laptop CPU, so a first backtest can take an afternoon. Keep it running in production to catch drift as equipment ages.

Good to know

Benchmark figures come from Mistral’s launch post (October 15, 2026) and Google Research’s TimesFM-3 announcement (August 31, 2026); neither has been independently reproduced at the time of writing. TimesFM 3.0 is in Preview in BigQuery, and Timestral is labeled Public Preview, so interfaces, limits and licenses may change. The Python example follows the Timestral repository and Eden AI’s documentation and is meant as a starting point, not production code. License summaries reflect the published model cards as of November 3, 2026 and are not legal advice.

Further reading

Original work

• TimesFM-3: a zero-shot foundation model for multivariate forecasting, Google Research
• A decoder-only foundation model for time-series forecasting, the original TimesFM paper (ICML 2024)
• Contiguous Patch Masking, the decoding method behind TimesFM-3
• Introducing Timestral, Mistral AI, and the Timestral repository
• Toto 2.0: Time Series Forecasting Enters the Scaling Era, Datadog, including its discussion of open problems
• Chronos-2 model card, Amazon
• Public leaderboards: GIFT-Eval, fev-bench and TIME

On the Eden AI blog

• Stop Using Your LLM for Everything: The Specialized AI Models Taking Over in 2027
• EU AI Endpoint: How to Keep AI Requests and Data in Europe
• AWS Bedrock vs Azure AI Foundry vs Google Vertex AI vs Alibaba Cloud Model Studio, for the wider question of committing to one cloud

FAQ