Chronos

Overview

Chronos is a family of pre-trained models for time-series forecasting. Its core idea is to treat a series of numbers like a sentence. The values are scaled and sliced into a fixed set of bins, each bin becomes a token, and a language-model architecture learns to predict the next tokens. After pre-training on a very large collection of series, the model can forecast a new series it has never seen, with no training on that series. This is called zero-shot forecasting.

The practical appeal is simple. Instead of building and tuning one model per dataset, you load a pre-trained model, give it the history, and sample possible futures. Because the output is a set of sampled paths, you get a probabilistic forecast: a median and a range. Chronos is a strong choice when you have many series, little history per series, or no time to tune. It is not always the best, and models trained on your own data with rich covariates, such as TFT, can win on specialized problems. It is best compared with Prophet, N-BEATS and PatchTST, and it belongs to the same wave of foundation-model thinking that has reached tabular data through TabPFN and TabICL.

What it is

Chronos is a set of pre-trained, open time-series forecasting models released by Amazon. The first release appeared in 2024, and the work was described in a paper titled "Chronos: Learning the Language of Time Series." The family comes in several sizes, from small to large, so that users can trade accuracy against speed and memory. Later releases in the family added faster variants. For the newest members, rely on the project's own documentation for details.

The central trick: values as words

Language models work on tokens from a fixed vocabulary. Time series are real numbers, not tokens. Chronos bridges the gap in two steps:

1. Scale the series so that values are on a common footing.
2. Quantize the scaled values into a fixed number of bins. Each bin has an id. The id is the token.

After this, a series looks like a sequence of integers from a small vocabulary. A standard language-model training loop, with a cross-entropy loss over tokens, can then be used without any change to the model design.

Everyday analogy

Imagine describing the daily temperature with a small alphabet: A for freezing, B for cold, C for cool, D for mild, E for warm, F for hot. A week of weather becomes a word like "CCDEEDC". Now a language model that has read millions of such words can guess what letter comes next. Chronos does this with a much finer alphabet, so that it can represent values accurately.

Zero-shot and probabilistic

• Zero-shot. The model forecasts a new series with no training on it.
• Probabilistic. The model outputs a distribution over the next token, and sampling many times gives many plausible futures. Quantiles are read from the samples.

Model sizes

The released checkpoints vary in size, from tens of millions of parameters up to several hundred million. A small model runs on a laptop CPU. The larger ones benefit from a GPU. Always check the documentation for exact sizes and for which variants are current.

Where it came from

Before foundation models, forecasting was done series by series, or with global models trained per dataset. In language and vision, large pre-trained models changed practice: one model, pre-trained once, can handle many tasks. Researchers asked whether time series could follow that path.

Earlier steps

• Global deep models. Models like N-BEATS and DeepAR-style networks trained on many series at once and showed that sharing across series helps.
• Transfer experiments. N-BEATS showed transfer from one set of series to another.
• Patch-based transformers. Models like PatchTST made transformers practical for long series and supported self-supervised pre-training.
• Language models for everything. The success of large language models raised the question of whether their architecture and training recipe could be reused for numbers.

The Chronos paper

The Chronos authors proposed a minimal approach: do not change the language model. Change only the data. Turn values into tokens with scaling and quantization, train an existing encoder-decoder language-model architecture (the T5 family) with the standard loss, and see how well it forecasts. They also had to solve a data problem: public time-series data is limited compared with text. Their answer had two parts.

1. Gather a large collection of public time series from many domains.
2. Generate synthetic series to broaden the training data. One method used Gaussian processes, mixing kernels such as periodic, linear and noise kernels to produce varied shapes. This is often called KernelSynth.

The paper reported that the models did well on many benchmark datasets, including ones not seen in training, and that adding synthetic data helped. It also found that fine-tuning on a target dataset could improve results further. Treat exact scores as belonging to the paper and the benchmark version used; they should not be quoted without the source.

Related foundation models

