Chronos Forecasting: Amazon's Pretrained Time Series Models

What Chronos forecasting solves, and for whom

Most forecasting projects start the same way: collect history per series, fit a model per series or a global model across them, then spend weeks on feature engineering and tuning. Chronos replaces that with a pretrained model that produces forecasts from the raw history alone. The README describes the package as an interface to a family of pretrained time series forecasting models, and the headline property is zero-shot use: no fitting step on your data.

The intended user is a Python engineer or data scientist who already has a pandas DataFrame of time series and wants a forecast without building a pipeline. The package targets three task shapes. Univariate forecasting takes one series at a time. Multivariate forecasting models several related series jointly. Covariate-informed forecasting accepts exogenous features alongside the target. Chronos-2 is the version that covers all three; the older Chronos and Chronos-Bolt models are univariate.

It is not a general AutoML system. There is no built-in hyperparameter search, no automatic seasonality detection layer, and no evaluation harness in this repository. The README points to fev, a separate lightweight benchmarking package, for that work. If your job is to compare twenty models on a fixed backtest, Chronos gives you one of the twenty, not the comparison.

How Chronos-2, Chronos-Bolt and the original Chronos differ

The three model families in the README use different mechanisms, and the difference matters more than the parameter counts.

The original Chronos models are language-model architectures. A time series is scaled and quantized into a sequence of tokens, and a language model is trained on those tokens with a cross-entropy loss. Forecasts come from sampling multiple future trajectories conditioned on the historical context, which is what makes the output probabilistic rather than a single point estimate.

Chronos-Bolt is patch-based. The historical context is chunked into patches of multiple observations, the encoder consumes those patches, and the decoder directly emits quantile forecasts across multiple future steps. The README calls this direct multi-step forecasting and states that Bolt models are up to 250 times faster and 20 times more memory efficient than the original Chronos models of the same size, with 5% lower error.

Chronos-2 is the newest. The README states it offers zero-shot support for univariate, multivariate and covariate-informed tasks, reports state-of-the-art zero-shot results on fev-bench and GIFT-Eval, and claims a win rate above 90% against Chronos-Bolt in head-to-head comparisons. Those numbers come from the project's own benchmarks; treat them as vendor-reported until you reproduce them on your data.

The practical consequence: if you only need univariate point forecasts and care about latency, a Bolt model is the smaller commitment. If you have exogenous regressors or several correlated series, Chronos-2 is the only family member the README documents for that.

Installing chronos-forecasting and running a first forecast

The README gives a single install command. The package is published on PyPI as chronos-forecasting, so pip resolves it directly:

pip install chronos-forecasting

The package requires Python 3.10 or newer, according to pyproject.toml. Its runtime dependencies are torch (>=2.2,<3), transformers (>=4.41,<6), accelerate (>=1.1.0,<2), numpy (>=1.21,<3), einops (>=0.7.0,<1) and pandas (>=2.0,<4). Because torch is a dependency, the first install pulls a large wheel; on a CPU-only machine expect the install to take noticeably longer than a pure-Python package.

The README's minimal example imports pandas and the Chr class from chronos. Note the pandas extra the README requests in the comment: pip install 'pandas[pyarrow]'. The example is written for Chronos-2, so the model ID you pass is amazon/chronos-2. Weights come from Hugging Face, and the first call downloads them.

import pandas as pd  # requires: pip install 'pandas[pyarrow]'
from chronos import Chr

What you should see: the import succeeds once chronos-forecasting and its dependencies are installed, and the model weights are fetched from the Hugging Face Hub the first time you load a checkpoint such as amazon/chronos-2. The README's example is truncated at the import line, so the exact predict signature is not reproduced here. Read notebooks/chronos-2-quickstart.ipynb in the repository for the full call, including how the context DataFrame is shaped and what columns the forecast output carries.

Two optional extras are declared in pyproject.toml: an extras group that adds boto3, peft, fev and the pandas pyarrow extra, and a test group with pytest. If you want the benchmarking package in the same environment, install the extras rather than adding fev by hand.

Where the documentation stops and the repository takes over

The README is a launch page, not a manual. It lists model IDs and parameter counts, gives one install command, and shows a truncated snippet. It does not document the predict API, the expected input schema beyond a pandas DataFrame, how to handle missing values or irregular timestamps, or how to select quantile levels for the probabilistic output.

The repository layout fills some of that gap. There is a notebooks directory, and the README links two notebooks by path: notebooks/chronos-2-quickstart.ipynb for getting started and notebooks/deploy-chronos-to-amazon-sagemaker.ipynb for deployment. There is a scripts directory, a src/chronos package directory, a test directory and a ci directory. If you are evaluating the project seriously, the notebooks are the real documentation, and the README does not say so.

