granite-tsfm: notebooks and utilities for the Granite time series models

The weights live on Hugging Face, the notebooks live here

The most useful thing to know about granite-tsfm is what it is not. It is not a model release. The project describes itself as public notebooks, utilities and serving components for working with Time Series Foundation Models, and it points to a granite time series collection on Hugging Face where the core TSFM time series models have been made available. The model code itself is part of the Hugging Face transformers library, and the repository notice says the intention is to make Granite TimeSeries components that shipped in that library easier to use and to demonstrate. In other words, this is a workbench repository, not a weights repository. The primary language recorded for it is Jupyter Notebook, and that is where most of the effort went. Anyone arriving from a model card will find the implementation surface in another library, and this repository is the path to running it. The audience is an engineer who needs a forecasting or finetuning baseline on real time series data and would rather start from a notebook that already runs than from a configuration file.

Dependency ranges narrow the set of environments that work

The distribution is named granite-tsfm, and its version is not written by hand. The packaging file marks the version as dynamic and configures setuptools-scm to write it into tsfm_public/_version.py, so a build from a git checkout reports a version derived from the commit rather than a pinned string. The interesting part for an adopter is the range of pinned dependencies. transformers is required at 4.57.6 or newer and below 6, torch at 2.10 or newer and below 2.12, numpy below 3, scikit-learn below 1.8, pandas at 2.3.3 or newer and below 4. filelock sits at 3.20.3 or newer and einops at 0.7 or newer, with datasets, deprecated and urllib3 also on the list. That urllib3 requirement is annotated in the file with a link to a GitHub security advisory, which tells you the upper bounds are deliberate rather than accidental. The cost of those bounds is real: an environment already holding an older torch, or a numpy 3 stack, will not install cleanly, and the install section that follows cannot repair that.

Clone first, then install the notebooks extra

Setup starts with a clone, because the package is meant to be used from the repository itself rather than from a published wheel. The first two steps are the ones the project gives:

git clone "https://github.com/ibm-granite/granite-tsfm.git" 
cd granite-tsfm

After the clone, the notebook environment comes from the notebooks extra of the same package, installed with pip from the repository root:

pip install ".[notebooks]"

That extra pulls in jupyter, matplotlib, datasets, ipywidgets, plotly, kaleido and tensorboard on top of the base dependencies listed earlier, and it is what the getting started pages need. Expect a long install the first time, since torch comes in through the transformers extra. The project also publishes a Google Colab tutorial for TinyTimeMixer, which runs the same notebook without any local setup and is the shortest path to a working forecast.

The demo extra still needs checkpoints that are not out yet

There are two installation paths in the project, and the second one is not yet usable end to end. The notebooks extra adds jupyter, matplotlib, datasets, ipywidgets, plotly, kaleido and tensorboard on top of the base install, and it is what the getting started pages need. The demos extra covers a separate application, the demo presented at NeurIPS 2023, which lives in the tsfmhfdemos package and pulls in streamlit, altair, plotly, streamlit-aggrid, kaleido and toml. The limitation is stated plainly in the project text: this demo requires you to have pre-trained and finetuned models in place, and those are planned for a later release. So the install command works and the application has no weights to serve yet. Treat the demos extra as a place holder for a future release rather than a runnable product, and do not plan a demo on top of it without checking the current release notes first.

One notebook per model family, with benchmarking scripts beside them

The notebook inventory maps almost one to one onto the model families, and the file names make the intended learning path easy to follow. Under notebooks/hfdemo there is a getting started notebook for PatchTSMixer, a transfer learning notebook for PatchTSMixer, a transfer learning notebook for PatchTST, a getting started notebook for TinyTimeMixer, a FlowState getting started notebook and a PatchTST-FM getting started notebook. The TinyTimeMixer entry is different from the rest because it points at a full_benchmarking directory rather than a single file, so the TTM family ships its benchmarking scripts and results alongside the demo. There is also a Google Colab tutorial for TTM, hosted as a Colab notebook on the repository, for building a forecasting application with pre-trained models without installing anything locally. A separate services directory holds inference and finetuning components, and the project points readers to a README inside services/inference for that part. The repository root also lists an agentic directory, and a wiki page sits next to the README for longer form documentation.

The README and the packaging file disagree about Python 3.10

A small conflict in the documentation matters more than it looks. The README states that the current Python versions supported are 3.10, 3.11, 3.12 and 3.13. The packaging file, by contrast, declares requires-python as greater than or equal to 3.11 and below 3.14. Under a 3.10 interpreter the install will be refused by the packaging tooling, whatever the README says. Pick 3.11 or newer and both statements line up, but if you are pinning an environment on 3.10 because some other part of your stack needs it, the two documents will send you in opposite directions. The same section of the README is also where the Colab tutorial is advertised, so Colab is the sensible first stop for anyone who only wants to see the TTM flow end to end. Beyond the version range, the README does not document rollback procedures, an upgrade guide, or a supported and tested combination of transformers and torch beyond the dependency bounds themselves.

Ruff targets and lock file churn form the maintenance routine

The repository carries a Makefile adapted from the Hugging Face transformers tree, and it tells you how changes are expected to be checked. The quality target runs a lint pass and a format check across tests, tsfm_public, tsfmhfdemos, notebooks and services, and the style target runs the same lint pass with a fix flag before formatting. Both invoke ruff through uv, with the lint configuration setting a line length of 119 and a rule selection of C, E, F, I and W, while ignoring a handful of complexity, line length, name and undefined name codes. The dependency pins include a pinned ruff of 0.5.7 in the dev extra, so formatting output is reproducible. A separate target exists for refreshing lock files, touching and then removing the three uv.lock files at the root and under services/finetuning and services/inference, relocking each directory, and then running make update_examples in the inference service. The comment attached to that target gives the reason as CVE compliance, which is a real constraint on how often you can simply keep an old environment.

IBM's own notice says the code will not be maintained going forward

Two facts about upkeep deserve to be in the same paragraph. The last push was on 2026-10-22, and the recent tags move quickly: v0.3.10 on 2026-10-02, v0.3.9 on 2026-08-28 and v0.3.8 on 2026-08-04. Against that, the public repository disclosure states that all content including code has been provided by IBM under the associated open source software license, that IBM is under no obligation to provide enhancements, updates or support, that the developers produced it as an open source project rather than an IBM product, and that IBM will not be maintaining this code going forward. The licence field on the repository says Apache-2.0, and the packaging classifiers call the project a beta under the Apache Software License. The root also carries three files named for the advisory GHSA-9mmf-qgpx-g4qx, one describing the fix and one listing additional modules. Frequent tags plus a disclaimer of no support is a combination that suits experimentation and experiments, and it does not suit a service you intend to depend on for years.

Editorial conclusion

granite-tsfm fits a team that wants a working notebook for PatchTSMixer, PatchTST or TinyTimeMixer before it writes any model code, and it gives little to a team that needs a supported service, since IBM states it will not maintain this code going forward. Before adopting it, check the Python version you run against the range in pyproject.toml, confirm the checkpoints you need exist in the Hugging Face granite time series collection, and read the root security notes for GHSA-9mmf-qgpx-g4qx if you plan to serve the components.

Frequently asked questions

Official sources

1. ibm-granite/granite-tsfm on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases