aeon: a scikit-learn-compatible toolkit for time series machine learning
A toolkit for time series machine learning and deep learning
At a glance
- What is it?
- aeon collects classification, regression, clustering, forecasting, anomaly detection, segmentation and similarity search under one scikit-learn-style API, with many algorithms contributed by the researchers who wrote them. The judgement: it is the broadest single-package option for time series tasks, but its breadth is also its cost, and the documentation does not settle every question a production team will ask.
- Who is it for?
- Adopt aeon if you are working in Python and need several time series tasks under one scikit-learn-compatible interface, particularly classification, regression or clustering where the estimator list is the reason to be there. Do not adopt it if you only need univariate forecasting and already run statsmodels or a dedicated forecasting package, because the extra surface area buys you nothing.
- Can I use it commercially?
- Yes. BSD-3-Clause 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 1 day ago.
- What is it written in?
- Mainly Python, 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
The gap aeon is trying to fill
Time series work in Python has historically been split across packages that do not share conventions. One library handles forecasting, another handles classification, a third handles anomaly detection, and each has its own data format, its own fit and predict signatures, and its own idea of what a train/test split looks like. Moving between them means rewriting glue code rather than changing a class name. aeon's stated position is that it is a scikit-learn compatible library for learning from time series, covering classification, regression, clustering, forecasting, anomaly detection, distances, segmentation, similarity search, transformations and benchmarking. The intended reader is someone who already knows the scikit-learn fit, predict and transform pattern and wants that pattern to hold when the input is a series rather than a table. The README also makes a claim about provenance that matters more than the API surface: many implementations are contributed and maintained by the researchers who developed the original methods. That is a different kind of promise from the usual wrapper library. It means the code is closer to the paper, and it also means the maintainer list is tied to academic careers rather than to a company's product roadmap.
What scikit-learn compatibility actually buys you
The compatibility claim is the load-bearing one, because it determines whether aeon is a library you learn once or a library you learn per module. In practice, scikit-learn compatibility means estimators expose fit and predict, they follow the estimator API conventions, and they can be dropped into the surrounding ecosystem of splitters, pipelines, scorers and search procedures that assume those conventions. For a team already running cross-validation and hyperparameter search, that is the difference between adopting a new algorithm in an afternoon and adopting a new framework in a quarter. The claim is also falsifiable in a useful way: if an estimator does not behave like a scikit-learn estimator, that is a bug report rather than a matter of taste. The README does not enumerate which estimators satisfy the contract and which do not, so the honest position is that compatibility is the design intent and you should confirm it for the specific estimator you plan to use. The API reference linked from the README is where that confirmation happens.
How the package is organised and installed
aeon is distributed on PyPI and conda-forge, so the two documented installation paths are a pip install and a conda install. The README links to a getting started page at aeon-toolkit.org/en/stable/getting_started.html, and the API reference is split by task area, which mirrors the module list in the description: classification, regression, clustering, forecasting, anomaly detection, distances, segmentation, similarity search, transformations and benchmarking. That structure tells you something about how the project expects to be used. You do not read aeon end to end. You pick a task area, read the estimators in it, and ignore the rest. The repository also ships an examples directory, and the README offers a Binder link that opens those notebooks in a browser with the filepath parameter pointing at examples. If you want to evaluate aeon without touching your own environment, that Binder route is the lowest-commitment option the README provides. For local installation, the practical question is dependency weight: a toolkit spanning deep learning approaches alongside classical methods will pull in more than a minimal install, and the README does not lay out optional dependency groups in the excerpt available here. Check the getting started page for the extras syntax before you assume a plain install covers the deep learning estimators.
Breadth as a maintenance liability
The same scope that makes aeon attractive is the thing to be sceptical about. Ten task areas maintained by different groups of contributors, several of them academics contributing the method they published, means the package is not one codebase in any meaningful sense. It is a federation. The release cadence visible in the repository supports that reading: v1.3.0 in September 2025, v1.4.0 in March 2026, v1.5.0 in June 2026. Three minor releases in roughly nine months is a steady rhythm, and minor releases in a project this size can carry behaviour changes. The concrete risk is not that the project is abandoned, it is that the estimator you depend on is maintained by someone whose paper is finished. A method contributed by its author and then left alone will keep working until a dependency moves, and then it will not. The README gives no deprecation policy and no support window, so version pinning is not optional advice here, it is the mechanism by which you avoid being surprised. There is also a fit question: if your problem is univariate forecasting and nothing else, aeon's breadth is pure overhead against a library that does one thing.
Where aeon is the wrong tool
Two cases stand out. The first is narrow scope. If you need forecasting and only forecasting, and your models are classical statistical ones, a dedicated forecasting library will have a smaller dependency tree and a shorter path from install to first forecast. aeon's value comes from having classification, clustering, segmentation and the rest in the same place with the same conventions. Remove that and you are paying for modules you never import. The second case is the one where the algorithm is the easy part. aeon gives you estimators. It does not give you a data pipeline, a feature store, a backtesting harness for a live trading system, or a monitoring layer for drift. If your bottleneck is that your series are irregular, your labels are noisy, or your evaluation protocol does not match how the model will be used, a better estimator will not fix it. The README is a library README, and it is honest about that; it does not claim to be a platform. Teams that read it as a platform will be disappointed, and that disappointment will be their own misreading rather than a defect in the project.
The real alternative and the actual difference
The obvious comparison is scikit-learn itself. The difference is not quality, it is input shape and method coverage. scikit-learn assumes a two-dimensional array of samples by features. Time series classification and clustering do not fit that assumption cleanly, which is why aeon exists alongside scikit-learn rather than inside it. aeon's contribution is the estimator set and the time series specific machinery (distances, segmentation, similarity search) that scikit-learn does not attempt. A second comparison is a dedicated forecasting package, and here the difference is philosophical. A forecasting-first library typically assumes one series or a small panel, offers a fixed family of statistical and machine learning models, and optimises for the forecasting workflow: horizon, seasonality, backtesting. aeon treats forecasting as one task area among ten and optimises for consistency with the rest. If your work is forecasting and nothing else, the forecasting-first library will have a shorter path to a result. If your work involves classifying series, clustering them, finding anomalous segments in them, and also forecasting them, aeon's consistency is worth more than any single module's depth. That is the trade, and it is a real one in both directions.
Licence, governance and what to verify before adopting
The licence is BSD-3-Clause, which is a permissive licence: it allows use, modification and redistribution, including in closed-source products, provided the copyright notice and licence text are retained. That is the general shape of BSD-3-Clause and it is the reason the licence is unlikely to be the blocker in a commercial setting. It is not legal advice, and if your organisation has a licence review process, the file to hand to it is the LICENSE file in the repository. On governance, the project is published in the Journal of Machine Learning Research (2024) under the title aeon: a Python Toolkit for Learning from Time Series, which is a meaningful signal about the intended audience and about how contributions are evaluated. It is not a signal about long-term maintenance. The repository is not archived and the last push is dated 2026-09-09, so the project is active as of that date. What you should verify first is narrower and more practical: confirm in the API reference that the estimator you intend to use is present in the version you will install, pin that version in your dependency file, and install the optional dependencies that estimator needs. If the estimator you need is not in the API reference for your version, no amount of reading the README will put it there.
Editorial conclusion
Adopt aeon if you are working in Python and need several time series tasks under one scikit-learn-compatible interface, particularly classification, regression or clustering where the estimator list is the reason to be there. Do not adopt it if you only need univariate forecasting and already run statsmodels or a dedicated forecasting package, because the extra surface area buys you nothing. Before committing, verify three things against your own data: that the estimator you want is still present in the API reference for your installed version, that your aeon version is pinned in your dependency file, and that the optional dependencies your chosen estimator needs are installed in your environment.
Community notes