Fine-tuning is the sharpest gap. The README describes Chronos-2 as a pretrained model and never walks through adapting it to a private dataset. The extras group includes peft, a parameter-efficient fine-tuning library, which suggests the maintainers expect that workflow, but the README does not present a recipe. Anyone whose series look nothing like the pretraining corpora should confirm what the repository actually supports before committing to it.

Maintenance signals are visible in the release list. v2.3.2 was published on 2026-09-08, the same day as the last push, and v2.3.0 and v2.3.1 landed in June and July 2026. The repository is not archived. That is a release cadence, not a support contract, and the README does not describe a deprecation policy for the older Chronos and Chronos-Bolt model IDs.

Licence terms and what upgrading costs

The project is Apache-2.0. The LICENSE file sits at the repository root and pyproject.toml declares license = { file = "LICENSE" }, with an Apache Software License classifier. Apache-2.0 permits commercial use and modification and includes a patent grant. It also requires that you keep the licence and notice files with redistributed copies; the repository carries a NOTICE file for that purpose. This is a description of the licence text, not legal advice. If you redistribute the package inside a product, have counsel read the NOTICE file.

Model weights are a separate question from code. The README links model IDs on the Hugging Face Hub, including amazon/chronos-2, autogluon/chronos-2-synth, autogluon/chronos-2-small and the Bolt and T5 families, but it does not state the licence of the weights. Check the model card for each ID you use; the code licence does not automatically cover them.

Upgrade cost is bounded by the dependency pins. transformers is constrained to >=4.41,<6 and torch to >=2.2,<3, so a major transformers release will require a package update before you can move. Chronos-2 is a distinct architecture from the T5-based Chronos models, so migrating from chronos-t5-base to amazon/chronos-2 is a code change, not a version bump. The README claims a win rate above 90% for Chronos-2 against Chronos-Bolt, which is an argument for migrating, but you would be changing model ID and possibly input schema at once.

A real alternative, and the difference in approach

The obvious alternative is a classical statistical or gradient-boosted forecaster that you fit yourself, such as an ARIMA or ETS model per series, or a global gradient-boosted model over engineered lag features. The difference is not accuracy on a leaderboard; it is where the work happens.

A fitted model learns from your history. It can absorb your specific seasonality, your holiday calendar and your structural breaks, provided you encode them. It also needs enough history per series, a training run, and a retraining schedule as the series drift. Chronos inverts this. You download a pretrained checkpoint and forecast immediately. The cost moves from training compute and feature engineering to inference compute and a large model download, and the model's behaviour is fixed by its pretraining data rather than yours.

That inversion is the whole trade. For a handful of long, well-understood series with strong annual patterns, a fitted model with an explicit seasonal term is often easier to reason about and to explain to a stakeholder. For hundreds or thousands of short series where you cannot afford to fit and maintain a model per series, zero-shot inference is the pragmatic choice. The README's own framing points at the second case: it presents Chronos-2 as a pretrained model with zero-shot support across task types, not as a tuned solution for one dataset.

A middle path exists in the same ecosystem. AutoGluon, linked from the README's deployment notes, combines model families and can include Chronos as a component. The README does not document that integration in detail, so treat it as a pointer rather than a documented workflow.

Deploying Chronos-2 beyond a notebook

The README is explicit that production deployment is expected on AWS. It recommends two paths. AutoGluon-Cloud is described as the recommended option: a high-level Python API where pandas DataFrames go in and forecasts come out, with real-time, serverless and batch inference available. The README says this takes three lines of code and links a deployment guide at auto.gluon.ai. The second path is Amazon SageMaker JumpStart, which the README describes as production-ready real-time endpoints on CPU or GPU, with a tutorial notebook at notebooks/deploy-chronos-to-amazon-sagemaker.ipynb.

Neither path is a self-hosting guide. If you run outside AWS, the README does not describe a serving layer, a container image, or a REST API. You would be writing that yourself around the Python pipeline, and you would own batching, concurrency and the model cache. The extras group's boto3 dependency is consistent with the AWS-first framing.

Sizing is the other unwritten part. The README lists parameter counts from 8M for chronos-t5-tiny up to 710M for chronos-t5-large, with Chronos-2 at 120M and a smaller autogluon/chronos-2-small at 28M. It does not give memory or latency figures for any of them, beyond the relative claim that Bolt is up to 250 times faster than the original Chronos at the same size. Measure on your own hardware before you pick a checkpoint.

Editorial conclusion

Adopt Chronos if you need a zero-shot baseline over many series and can accept the model download and the Apache-2.0 terms. Do not adopt it if you need documented fine-tuning, a built-in evaluation harness, or a non-AWS production serving path. Verify the pinned transformers range and the Python 3.10 floor before installing.

Frequently asked questions

Official sources

1. amazon-science/chronos-forecasting on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases