OpenLTM: A Pre-Training Pipeline for Large Time-Series Models, Not a Model You Install
Implementations, Pre-training Code and Datasets of Large Time-Series Models
At a glance
- What is it?
- OpenLTM collects pre-training, supervised training and adaptation code for Timer-XL, Moirai, Timer, Moment, TTMs, GPT4TS, Time-LLM and AutoTimes under one MIT-licensed repository. Its value is the pipeline and the scripts, not a single downloadable forecaster, and its main constraint is that the heavy assets live outside the repo.
- Who is it for?
- Adopt OpenLTM if you already have a forecasting benchmark and want one repository where supervised, rolling, pre-training and fine-tuning runs for Timer-XL, Moirai, Timer, Moment, TTMs, GPT4TS, Time-LLM and AutoTimes share a single entry point. Do not adopt it if you want a zero-shot forecaster you can call on a dataframe this afternoon; the README points those users to the HuggingFace collection or to Large-Time-Series-Model instead.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 178 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenLTM Is Actually For
OpenLTM targets a narrow audience: engineers and researchers who need to pre-train or adapt a large time-series model and want the training loop, the dataset plumbing and the evaluation harness already wired together. The README describes it as "an open codebase aiming to provide a pipeline to develop and evaluate large time-series models." That word pipeline is the honest description. The repository is not a library you import into a production service, and it is not a packaged model. It is a set of Jupyter notebooks and Python modules plus shell scripts that drive training runs. The problem it solves is fragmentation. Before a repository like this, reproducing a Timer-XL or Moirai result meant reconstructing the data loaders, the normalization scheme and the evaluation protocol from a paper and a separate code release. OpenLTM gathers several of those implementations behind one experiment base class so a run on ETTh1 and a run on UTSD differ mainly by the script you invoke. If you are choosing a forecasting model rather than training one, this is the wrong repository, and the README says so directly by pointing to the HuggingFace collection and to Large-Time-Series-Model for out-of-the-box use.
The Model Checklist Is a Status Board, Not a Feature List
The README carries a checklist of thirteen models. Eight are ticked: Timer-XL, Moirai, Timer, Moment, TTMs, GPT4TS, Time-LLM and AutoTimes. Five are unticked: Sundial, LLMTime, Chronos, Time-MoE and a decoder-only foundation model for time-series forecasting. The distinction matters more than it first appears. A ticked entry means an implementation exists in the repository, with a model file and scripts. An unticked entry is a citation plus a link to somebody else's code, which is useful for orientation and useless for running anything. Two of the ticked entries arrived through outside contributors, TTMs and other LLM4TS methods from frndtls, and GPT4TS from khairulislam, which the update notes credit by name. That pattern tells you something about the maintenance model: coverage grows when someone outside the core group needs a model badly enough to port it. If the model you care about is on the unticked list, OpenLTM will not run it for you today.
How a Training Run Is Assembled
The architecture visible in the material is a small experiment framework rather than a deep abstraction layer. Models live as individual files under ./models, and the README points to ./models/timer_xl.py as the file to imitate when adding your own. Registration happens in one place: you include the new model in Exp_Basic.model_dict inside ./exp/exp_basic.py. Scripts under ./scripts then select the model, the dataset and the training regime by name. That is the whole extension path, and it is deliberately thin. The consequence is that the framework does not hide much. If your model needs a different batching strategy or a different loss, you will be editing near the training loop rather than overriding a hook. The payoff is that a reader can trace a run from the shell script to the model file without crossing many layers, which is what makes the repository usable as a starting point for a new architecture.
The Scripts Folder Encodes Three Separate Workflows
The scripts are organized by what you are trying to accomplish, and the README gives one example path for each. Supervised training splits into one-for-one forecasting via ./scripts/supervised/forecast/moirai_ecl.sh and one-for-all rolling forecasting via ./scripts/supervised/rolling_forecast/timer_xl_ecl.sh. Large-scale pre-training runs on UTSD through ./scripts/pretrain/timer_xl_utsd.sh or on ERA5 through ./scripts/pretrain/timer_xl_era5.sh. Model adaptation splits into full-shot fine-tuning with ./scripts/adaptation/full_shot/timer_xl_etth1.sh and few-shot fine-tuning with ./scripts/adaptation/few_shot/timer_xl_etth1.sh. The naming convention is consistent: model, then dataset. That consistency is the practical benefit, because once you have run one script you can predict what a second one does. Note that the supervised example uses Moirai while the pre-training and adaptation examples use Timer-XL, so the repository does not present a single canonical model. You are expected to pick.
Datasets and Checkpoints Are Not in the Repository
This is the constraint that shapes every first attempt. Installation is one command, pip install -r requirements.txt, on Python 3.11. Data is not. You place downloaded archives in ./dataset yourself. For univariate pre-training the README names UTSD, described as 1 billion time points in numpy format, and ERA5-Family, described as a 40-year span with thousands of variables for domain-specific models. For supervised training or modeling adaptation it points to the datasets from TSLib. Checkpoints are likewise external: the README says pre-trained checkpoints go in ./checkpoints, and the May 2025 update announces a 260B pre-trained Timer in PyTorch hosted on a Tsinghua cloud link, equivalent to the HuggingFace timer-base-84m model but, in the README's phrasing, "more user-friendly for fine-tuning." A notebook, load_pth_ckpt.ipynb, shows how to load that checkpoint. So the real setup cost is not the pip install. It is fetching tens of gigabytes from cloud links and arranging them under ./dataset in the layout the loaders expect, a layout the README summarizes only through an image of a dataset table.
Where OpenLTM Breaks Down
Three failure modes are visible from the material alone. First, the dataset layout is under-specified in text. The README references ./figures/datasets.png for a dataset summary rather than listing directory names, so if your download unpacks into a different structure than the loaders assume, you are reading source to find out. Second, the repository has no releases. The metadata shows no releases retrieved, so versioning is by commit on main. Pinning a working state means pinning a commit hash yourself, and there is no changelog to tell you what moved between two hashes. Third, the unticked half of the model checklist is a trap for the inattentive reader. A model appearing in the checklist with a paper link looks supported until you notice the box is empty and the code link points to a different organization. Anyone who skims the checklist and assumes Chronos or Time-MoE ships here will waste an afternoon. None of these are defects in the research code. They are the ordinary costs of a research repository that was never packaged as a product.
How This Differs From Time-Series-Library
The README itself makes the comparison, and it is the most useful orientation in the document. For deep time series models, it recommends Time-Series-Library and a survey paper; OpenLTM is positioned for the large-model case. The difference in approach is scale and training regime. Time-Series-Library is the source of the supervised datasets OpenLTM reuses, and its focus is training and evaluating deep forecasting architectures on established benchmarks. OpenLTM adds the pre-training stage on top: UTSD at 1 billion time points, ERA5-Family for domain-specific models, and a 260B checkpoint to fine-tune from. If your task is comparing architectures on ETTh1 or ECL, Time-Series-Library is the shorter path and OpenLTM's pre-training machinery is overhead you will not use. If your task is producing a model that generalizes across datasets, the pre-training scripts are the reason to be here, and the supervised scripts exist mainly to give you a baseline against the pre-trained result.
Maintenance, Licence and What to Check First
The repository is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is a statement about the licence text, not legal advice, and the external datasets and checkpoints carry their own terms that the README does not enumerate. Maintenance is active: the last push recorded is 2026-03-22, and the update log shows a steady cadence of outside contributions through 2024 and 2025. The upgrade cost is low in the abstract and annoying in practice. There are no tagged releases, so an upgrade is a git pull against main, and the things most likely to shift under you are the model registry in ./exp/exp_basic.py and the script names under ./scripts. Before you build on it, do three checks: confirm the checkpoint you plan to fine-tune corresponds to the model file you register, confirm your dataset unpacks into the structure the loaders in ./dataset expect, and confirm Python 3.11 with the pinned requirements.txt resolves in your environment, since the README specifies that version rather than a range.
Editorial conclusion
Adopt OpenLTM if you already have a forecasting benchmark and want one repository where supervised, rolling, pre-training and fine-tuning runs for Timer-XL, Moirai, Timer, Moment, TTMs, GPT4TS, Time-LLM and AutoTimes share a single entry point. Do not adopt it if you want a zero-shot forecaster you can call on a dataframe this afternoon; the README points those users to the HuggingFace collection or to Large-Time-Series-Model instead. Before committing, verify three things: that ./dataset holds UTSD, ERA5-Family or the TSLib archives in the layout the scripts expect, that your environment matches the required Python 3.11 and the pinned requirements.txt, and that the checkpoint you intend to fine-tune matches the model file you register in Exp_Basic.model_dict.
Community notes