Chronos was one of several time-series foundation models that appeared around the same time. Others used different tokenization, such as patches with continuous inputs, or decoder-only designs. The field moves fast, and rankings change as new models arrive. The key takeaway is the approach, not any one leaderboard.

How it works

This section follows the full pipeline, from raw numbers to sampled forecasts.

Step 1: Take the context window

The model receives the most recent part of the series, called the context. If the series is longer than the maximum context, only the tail is used. Missing values are allowed in the input in the sense that they can be masked, though the details depend on the version.

Step 2: Scale

Chronos uses simple scaling, commonly mean scaling: divide every value by the mean of the absolute values in the context. This puts series of different sizes onto a similar range. Without scaling, one huge series and one tiny series would need different vocabularies.

Analogy: converting currencies to a common one before comparing prices.

Step 3: Quantize into bins

The scaled values are mapped into a fixed number of bins that cover a chosen range, with values outside the range clipped to the end bins. The number of bins is a design parameter, often in the low thousands. Each bin id is a token. A few extra special tokens exist, such as a padding token and an end-of-sequence token.

The bin width sets the precision. A narrow bin gives a fine value but needs a larger vocabulary. A wide bin is cheaper but coarser. The authors chose uniform bins for simplicity.

Step 4: Feed tokens to a language-model architecture

The token sequence enters a transformer. In the original design, this is an encoder-decoder T5-style model: the encoder reads the context tokens, and the decoder generates future tokens one at a time. The model has no special time-series layers. Position information is handled by the architecture's own mechanism.

Step 5: Train with cross-entropy

During pre-training, the model sees context tokens and must predict the next tokens. The loss is the usual cross-entropy between the predicted distribution over the vocabulary and the true next token. Because the loss is over categories, the model can represent multi-modal futures, such as "either the series jumps or it stays flat," without forcing a single average.

Analogy: a student guessing the next letter in a word. They give a probability for each letter, and they are scored on how much probability they put on the right one.

Step 6: Train on a broad mix

The training data mixes many real series and synthetic series. The aim is to expose the model to many shapes: trends, cycles, level shifts, spikes, noise levels and combinations. Augmentation methods can mix series together to make even more varied examples.

Step 7: Forecast by sampling

At inference:

1. Encode the context into tokens.
2. Let the decoder generate the next token by sampling from its predicted distribution.
3. Append the token and repeat until the horizon is covered.
4. Repeat the whole process many times to get many sample paths.
5. Convert tokens back to values (bin centers), then undo the scaling.
6. Take the median across samples as the point forecast and quantiles for intervals.

Because each path is generated autoregressively, long horizons take longer. Some later variants predict many steps at once to cut that cost.

Step 8: Optional fine-tuning

If you have lots of data from a single domain, you can fine-tune the model on it, often with a small learning rate. This can help when your data differs from the pre-training mix. Methods such as LoRA can reduce the cost of fine-tuning by training small added matrices instead of all weights.

Step 9: Evaluate

Use the same backtest as for any model: several cutoffs, time-ordered, with metrics such as MASE for point accuracy and weighted quantile loss for probabilistic accuracy. Compare with seasonal naive and a tuned local model.

Why this design works

• Shared structure. Many series share trends, cycles and noise patterns. A model pre-trained on a wide mix learns these once.
• Categorical outputs. Predicting a distribution over bins avoids committing to a shape (like Gaussian) and handles skew and jumps.
• No special architecture. Reusing a proven language-model design means mature tools, training tricks and hardware support.
• Synthetic data. It fills gaps in real data coverage and guards against the model only learning the quirks of public benchmarks.

What the design gives up

• Precision limited by bins. Fine detail is lost in quantization.
• Cost of autoregressive sampling. Many samples of long paths are expensive.
• No native covariates. The base design reads only the target series.
• Context length limits. Only the most recent window can be used.

Key concepts and terms

A worked example

This example shows how to run a pre-trained Chronos checkpoint for zero-shot forecasting, then how to evaluate it. The model name below is a placeholder for whichever checkpoint you choose.

Step one: load a pre-trained model

import torch
import pandas as pd
import numpy as np
from chronos import ChronosPipeline

pipeline = ChronosPipeline.from_pretrained(
    "example-org/chronos-small",       # placeholder id; use a real checkpoint name
    device_map="cpu",                  # or "cuda" if a GPU is available
    torch_dtype=torch.float32,
)

Check the documentation for current checkpoint names and class names, which can change between versions.

Step two: prepare the context

df = pd.read_csv("daily_visits.csv")       # columns: date, visits
series = torch.tensor(df["visits"].values, dtype=torch.float32)

context = series[-512:]                    # use the most recent 512 points
horizon = 28

The context is just a tensor of numbers. No feature engineering is needed.

Step three: sample forecasts

samples = pipeline.predict(
    context,
    prediction_length=horizon,
    num_samples=20,
)                                           # shape: [1, num_samples, horizon]

low, median, high = np.quantile(
    samples[0].numpy(), [0.1, 0.5, 0.9], axis=0
)
print(median[:5])

The median is the point forecast. The 10th and 90th percentiles form an 80 percent band. More samples give smoother quantiles but cost more time.

Step four: backtest against a baseline

def mase(y_true, y_pred, history, season=7):
    scale = np.mean(np.abs(history[season:] - history[:-season]))
    return float(np.mean(np.abs(y_true - y_pred)) / scale)

history = series[:-horizon].numpy()
actual = series[-horizon:].numpy()

samples = pipeline.predict(torch.tensor(history[-512:]), horizon, num_samples=20)
pred = np.median(samples[0].numpy(), axis=0)

naive = np.tile(history[-7:], int(np.ceil(horizon / 7)))[:horizon]

print("Chronos MASE:", mase(actual, pred, history))
print("Seasonal naive MASE:", mase(actual, naive, history))

A MASE below 1 means the model beats the naive scale on that data. Always repeat over several cutoffs, not one.

A tiny tokenization walk-through

Suppose a context is [100, 120, 110, 130].

1. Mean of absolute values: (100 + 120 + 110 + 130) / 4 = 115.
2. Scaled values: [0.87, 1.04, 0.96, 1.13].
3. Suppose the bins cover the range from 0 to 2 with 200 bins, so each bin is 0.01 wide. The ids are about [87, 104, 96, 113].
4. The model reads these ids and predicts a distribution over the next id. If it samples id 108, the bin center is about 1.085.
5. Undo scaling: 1.085 x 115 = 124.8. That is one sample of the next value.

Real models use more bins and a wider range, but the process is exactly this.

Step five: batch many series

For a thousand series, pass a list of tensors in batches, and use a GPU. Zero-shot inference is fast per series, and there is no per-series training. The cost is dominated by sampling.

Step six: decide whether to fine-tune

Adding covariates by residual stacking

A common pattern when covariates matter is to use Chronos for the base forecast and a tabular model for the leftover.

# in-sample base predictions via rolling backtest
resid = actual_hist - chronos_hist_pred

# features known in the future
X = pd.DataFrame({"dow": dates.dayofweek, "promo": promo, "price": price})

import lightgbm as lgb
gbm = lgb.LGBMRegressor(n_estimators=300, learning_rate=0.05)
gbm.fit(X_train, resid_train)

final = chronos_future_pred + gbm.predict(X_future)

This keeps the zero-shot benefits and lets a table model learn the effect of promotions and prices. Check by backtest that the residual model adds value.

Strengths and limitations

Strengths

• No per-series training. Load a model and forecast, which saves time.
• Good for new or short series. The model brings knowledge from pre-training.
• Probabilistic out of the box. Sampling gives quantiles.
• Handles varied shapes. Categorical outputs can represent skew and multi-modal futures.
• Simple recipe. Standard language-model architecture and loss.
• Scales to many series. Inference is cheap compared with fitting thousands of local models.
• Open and flexible. Sizes from small to large fit different hardware.
• Fine-tuning option. Adapt to a domain when needed.

