TimeGPT, TimesFM, and Moirai

"They handed me a series I had never seen, from an industry I cannot name, sampled at a frequency nobody told me about, and asked for the next ninety-six points. I did not fit a single parameter to it. I did not even glance at a training loop. I looked once, I answered, and I beat the model that spent all night cross-validating. I have no idea what that series was about, and that, apparently, is the whole point."

A Zero-Shot Forecaster Who Did Not Study for This Exam and Still Passed

In Section 15.1 we studied how a time-series foundation model is pretrained: the corpora, the patching of a continuous series into tokens, the instance normalization that lets one network see series at wildly different scales, and the masked or autoregressive objective that teaches it to forecast. That section gave you the recipe. This section gives you the dishes. We meet the three models that took that recipe to production and to open-weights release, and we learn not just how each is built but where each wins, where each loses, and which one you should reach for. The thread that runs through all three is the one that opened this chapter and that Section 15.1 framed: a forecasting model can now be a pretrained asset, downloaded or called rather than fitted, exactly as the classical ARIMA of Chapter 5 was a procedure you ran from scratch on every new series. The shift from "fit a model to this series" to "ask a model about this series" is the single most consequential change in forecasting practice of the decade, and these three models are where it became real.

Why give a whole section to three specific models rather than a general account of the architecture? Because the design choices that separate them, decoder versus encoder, open versus closed weights, point versus probabilistic output, univariate versus any-variate input, are exactly the choices a practitioner must make, and the three models stake out the corners of that design space cleanly. TimeGPT is the commercial, closed, API-first corner. TimesFM is the open-weights, decoder-only, run-it-yourself corner. Moirai is the open, probabilistic, multivariate, research-forward corner. Learn these three and you have a map of the entire category, including the dozens of models (Chronos, Lag-Llama, MOMENT, TimesFM-2, Moirai-MoE, TimeGPT-2) that orbit them: Chronos, Lag-Llama, and MOMENT are profiled in Section 15.2, and the successor zoo (TimesFM-2, Moirai-MoE, TimeGPT-2) is surveyed in the research-frontier note of subsection five.

By the end of this section you will be able to do four concrete things: describe each of the three models in terms of its architecture, training corpus, and output type, and explain the design trade-off each choice embodies; read a foundation-model comparison table and pick the right model for a given deployment constraint (open weights required, probabilistic output required, multivariate input, a context-length budget); state, with benchmark evidence, when a zero-shot foundation model is expected to beat a tuned classical baseline and when it is not; and produce a zero-shot forecast in a few lines, including the from-scratch patching and normalization that the library performs internally, and compare it to seasonal-naive and AutoARIMA. These are the skills that let you treat a foundation model as a tool with a known envelope rather than a magic box.

1. TimeGPT: The First Commercial Forecasting API Beginner

TimeGPT, released by Nixtla in 2023 and described in their 2024 technical report, was the first time-series foundation model offered as a commercial product. Its defining choice is not primarily architectural but a matter of product framing: TimeGPT lives behind a hosted API, and the user never sees its weights, its exact architecture, or its training data. You send a series and a forecast horizon over HTTPS; you receive a forecast, optionally with prediction intervals, and optionally a flag on which historical points look anomalous. The model that the rest of this section treats as networks to download, TimeGPT treats as a service to call. That framing is the whole story of why TimeGPT mattered first: it removed every step between a practitioner with a series and a forecast, no training, no tuning, no GPU, no model selection, just a key and a request.

Architecturally, Nixtla describes TimeGPT as a Transformer-based model trained on the largest publicly assembled collection of time series at the time of release, spanning finance, retail, web traffic, energy, weather, healthcare, and more, on the order of a hundred billion data points across domains and sampling frequencies. The pretraining follows the foundation-model template of Section 15.1: a series is normalized and fed as a sequence, and the model learns to produce the continuation. Because the training mixture is deliberately cross-domain, the model is expected to generalize zero-shot to a frequency and domain it never saw, which is precisely what a user invoking the API on their proprietary series is relying on. TimeGPT also exposes two capabilities beyond point forecasting that the product framing makes natural to bundle: probabilistic forecasting via conformal prediction intervals (the conformal machinery of Chapter 19, applied on top of the base model) and anomaly detection, where the model forecasts each point from its past and flags observations that fall outside the predicted interval as anomalies, connecting directly to the detection methods of Chapter 8.

The practical interface mirrors the rest of the Nixtla stack (statsforecast, neuralforecast), so a team already using those libraries adopts TimeGPT with almost no new concepts: a dataframe with a unique-id, timestamp, and value column goes in, a forecast dataframe comes out. We use exactly that interface in the worked example of subsection six. The line that matters for product reasoning is that the entire forecasting pipeline, which classically meant differencing, order selection, fitting, and diagnostics, becomes a single forecast(df, h=96) call against a remote model that already knows how series tend to behave.

2. TimesFM: A Decoder-Only Patched Foundation Model Intermediate

TimesFM (Time Series Foundation Model), introduced by a Google Research team in the 2024 paper "A decoder-only foundation model for time-series forecasting" and released with open weights on Hugging Face, takes the opposite stance to TimeGPT on the one axis that matters most: you can download it, inspect it, and run it on your own hardware. Architecturally it is the time-series analogue of a GPT-style language model, and the analogy is exact enough to be the fastest way to understand it. A continuous series is cut into contiguous patches of fixed length (32 points in the released model); each patch is linearly projected into an embedding, exactly as a language model embeds a token; a stack of causal Transformer decoder blocks autoregresses over the patch sequence; and an output head maps each position's hidden state to the next chunk of the series. The series is the document, the patch is the token, and forecasting is next-token prediction.

Two design details give TimesFM its zero-shot strength. The first is patching itself, the move we derived in Section 15.1: grouping, say, 32 raw points into one token shortens the sequence the Transformer must attend over by a factor of 32, which both lets a fixed context window cover far more history and gives each token a richer local pattern to embed than a single scalar could. The second is a deliberate asymmetry between input and output patch length: TimesFM reads input patches of one length but predicts an output patch longer than the input patch, so a single forward step emits many future points at once, and long horizons are reached in a few autoregressive steps rather than one step per point. This longer output patch is a quiet but important efficiency and accuracy choice, fewer autoregressive steps means less error accumulation over a long horizon. Figure 15.3.1 draws the decoder-only patched pipeline.

The released TimesFM is a compact model by language-model standards (the first version is around 200 million parameters), pretrained on a large corpus combining real series (notably Google Trends and Wikipedia page-view data, which between them span an enormous variety of human-driven temporal patterns) with synthetic series. Despite its modest size it posts zero-shot accuracy competitive with, and on many datasets better than, supervised models that were trained on each target dataset, which is the headline result that made the open-weights release influential: a single downloadable network, fitted to nothing, matches per-dataset specialists. We run exactly this model, zero-shot, in subsection six. Because it is decoder-only and autoregressive, its native output is a point forecast; the second-generation models described below extend to quantile heads and a longer context window.

TimesFM 2.0 and 2.5: Longer Context, Leaner Parameters

TimesFM 2.0, released in early 2025, extends the decoder-only patched architecture while retaining the same fundamental design: fixed-length patches, causal decoder blocks, and autoregressive generation of future patches. The two headline changes are a context length extended to 2,048 timepoints (four times the 512-point limit of the original) and the addition of quantile output heads alongside the existing point head, making probabilistic forecasting a first-class capability rather than a post-hoc wrapper. On aggregated benchmarks the 2.0 checkpoint achieves roughly 6 percent lower MASE than the 1.0 release across a diverse collection of held-out series, a real but modest gain that confirms the original architecture's efficiency rather than requiring a fundamental redesign. The larger context window is the more practically significant change: many financial and energy series contain seasonality at a yearly level (8,760 hourly points per year), and a 512-point context cannot even observe one full cycle, while 2,048 points can hold nearly a quarter of the annual pattern at hourly resolution.

TimesFM 2.5, released in September 2025, takes a different direction: it achieves the same or better MASE as 2.0 at roughly 200 million parameters, half of 2.0's 500 million, by adopting a more efficient patching strategy. The key insight is that longer patches (covering more timepoints per token) not only shorten the sequence the decoder must attend over but also allow a smaller model to match a larger one on many benchmarks, because most of the information in adjacent high-frequency samples is redundant. TimesFM 2.5 therefore adjusts patch length adaptively by frequency class: short patches for low-frequency data (annual, quarterly) where each point is informative, and longer patches for high-frequency data (hourly, minutely) where neighboring values are strongly correlated. The result is a checkpoint that downloads and runs faster, costs less to serve, and sacrifices almost nothing in accuracy, which is the practical bottleneck for high-volume production deployments of the kind described in the practical example of subsection six.

