Toto-2.0: 5 Silent Failure Modes to Avoid for Full Performance (+Tutorial)

Toto-2.0 currently sits at the top of the foundation-model tier on the GIFT-Eval leaderboard. The model shows real capability across a wide range of tasks

But like any model built on architectural assumptions, Toto-2.0 has edge cases. These are not bugs. They are the result of design choices, such as patch sizes, causal scaling, decoding methods, and other decisions made during training. When your input hits one of these edge cases, the model can return a forecast that looks fine at first glance but is quietly wrong.

In this article, we walk through 5 such edge cases. For each one, we explain what triggers the behavior, what the failure looks like in practice, and how to work around it.

The goal is simple: Once you understand these limitations, you can structure your inputs to avoid them and get the full benefit of the model!

The 5 cases we cover:

1. Covariate support is narrower than it looks

2. Block decoding under-represents long-horizon uncertainty

3. The leading edge failure

4. The trailing edge failure

5. GIFT-Eval and design-time leakage

Let’s get started!

Subscribe to AI Horizon Forecast, a newsletter focusing on time series and hype-free AI research. Also, check the following notebooks on Toto-2.0:

• Edge Cases with Toto 2.0 - (This article) - Project 33

• TIME & Boom datasets (Sparse) - Project 30/ Project 31

• Retail Forecasting / Energy demand forecasting - Project 29 / Project 32

Before we start, one thing to keep in mind

Toto-2.0’s context length must be a multiple of 32 (the patch size). This is not a suggestion. The model calls:

on your raw context length in both the patch embedding and the causal scaler. Non-divisible inputs will throw an error. There is no padding helper inside forecast. Everything that follows assumes you have already trimmed your context to a multiple of 32.

Toto-2.0 is natively a multivariate forecaster.

The authors mention that exogenous variable support in the Chronos-2 sense is planned for a future release but is not yet available.

In practice, the inference API supports future-known covariates via known_dynamic inputs, and the series_id mechanism lets you determine how the model treats them. This is not shown in the quickstart notebook, but we leveraged future-known in the Retail Forecasting tutorial.

So the current API gives us 2 approaches on how to integrate covariates with panel data:

1. Full channel mixing. If we assign the same series_id to every target and every covariate, the model treats them as one multivariate system and freely mixes information across them. Good for global covariates like calendar features or macroeconomic indicators that mean the same thing to every series. This is what we did in the Retail Forecasting tutorial.

   The catch: the future-known covariates would mean the same thing to every target, e.g., calendar features. We can’t assign covariate-specific info, e.g., a store in a specific country having its own holidays.

2. Entity-isolated forecasting. If we give each panel its own series_id and tag each covariate with the same id as the target it belongs to, then store-specific promotions or country-specific holidays bind only to their own targets. The catch: panels are now isolated. Store A’s history no longer informs Store B’s forecast.