Limitations

• Univariate focus. The base models read one target series. Covariates, static features and cross-series links are not used directly.
• Quantization error. Fine detail is limited by bin width, and extreme values can be clipped.
• Autoregressive sampling cost. Long horizons and many samples take time.
• Black box. There are no components like trend or seasonality to inspect, unlike Prophet.
• Context limit. Very long histories are truncated.
• Domain shift risk. If your data is unlike anything in pre-training, zero-shot quality can drop.
• Event blindness. Holidays, promotions and shocks that are not visible in the history cannot be anticipated.
• Benchmark leakage worries. As with any pre-trained model, check whether evaluation data may overlap with pre-training data before trusting reported numbers.
• Moving target. New versions and competitor models appear often, so comparisons age quickly.

How it compares with alternatives

A fair approach is to treat Chronos as a strong default and a strong baseline. If a tuned local or global model cannot beat it, there is little reason to add complexity. If a model with covariates clearly beats it, use that, or combine the two.

Role in tabular foundation models

Chronos is a time-series foundation model, and it shares a family resemblance with foundation models for tables. Looking at the two side by side makes the ideas clearer.

Rows, columns and tokens

A tabular foundation model reads a table with rows and columns. Chronos reads a single column over time. Chronos turns numbers into tokens by scaling and binning. Several tabular models also turn numeric cells into tokens or embeddings (see data tokenization and tokenizer training). The trade-off is the same in both worlds: binning gives a clean vocabulary and a categorical loss but loses fine precision, while continuous embeddings keep precision but need regression-style heads.

Mixed types

Chronos only sees numbers from one series. Real tables mix numeric, categorical, date and text columns. A table-native model such as TabICL, TabPFN or FT-Transformer handles these natively. In a pipeline, Chronos can act as a feature generator for the time-based numeric columns: its forecast or its encoder embedding becomes a new column in the table, which the table model then uses with the categorical data.

Missing values

Chronos can accept masked values in its context, and the categorical output design is tolerant of messy inputs. Still, a long run of gaps weakens the forecast. Tabular foundation models are often pre-trained with random masking so that missing cells are normal inputs. For general fill-in methods, see imputation networks.

No column names

Chronos has no concept of names at all. It looks at values only. This is the same name-blind property that is tested in tabular foundation models: if the model works well on anonymized columns, it has learned structure rather than relying on header text.

Pre-training on synthetic or real data

This is the most direct link. Chronos pre-trains on a large mix of real series and synthetic series generated from Gaussian process kernel mixtures. Tabular foundation models such as TabPFN follow the same philosophy for tables: pre-train on many synthetic datasets drawn from random data-generating processes, so the model learns general rules for prediction, then apply it to a real table in a single forward pass. In both cases, the quality of the synthetic generator matters a great deal. Too narrow, and the model fails on real data. Too wide and unrealistic, and capacity is wasted. See synthetic data generation.

In-context learning

Zero-shot forecasting in Chronos is a close cousin of in-context learning: the model adapts to a new series using only what is in its input window, with no weight updates. Tabular in-context learners go one step further by taking labeled example rows as part of the input, then predicting labels for new rows. In both cases the model has learned during pre-training how to learn from a context. See few-shot learning and zero-shot learning.

Continual learning

A pre-trained model like Chronos does not need to be retrained as new data arrives, because new data simply enters the context. That is a natural form of continual adaptation. When the world changes in ways the context cannot show, fine-tuning is needed, and then the usual concerns apply: avoid forgetting, keep a replay of older data and validate on both old and new regimes. See transfer learning and LoRA for lightweight adaptation.

Imputation

Forecasting and imputation are linked: predicting the next values is like filling in a future gap. Chronos can be used to fill the end of a series. To fill gaps in the middle, one can run the model forward from the left side and, with some care, backward from the right side, then blend. For many columns with scattered gaps, a table-native imputer is more suitable.

Anomaly detection

Because Chronos gives a predictive distribution, a value far outside the sampled range is a candidate anomaly. This needs no training, which makes it a quick screen across many series. Combine it with domain rules to keep false alarms low. See anomaly detection and predictive maintenance.

Sector and semantic classification

The encoder's hidden states can serve as embeddings of the series shape. A small classifier on these embeddings can label series by type or sector. In a table, a foundation model that reads column values can infer a column's role directly. Both approaches rely on pre-training to build a general sense of what data looks like.

For more on how foundation models for tabular data are designed and measured, see /model/architecture, /model/research and /model/benchmarks.

The bottom line

Chronos and tabular foundation models share one big bet: broad pre-training, often with synthetic data, can replace per-dataset training. Chronos applies it to one column over time. Tabular models apply it to whole tables.

Practical guidance and best practices

Choosing a checkpoint

• Start with a small checkpoint to validate the workflow.
• Move to a larger one if accuracy gains justify the cost.
• Consider faster variants if latency matters.
• Check the license and the documentation for the current model list.

Preparing data

• Provide a clean, regular series at the right frequency.
• Use enough context to cover at least a couple of cycles.
• Mark missing values rather than filling with zeros.
• Do not scale yourself unless you also handle the inverse.
• Remove obvious data errors, such as a sensor stuck at a constant value.

Sampling settings

• Use at least 20 samples for stable quantiles. Use more for tail risk.
• Use a moderate temperature and top-k setting, or the defaults.
• Keep prediction length reasonable. Very long horizons accumulate sampling noise.
• Fix a random seed for reproducible reports.

Evaluation

• Backtest over multiple cutoffs.
• Compare with seasonal naive, a local statistical model and, if relevant, a trained global model.
• Use both point and probabilistic metrics.
• Check interval coverage.
• Check the evaluation set against the pre-training sources to avoid overlap.

Combining with other models

• Use Chronos output as a feature in a LightGBM or XGBoost model.
• Use residual stacking when covariates are important.
• Ensemble Chronos with a local model such as Prophet or ARIMA. Simple averages often help.

Deployment

• Batch requests to use the hardware well.
• Cache context encodings if the same series is queried often.
• Quantize model weights if memory is tight, using tools like bitsandbytes.
• Export or serve through a stable runtime. See ONNX Runtime for portable inference.
• Log inputs and outputs so you can audit forecasts.
• Monitor error over time and compare with a baseline.

A simple decision guide

Governance

• Record the model version, checkpoint and sampling settings with every forecast.
• Keep a human review step for high-stakes decisions.
• Communicate uncertainty with the band, not just the median.

Common mistakes

1. Assuming zero-shot is always best. A tuned model with covariates can beat it on specific problems.
2. Judging from one window. A single backtest cutoff says little.
3. Ignoring benchmark overlap. Public datasets may appear in pre-training, which inflates scores.
4. Too few samples. Quantiles from five samples are noisy.
5. Feeding irregular or mixed-frequency data. The model assumes a regular grid.
6. Using it for intermittent demand without checks. Series with mostly zeros may behave poorly.
7. Forgetting events. The model cannot know about a promotion unless it shows in the history.
8. Over-trusting the interval. Coverage must be checked on your data.
9. Not versioning the checkpoint. Results change when models change.
10. Fine-tuning on tiny data. It can overfit and hurt the pre-trained skill.
11. Clipping extremes. Values far outside the bin range get squashed. Check series with huge spikes.
12. Skipping simple baselines. Without seasonal naive, you cannot judge the gain.

Frequently asked questions

What is Chronos?

Chronos is a family of pre-trained time-series forecasting models that turn numeric values into tokens and use a language-model architecture to predict the next tokens. It can forecast new series without training on them, and it produces probabilistic forecasts through sampling.