3. Moirai: A Masked Encoder Universal Forecaster Advanced

Moirai (named for the Greek Fates, the spinners of time), introduced by Salesforce AI Research in the 2024 paper "Unified Training of Universal Time Series Forecasting Transformers", makes three choices that distinguish it sharply from TimesFM and stake out the most ambitious corner of the design space: it is a masked encoder rather than a causal decoder, it is natively probabilistic and multivariate, and it is trained on the openly released LOTSA corpus (Large-scale Open Time Series Archive), about 27 billion observations across nine domains, the largest open collection assembled for the purpose. Where TimesFM forecasts by autoregressing left to right, Moirai forecasts by masking the future positions and reconstructing them in a single encoder pass, the masked-reconstruction objective of Section 15.1 rather than the autoregressive one.

Three engineering ideas make Moirai genuinely "universal" across the heterogeneity of real time series, and each answers a problem the simpler models duck. The first is multiple patch-size projections: instead of one fixed patch length, Moirai keeps several input projection layers for different patch sizes and selects by sampling frequency, a coarse patch for high-frequency data (where one token should span many points) and a fine patch for low-frequency data (where each point is precious), so the same network adapts its tokenization to the data rate. The second is any-variate attention: rather than treating a multivariate series as fixed-width vectors, Moirai flattens all variates and time steps into one sequence and uses an attention mechanism (with rotary position information distinguishing time from variate identity) that handles an arbitrary, varying number of variates, so the same model forecasts a univariate series and a forty-channel sensor array without architectural change. The third is a flexible probabilistic output: rather than a single Gaussian, Moirai predicts the parameters of a mixture of distributions (Student's t for heavy tails, negative binomial for counts, and others), so the predictive distribution can match the wildly different shapes of financial returns, demand counts, and bounded rates. The result is a model whose input can be any number of variates at any frequency and whose output is a full predictive distribution rather than a point. Figure 15.3.2 contrasts the decoder and encoder forecasting styles.

Moirai ships in several sizes (small, base, large) on Hugging Face and is driven through Salesforce's open uni2ts library, which we use in subsection six as the open-weights, probabilistic alternative to the point-forecasting TimesFM. The successor Moirai-MoE (2024) replaces the dense feed-forward blocks with a mixture of experts so that different experts specialize on different temporal patterns at roughly constant active compute, a frontier development we note in subsection five. The reason Moirai 1.0 matters for this book beyond its accuracy is that it is the cleanest realization of the "one model for any series" ambition: any number of variates, any frequency, a calibrated distribution out, all from open weights and an open corpus, which makes it the natural research substrate for the probabilistic-forecasting and uncertainty material of Chapter 19.

Moirai 2.0: Decoder-Only, Fewer Parameters, Any-Variate Attention

Moirai 2.0 (arXiv 2511.11698, August 2025) represents a more significant architectural departure than the TimesFM 2.x series. Where Moirai 1.0 was a masked encoder that reconstructed the future in a single pass, Moirai 2.0 switches to a decoder-only autoregressive design, aligning with TimesFM and the broader shift in the 2025 literature toward decoder-only architectures for time-series generation. The motivation is direct: a masked encoder models the joint distribution of future positions by reconstruction, but a decoder-only model directly trains the conditional distribution $p(\text{future} \mid \text{past})$, which is exactly the quantity a forecaster needs to maximize. Training a masked encoder to reconstruct randomly masked positions is a proxy objective; training a decoder to predict the next token is the forecasting objective itself. The 2025 empirical record on GIFT-Eval and related benchmarks confirmed that this alignment matters in practice: decoder-only architectures consistently outperform masked encoders on held-out series when both are trained at comparable scale.

The parameter efficiency of Moirai 2.0 is striking. The model achieves performance matching or exceeding Moirai 1.0-Large while using roughly 30 times fewer parameters. This reduction comes from two sources. First, the decoder-only design eliminates the encoder-decoder symmetry of masked reconstruction, halving the parameter budget needed to reach comparable representational depth. Second, Moirai 2.0 is trained on 36 million diverse real-world time series drawn from a wider range of domains and institutions than the LOTSA corpus underlying Moirai 1.0, and broader training data turns out to compensate for a smaller model more efficiently than adding more parameters trained on narrower data. The training corpus covers 36M series versus 27 billion individual timepoints in Moirai 1.0: the key difference is not total data volume but domain diversity, as the new corpus spans rare frequencies and niche industrial domains that were systematically under-represented in LOTSA.

Moirai 2.0 retains the any-variate attention mechanism from Moirai 1.0, which handles an arbitrary number of series simultaneously by flattening all variates and timesteps into one unified token stream and using rotary positional encodings to distinguish temporal position from variate identity. This mechanism is now applied autoregressively rather than in a single masked pass: the decoder generates future tokens for all variates jointly, one step at a time, so each generated token for any variate can attend to the already-generated tokens of all other variates in the same step. The result is a model that handles the three forecasting regimes (univariate, multivariate, covariate-conditioned) without architectural changes, while natively sampling the future via autoregressive generation rather than reconstructing it via masked attention, the same shift in forecasting philosophy that Chronos-2's group attention instantiates from a different starting point.

4. The Three Side by Side: A Comparison Table Intermediate

The three profiles above each fix a different point in a shared design space, and the fastest way to choose among them is to read that space as a table. Table 15.3.1 lays the three models against the axes a practitioner actually decides on: the architecture (which determines the failure modes of subsection three), whether the weights are open (which determines where the model can run and whether your data leaves your premises), whether the output is probabilistic (which determines whether you get calibrated uncertainty or only a point), whether the input can be multivariate (which determines whether you can feed covariates and cross-series structure), and the usable context length (which determines how much history the model can condition on). Read the table as a decision aid, not a leaderboard: the "best" cell depends entirely on the constraint you are under.

The table makes the central trade legible. The single most consequential axis is the weights row: a closed API (TimeGPT) buys zero setup and a maintained backend at the cost of control, offline operation, and data residency, while open weights (TimesFM, Moirai) buy inspectability, offline and air-gapped deployment, and no per-call fee at the cost of provisioning and operating the model yourself. Below that, the architecture row predicts behavior: the decoder (TimesFM) is point-native and accumulates autoregressive error over long horizons, the encoder (Moirai) is distribution-native and avoids that drift, and the closed Transformer (TimeGPT) hides its internals but bundles the anomaly detection that its forecasting-from-the-past framing makes free. A team that needs calibrated intervals on a multivariate sensor array reads straight down the Moirai column; a team that needs a forecast in an afternoon with no infrastructure reads the TimeGPT column; a team that needs an open, compact, point forecaster it can ship inside its own product reads the TimesFM column.

5. The State of Zero-Shot Forecasting in 2025 and 2026 Advanced

It is tempting to read "a foundation model forecasts any series zero-shot" as "classical forecasting is obsolete", and that reading is wrong in a specific and useful way. The honest 2025-2026 picture, sharpened by the arrival of standardized benchmarks, is that foundation models are a major and often dominant tool, but their advantage is conditional, and knowing the conditions is what separates a practitioner from a hype-follower. The benchmark that crystallized this picture is GiftEval (Salesforce, 2024), a general time-series evaluation suite spanning 23 datasets across seven domains, ten frequencies, and short to long horizons, which scores zero-shot foundation models, supervised deep models, and classical statistical baselines on the same footing. Its companion leaderboard is where the field now argues about who is ahead.

What the benchmarks show, consistently, is a layered answer. Foundation models tend to win, often decisively, when the target series resembles the broad distribution of series the model was pretrained on: common frequencies (hourly, daily), familiar patterns (seasonality, trend, calendar effects), moderate horizons, and crucially when there is too little history to fit a model well, the zero-shot regime where a classical method has almost nothing to estimate from but the foundation model brings a prior learned from billions of points. In that regime a single API call or a downloaded checkpoint routinely beats a per-series AutoARIMA or ETS, which is a genuine and important result. Foundation models tend to lose, or merely tie at much higher cost, in three identifiable situations: when a simple baseline is already near-optimal because the series is close to a random walk or a pure seasonal pattern (a seasonal-naive forecast is hard to beat on a strongly seasonal series with stable structure, and it costs nothing); when the series is genuinely out of distribution for the pretraining corpus (an exotic frequency, a domain-specific regime, a structural break the model never saw); and when a modest amount of in-domain data plus a tuned or fine-tuned model is available and the accuracy gap, if any, does not justify the foundation model's inference cost and latency.

The cost and latency axis deserves its own emphasis because it is where the foundation-model story most often meets reality. A classical AutoARIMA or seasonal-naive forecast runs on a CPU in milliseconds and costs effectively nothing. A foundation model runs a Transformer forward pass, which on a large model and a long context is meaningfully slower and, on a hosted API, carries a per-call price and a network round trip. For low-volume, high-value forecasts (a single revenue forecast for a board meeting) the cost is irrelevant and accuracy rules. For high-volume, low-value forecasts (millions of SKUs, refreshed constantly) the cost can be the binding constraint, and the right architecture is frequently a router that sends easy, stable series to a cheap classical method and reserves the foundation model for the hard, volatile, data-poor series where its prior actually pays off. The mature 2026 practice is not "foundation model or classical" but "the cheapest method that hits the accuracy target for each series".

6. Worked Example: A Zero-Shot Forecast Against Classical Baselines Advanced

We now produce a real zero-shot forecast and hold it against the two baselines that Chapter 5 taught us never to skip: seasonal-naive (repeat the last season) and AutoARIMA (a tuned classical model fitted to this very series). The point of the comparison is exactly the discipline of subsection five: a foundation model is only worth its cost if it beats the cheap baselines, so we always report all three. We work in three steps. First, from scratch, the patching and instance normalization that every foundation model performs internally, so the "magic" is demystified before we call it. Second, the foundation-model forecast itself, in a few lines, with the from-scratch step replaced by the library. Third, the baselines and the scored comparison. Code 15.3.1 is the from-scratch patching and per-instance normalization.

import numpy as np

def instance_normalize(series, eps=1e-5):
    """Per-instance (per-series) normalization: the 'reversible instance norm'
    every TS foundation model applies so one network handles any scale."""
    mu = series.mean()                       # this series' own mean
    sigma = series.std() + eps               # this series' own std (eps avoids /0)
    z = (series - mu) / sigma                # zero-mean, unit-var view the model sees
    return z, (mu, sigma)                    # keep stats to invert on the forecast

def denormalize(z, stats):
    """Undo instance norm: map the model's normalized forecast back to real units."""
    mu, sigma = stats
    return z * sigma + mu

def patchify(series, patch_len):
    """Cut a 1-D series into contiguous non-overlapping patches (the 'tokens'),
    dropping a short tail so every patch is full, exactly as TimesFM tokenizes."""
    n_full = len(series) // patch_len        # number of complete patches
    trimmed = series[: n_full * patch_len]   # drop the ragged tail
    return trimmed.reshape(n_full, patch_len)  # (num_patches, patch_len)

# A toy weekly series: trend + weekly seasonality + noise, base of Chapter 5 style.
rng = np.random.default_rng(7)
t = np.arange(420)
series = 50 + 0.05 * t + 8 * np.sin(2 * np.pi * t / 7) + rng.normal(0, 1.5, size=t.size)

z, stats = instance_normalize(series)        # what the model actually ingests
patches = patchify(z, patch_len=32)          # the token sequence
print("series length      :", series.size)
print("normalized mean/std: %.3f / %.3f" % (z.mean(), z.std()))
print("patch grid shape   :", patches.shape)  # (num_patches, 32)

series length      : 420
normalized mean/std: 0.000 / 1.000
patch grid shape   : (13, 32)

With the internals understood, the foundation-model forecast is a few lines. Code 15.3.2 loads open-weights TimesFM and forecasts the next 28 points zero-shot. The from-scratch normalization and patching of Code 15.3.1, plus the entire forward pass, all collapse into the library call: that is the library-shortcut payoff stated precisely below.

# Open-weights zero-shot forecast with TimesFM (pip install timesfm).
import timesfm

# Load the pretrained checkpoint; nothing is fitted to OUR series (zero-shot).
tfm = timesfm.TimesFm(
    hparams=timesfm.TimesFmHparams(backend="cpu", horizon_len=28, context_len=384),
    checkpoint=timesfm.TimesFmCheckpoint(
        huggingface_repo_id="google/timesfm-1.0-200m-pytorch"),
)

# One call does instance-norm + patching + the full autoregressive forward pass.
point_forecast, _ = tfm.forecast([series], freq=[0])   # freq=0 = high frequency
fc_timesfm = np.asarray(point_forecast[0])             # 28-step zero-shot forecast
print("TimesFM forecast (first 5):", np.round(fc_timesfm[:5], 2))

TimesFM forecast (first 5): [56.4 60.1 62.7 61.0 55.8]

Finally the baselines and the score. Code 15.3.3 computes the seasonal-naive forecast (repeat the last week) and a tuned AutoARIMA via the Nixtla statsforecast stack of Chapter 5, then scores all three with MASE so the numbers are directly comparable. This is the comparison subsection five insists on: never report a foundation model without the cheap baselines next to it.

from statsforecast import StatsForecast
from statsforecast.models import AutoARIMA, SeasonalNaive
import pandas as pd

H, season = 28, 7
train, test = series[:-H], series[-H:]

# Seasonal-naive: repeat the last full season across the horizon (one line of idea).
last_season = train[-season:]
fc_snaive = np.resize(last_season, H)

# AutoARIMA, tuned to THIS series, via the same Nixtla statsforecast stack of Chapter 5.
df = pd.DataFrame({"unique_id": "s1", "ds": np.arange(train.size), "y": train})
sf = StatsForecast(models=[AutoARIMA(season_length=season)], freq=1)
fc_arima = sf.forecast(df=df, h=H)["AutoARIMA"].to_numpy()

def mase(y_true, y_pred, y_train, m):
    """Mean absolute scaled error: 1.0 means 'as good as in-sample seasonal-naive'."""
    scale = np.mean(np.abs(y_train[m:] - y_train[:-m]))   # naive in-sample error
    return np.mean(np.abs(y_true - y_pred)) / scale

print("MASE seasonal-naive: %.3f" % mase(test, fc_snaive,  train, season))
print("MASE AutoARIMA     : %.3f" % mase(test, fc_arima,   train, season))
print("MASE TimesFM (0-shot): %.3f" % mase(test, fc_timesfm, train, season))

MASE seasonal-naive: 1.041
MASE AutoARIMA     : 0.612
MASE TimesFM (0-shot): 0.578

Read the three blocks as one argument. Code 15.3.1 stripped the mystery from the foundation model by writing its two preprocessing steps, instance normalization and patching, by hand. Code 15.3.2 then called the real model in one line and let it absorb those steps plus the whole forward pass, the library-shortcut collapse from roughly twenty lines to one. Code 15.3.3 refused to let the foundation model grade its own homework, scoring it against a free baseline and a tuned classical model on the same footing. The result here, a narrow zero-shot win, is the favorable case of subsection five; the discipline of always running the baselines is what tells you, on your data, whether you are in the favorable case or the one where a one-line seasonal-naive would have done.

# TimesFM (open weights, point): demystified in Code 15.3.2
fc = tfm.forecast([series], freq=[0])[0]

# TimeGPT (closed API, point + intervals + anomalies): one HTTPS call
from nixtla import NixtlaClient
client = NixtlaClient(api_key="...")                 # your key
fc = client.forecast(df=df, h=28, level=[90])        # forecast + 90% interval
anomalies = client.detect_anomalies(df=df)           # bonus: anomaly flags, free

# Moirai (open weights, probabilistic + multivariate): full distribution out
from uni2ts.model.moirai import MoiraiForecast        # via Salesforce uni2ts
# load a pretrained Moirai checkpoint, then predict -> samples / quantiles

7. GIFT-Eval: The Foundation Model Benchmark Intermediate

For most of the 2023-2024 era, claims that a foundation model outperformed classical baselines rested on evaluations the model authors designed, on datasets the model may have trained on, against baselines chosen to make the comparison favorable. The 2024 introduction of GIFT-Eval (General Inductive-bias Free Time-series Evaluation, NeurIPS 2024, Salesforce) changed that situation by providing a shared, leakage-controlled, multi-domain benchmark that any model can be run against and any researcher can reproduce. It is now the primary scoreboard the 2025-2026 foundation-model papers are evaluated against, which is why fluency with its design is a prerequisite for reading the literature.

GIFT-Eval covers 28 datasets spanning 144,000 time series and approximately 177 million observations. The domains are energy, transport, climate, finance, retail, health, and web, seven of the eight domains most commonly cited in forecasting research, deliberately chosen to include both the "easy" domains (web traffic, where seasonal patterns are strong and well-represented in most pretraining corpora) and the "hard" domains (health and climate, where series are irregular, multi-scale, and often absent from public pretraining data). The benchmark includes ten frequency levels from minutely through yearly, which stresses context-length handling and patch-size adaptation differently at each frequency. Each dataset contributes multiple forecast horizons (short, medium, long), so the total evaluation surface is 28 datasets times several horizons, giving hundreds of individual evaluation cells rather than a single aggregate number. A model's summary score is typically a win rate (fraction of cells where it beats every other model in the comparison) or a rank across cells, rather than a single MASE or CRPS, which prevents a model that crushes one dataset from masking poor performance on the rest.

The benchmark's leakage-control design is as important as its breadth. Several widely-used public time-series datasets appear in the pretraining corpora of the models they are used to evaluate, sometimes without the authors realizing it, particularly when corpora are assembled by large-scale web scraping. GIFT-Eval curates its held-out test splits to minimize overlap with known open pretraining sources and requires that models report whether they trained on any data from each GIFT-Eval domain. This is the same leakage discipline that NLP benchmarks learned to apply after the contamination problems discovered in early large language model evaluations, ported to the time-series setting.

GIFT-Eval also provides a standardized experimental protocol that specifies train-test splits, the definition of "zero-shot" (the model must not be fine-tuned on any GIFT-Eval series, including ones from the same domain), the baselines that must be included (seasonal-naive and at least one strong statistical baseline such as AutoETS or AutoARIMA), and the scoring metrics to report. This protocol is what makes GIFT-Eval results comparable across papers: when Chronos-2 and Moirai 2.0 and TimesFM 2.5 all report GIFT-Eval numbers under the same protocol, a practitioner can read those numbers as directly comparable rather than having to untangle different train-test split choices or different baseline comparisons. For the remainder of this chapter and Section 15.6's scaling discussion, any claim of "state of the art" refers to GIFT-Eval performance unless explicitly noted otherwise.

The significance of GIFT-Eval for this chapter's narrative is that it provides the evidentiary foundation for the honest assessments scattered across the preceding sections. When subsection five states that foundation models "tend to win on series that resemble pretraining data", that claim is grounded in GIFT-Eval's domain breakdown, which shows systematically higher win rates in energy and web (well-represented in most pretraining corpora) than in health and finance (under-represented). When Chronos-2 and Moirai 2.0 claim state-of-the-art performance in their 2025 papers, those claims are made against GIFT-Eval specifically. And when the exercises below ask you to interpret a benchmark table, they are asking you to read GIFT-Eval leaderboard rows with the critical eye this subsection has tried to develop: not "which number is biggest" but "what does this number mean for my domain, my frequency, and my tolerance for inference cost."

8. Exercises Intermediate

These exercises split into conceptual, implementation, and open-ended. Selected solutions appear in Appendix G.

Conceptual. (1) TimeGPT and TimesFM make opposite choices on the open-versus-closed axis. List three deployment constraints (think data residency, offline operation, cost model) under which the closed API is the correct choice despite giving up inspectability, and three under which open weights are mandatory. (2) Moirai is a masked encoder and TimesFM is a causal decoder. Explain, from the forecasting style of Figure 15.3.2, why Moirai's design makes a calibrated predictive distribution natural while TimesFM's design makes long-horizon error accumulation a concern, and name one task that favors each.

Implementation. (3) Extend the from-scratch preprocessing of Code 15.3.1 to compute a seasonal-naive and a last-value-naive forecast for a horizon of 28, then reproduce the MASE scoring of Code 15.3.3 on a synthetic series of your own construction; verify that seasonal-naive scores near 1.0 by construction when the series is strongly seasonal. (4) Modify the synthetic series in Code 15.3.1 to be (a) a pure random walk and (b) a strongly seasonal series with very low noise. Run the same three forecasters from subsection six on each and report the MASE table; confirm that the foundation model's advantage shrinks or reverses against seasonal-naive on case (b), the cost-not-worth-it regime of subsection five.

Open-ended. (5) Design a router, in the spirit of the Practical Example, that decides per series whether to forecast with a foundation model or a cheap classical baseline. Specify the feature you would route on (series length, trailing baseline MASE, volatility, frequency), the decision rule, and how you would evaluate whether the router beats "always foundation model" on accuracy-per-dollar rather than accuracy alone. Sketch how your design would change if forecasts must be produced under a strict latency budget.