TSLib: When a Time Series Benchmark Becomes a Baseline Archive

The problem TSLib solves is comparison, not deployment

Deep time series research has a reproducibility problem that is mostly mechanical. Two papers report forecasting numbers on the same dataset, but one uses a look-back window of 96 and the other searches over look-back lengths, so the numbers sit in different columns of the same table and nobody notices. TSLib's answer is a shared data loader, a shared training loop, and a shared set of scripts, so that swapping a model is a flag change rather than a rewrite. The README states the library covers five mainstream tasks: long- and short-term forecasting, imputation, anomaly detection, and classification. That scope is the product. It is aimed at deep learning researchers, and the README says so directly, describing TSLib as a code base for evaluating advanced deep time series models or developing your own. If you are an engineer looking for a forecasting microservice, the framing is wrong for you from the first line. The library's own maintainers later concede the point in the April 2026 news item: because the library was originally released three years ago, many of its benchmarks may no longer be meaningful for evaluating the effectiveness or progress of current research, while the baseline implementations remain correct. That sentence is the most useful thing in the repository for anyone making an adoption decision.

One entry point, five task-specific experiment modules

The architecture visible in the repository is deliberately flat. A run.py entry point sits at the top, models/ holds one file per architecture, exp/ holds the experiment logic split by task, and scripts/ holds shell scripts per dataset and per task. The zero-shot forecasting addition from November 2025 follows the same pattern: exp/exp_zero_shot_forecasting.py for the logic, and a script under scripts/long_term_forecast/ETT_script/ for the invocation. That split matters because it tells you where to look when something breaks. A shape mismatch between the model output and the loss is an exp/ problem. A model that ignores the input length is a models/ problem. The data pipeline is shared, which is the actual value proposition: the same loader feeds TimesNet, iTransformer, PatchTST, DLinear, FEDformer, Autoformer, Informer and the non-stationary Transformer, so a difference in reported error is more likely to come from the model than from preprocessing. The library also carries a leaderboard covering five tasks, ranked by the maintainers as of March 2024, with long-term forecasting split into Look-Back-96 and Look-Back-Searching categories. That split was introduced in March 2024 precisely because papers used inconsistent look-back lengths. TimeXer tops the Look-Back-96 column in that table and TimeMixer tops Look-Back-Searching. Treat the table as a snapshot of a specific date, not a live ranking. The README's own note says it will keep updating the leaderboard, but the April 2026 news item about not adding new features makes that commitment uncertain.

Getting a baseline running: run.py, task flags and the script directory

The documented path to a first result is a shell script. For the zero-shot forecasting feature added in November 2025, the README points to scripts/long_term_forecast/ETT_script/LTSM.sh as the script to try. The general shape is that you invoke run.py with a task name, a model name, a dataset identifier, and the usual training hyperparameters, and the exp/ layer dispatches on the task. Because the README excerpt does not enumerate the full flag list, I cannot state the exact argument names here; check run.py directly for the authoritative set. Two concrete installation details are documented. Mamba support, added in April 2024, lives in models/Mamba.py and requires installing mamba_ssm with pip first, which is a separate dependency from the base environment and a common source of import failures. Separately, a December 2025 contribution from the user ailuntz added updated requirements and a Docker deployment along with reorganized documentation, which the maintainers describe as meaningful for beginners. If you are setting up from scratch, that Docker path is likely to save time compared with resolving dependencies by hand, since the original requirements file predates several of the newer models. The library's licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive arrangement, but it says nothing about the licences of the individual model implementations or the datasets the scripts download, which you would need to check separately. This is not legal advice.

The maintenance signal is the headline limitation

In April 2026 the maintainers announced that due to limited bandwidth they will not be actively adding new features, and recommended seeking out newer benchmarks. That is an unusually direct statement and it should drive the decision. The practical consequence is that TSLib is now a fixed artefact. Bugs in baseline implementations may still be fixed, since the same note says the baseline implementations remain correct, but new architectures will not land. If a model published after that date claims better numbers, TSLib will not contain it. There is a second limitation that predates the freeze. The library's benchmark datasets and configurations were chosen years ago, and the October 2025 news item about the Accuracy Law is the maintainers arguing that some standard datasets are saturated, meaning a fraction of a percent improvement on them carries little information. A framework whose scripts default to those datasets will keep producing numbers on them. There is also a scope limitation worth naming: TSLib is a training and evaluation harness, not a serving layer. Nothing in the description suggests batching, latency budgets, model export, or online updating. Using it as the runtime for a production forecaster means writing that layer yourself.

OpenLTM is the sibling project with the opposite workflow

The README itself points to the alternative. In October 2024 the lab open-sourced OpenLTM, described as providing a distinct pretrain-finetuning paradigm compared to TSLib, aimed at Large Time Series Models. The difference in approach is structural rather than a matter of model choice. TSLib trains each model from scratch on each dataset through run.py, which is what makes it a fair benchmark: every architecture sees the same data with the same budget, and no model gets a head start from pretraining on other series. OpenLTM inverts that, pretraining a backbone once and then finetuning per task, which is how large time series models are typically built but which makes cross-model comparison on a small dataset less clean. If your question is which architecture wins on ETT with a fixed budget, TSLib is the right instrument. If your question is how to get useful forecasts on a new series with limited history, the pretrain-finetune route is a different and often better bet. The November 2025 zero-shot forecasting addition sits between the two: it lets you evaluate large time series models inside TSLib's harness, using the LTSM.sh script, without adopting the OpenLTM codebase. That is a reasonable compromise if you want TSLib's evaluation discipline but not its from-scratch training assumption.

What to check before you commit a project to TSLib

Three checks are cheap and each one has killed an adoption. First, open models/ and confirm the architecture you intend to use is present as a file. The library covers a specific set, and the leaderboard table marks included implementations with a checkbox, so the table doubles as an inventory. Second, confirm the task has a matching exp/ module, since the five tasks are not symmetric in how much code they carry. Third, decide whether the Mamba path matters to you, because if it does you are adding mamba_ssm and its CUDA toolchain to your environment, which is a heavier install than the rest of the library. Beyond those, read the April 2026 news item again before you write a paper that leans on TSLib numbers. The maintainers are telling you the benchmarks may be saturated and that you should look for newer ones. That is a self-assessment from the people best positioned to make it, and it costs you nothing to take seriously.

Editorial conclusion

Adopt TSLib if you need a single MIT-licensed code base to reproduce or compare deep time series baselines across forecasting, imputation, anomaly detection and classification, and you accept that no new features are being added. Do not adopt it as the foundation for a production inference service, and do not treat its leaderboard as current evidence of state of the art. Before committing, verify three things: that the model you need is actually present under models/, that the task you need has a matching exp/ file, and whether the Mamba path requires the separate mamba_ssm install. If your goal is pretraining a large time series model, the same lab points to OpenLTM instead.

Official sources

1. Issues
2. License: MIT
3. README
4. thuml/Time-Series-Library on GitHub