What does zero-shot forecasting mean?

It means the model forecasts a series it has never seen, using only the recent history you give it as context. No training or tuning on that series is needed. The model relies on patterns it learned during pre-training on a large and varied set of series.

How does Chronos turn numbers into tokens?

It first scales the series, usually by dividing by the mean of the absolute values. It then maps each scaled value to one of a fixed number of bins. The id of the bin is the token. The reverse process maps a predicted token back to a bin center and undoes the scaling.

Is Chronos better than Prophet?

It depends on the data. On many benchmark sets, pre-trained models like Chronos do very well without tuning. Prophet remains useful when you need clear trend, seasonality and holiday components and have a single calendar-driven series. A backtest on your own data is the right way to decide.

Can Chronos use extra variables such as price or promotions?

The base models read only the target series. To use extra variables, you can fit a second model on the residuals with those variables as features, or use a model designed for covariates, such as TFT. Some newer variants may add covariate support, so check the current documentation.

How are prediction intervals produced?

The model generates many sample paths by sampling tokens, and quantiles are computed across the samples. For example, the 10th and 90th percentiles of the samples give an 80 percent band. More samples give smoother estimates.

Why use synthetic data in pre-training?

Real public time-series data is limited and uneven. Synthetic series from programs, such as mixtures of Gaussian process kernels, add variety in shapes and noise, which helps the model generalize. It also reduces the chance that the model only learns the quirks of a few public datasets.

Do I need a GPU?

Small checkpoints can run on a CPU, which is fine for a few series. For thousands of series, long horizons or larger checkpoints, a GPU speeds things up a great deal. Sampling many paths is the main cost.

Can I fine-tune Chronos?

Yes. Fine-tuning on a domain dataset can improve accuracy when your data differs from the pre-training mix. Use a small learning rate, hold out a time-ordered validation set, and consider lightweight methods such as LoRA to save memory.

How does Chronos relate to tabular foundation models?

They share the idea of broad pre-training, often with synthetic data, followed by adaptation from context instead of per-dataset training. Chronos applies this to a single series over time, while tabular models such as TabPFN apply it to whole tables with mixed columns. The two can be combined in a pipeline.

Glossary

• Autoregressive generation. Producing one token at a time, each based on the earlier ones.
• Bin. A small range of values that maps to one token.
• Context length. The number of past steps the model reads.
• Cross-entropy. A loss for predicting categories.
• Foundation model. A large pre-trained model reused for many tasks.
• Gaussian process. A flexible statistical model for smooth random functions.
• Horizon. The number of future steps to predict.
• KernelSynth. A method of generating synthetic series by combining Gaussian process kernels.
• MASE. Mean absolute scaled error.
• Quantile. A value below which a given share of outcomes fall.
• Quantization. Mapping continuous values to a finite set of levels.
• Sample path. One simulated future series.
• T5. An encoder-decoder transformer family.
• Token. A discrete unit of model input or output.
• Zero-shot. Predicting without any training on the target data.

Summary

Chronos brings the foundation-model recipe to forecasting. It scales and quantizes values into tokens, trains a standard language-model architecture on a wide mix of real and synthetic series, and then forecasts new series zero-shot by sampling possible futures. The result is a quick, probabilistic, low-effort forecaster that is a strong default for many series and a hard baseline to beat.

Its weaknesses are limited use of covariates, quantization error, the cost of sampling, little interpretability and the need to guard against benchmark overlap. For tabular foundation models, Chronos is a close relative: it shares the bet on synthetic pre-training, in-context adaptation and name-blind inputs, but works on one column over time instead of a whole table. Use it as a first model, compare it with Prophet, N-BEATS, PatchTST and TFT, and combine it with table models when covariates matter.

Related

It belongs to Forecasting and tasks in my stack, under Foundation models and applied ML. Others in the same group: