sktime: one estimator API across forecasting, classification and detection
A unified framework for machine learning with time series
At a glance
- What is it?
- sktime wraps forecasting, time series classification, clustering and anomaly or changepoint detection behind a single scikit-learn style interface, plus adapters to statsmodels, tsfresh, PyOD and prophet. The value is interoperability and composable pipelines; the cost is a large dependency surface and a learning curve for its data container conventions.
- Who is it for?
- Adopt sktime if you already work in scikit-learn idioms and need one interface across several time series tasks, or if you want to reduce a forecasting problem to a tabular regression problem without rewriting your validation code. Do not adopt it if you only need a handful of classical forecasting models with fixed assumptions; statsmodels or Prophet cover that with fewer moving parts.
- 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 received new commits within the last day.
- 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 problem sktime attacks: one interface for tasks that share data but not APIs
Forecasting, time series classification, clustering and anomaly or changepoint detection all operate on ordered sequences, but in Python they have historically lived in separate libraries with separate conventions. A forecasting library expects a series indexed by time. A classification library expects a two dimensional array of shape (n_samples, n_timepoints) plus a label vector. A changepoint library expects a single long sequence and returns indices. Moving a model from one setting to another usually means reshaping data and rewriting the surrounding code.
sktime's stated objective is to improve interoperability and usability across the time series ecosystem by providing a unified interface for these distinct but related tasks. The README lists forecasting, time series classification, clustering, anomaly and changepoint detection as the currently covered tasks. The intended audience is therefore an engineer or data scientist who already knows scikit-learn, has more than one time series problem on their plate, and does not want four different data layouts and four different fit signatures in the same codebase.
How the unified interface works: estimators, adapters and reduction
The mechanism is an estimator protocol borrowed from scikit-learn. The README describes sktime as "a unified interface for machine learning with time series" and says it comes with time series algorithms and scikit-learn compatible tools to build, tune and validate time series models. In practice that means a model is an object with fit and predict style methods, so the same tuning and validation machinery you use for tabular models can be pointed at a time series model.
The second mechanism is composite model building. The README names pipelining, ensembling, tuning and reduction as the tools provided, and describes reduction as letting users "apply algorithms designed for one task to another". Reduction is the part worth understanding before you adopt anything: it is the bridge that turns, for example, a tabular regressor into a forecaster by reframing the series as supervised learning rows. That is why the same interface can cover forecasting and classification without duplicating every algorithm.
The third mechanism is adapters. sktime does not reimplement everything. The README states it provides interfaces to related libraries including scikit-learn, statsmodels, tsfresh, PyOD and fbprophet. Those adapters are what make the unified interface useful in practice, and they are also the main source of installation weight, since each wrapped library brings its own dependencies.
Installing sktime and the first fit call
The README points to PyPI and conda-forge as the distribution channels, and the badges reference both the pypi and conda package names as sktime. The straightforward install is therefore:
pip install sktime
or, for conda users:
conda install -c conda-forge sktime
The README does not spell out a minimal code example in the material available here, so the exact constructor arguments for a given forecaster should be read from the API reference rather than guessed. What the material does establish is the shape of the workflow: you pick an estimator from the estimator overview page, construct it, call fit on your series, and call predict. Because the interface is scikit-learn compatible, tuning and validation are handled by the same tools the README references.
Two practical points before you start. First, the version matters: the README announces Version 1.1.0, and the recent releases list v1.1.0 followed by v1.0.2 and v1.0.1, so pinning an exact version in your requirements file avoids surprises from the fast release cadence. Second, the extension templates in the documentation are the right place to look if you intend to wrap your own model, since they document the estimator API you would need to satisfy.
Where sktime gets in the way: data containers and adapter dependencies
The unified interface is only as uniform as the data container underneath it. Time series in sktime carry index and column semantics that tabular arrays do not, and the material here does not enumerate those conventions in detail, which is itself a signal: expect to read the API reference for the expected input format before your first fit call succeeds. If you pass a plain NumPy array where a pandas object with a time index is expected, or transpose a series that should be (n_timepoints,) rather than (n_samples, n_timepoints), the failure will be a shape or index error rather than a modelling error, and it will cost you an afternoon.
The second cost is the dependency surface. Adapters to statsmodels, tsfresh, PyOD and prophet mean that a full install can pull in a substantial stack, and version conflicts between those libraries are a realistic failure mode in an existing environment. If you only need the adapter for one of them, install selectively rather than assuming the default environment is what you want in production.
The third case where sktime is the wrong tool is narrow, single-model work. If your problem is one univariate series and one classical model, the extra abstraction buys you nothing and adds a layer between you and the library that actually implements the estimator. The unified interface pays off when you have several tasks, several candidate models, or a need to tune and validate systematically.
statsmodels and Prophet as the narrower alternatives
statsmodels is a statistics library, not a machine learning framework. It exposes specific estimators with their own fit and results objects, and its output is oriented toward inference: coefficients, standard errors, diagnostic tests. sktime, by contrast, wraps statsmodels behind its own estimator interface so that the same object can be pipelined, tuned and cross-validated alongside non-statistical models. If you need to read a coefficient table and reason about model assumptions, statsmodels directly is the shorter path. If you need to compare a statistical model against a gradient boosted reduction on the same validation split, sktime's adapter is what makes that comparison mechanical.
Prophet takes a different position again. It is a single forecasting procedure with a fixed additive structure and a dataframe interface with ds and y columns. It does not attempt to cover classification or changepoint detection, and it does not try to be composable. sktime's README lists fbprophet among the libraries it interfaces to, so the two are not mutually exclusive: you can use Prophet's model through sktime's interface if you want it to participate in the same tuning and validation loop as everything else. Choose Prophet alone when you want one opinionated forecaster and no framework; choose sktime when the framework is the point.
Maintenance, releases and the BSD-3-Clause licence
The repository is not archived, the default branch is main, and the most recent push recorded here is 2026-09-10. The release history shows v1.1.0 in July 2026, preceded within days by v1.0.2 and about six weeks earlier by v1.0.1. That cadence is fast enough that a loose version constraint in a requirements file will move under you, and the changelog is the document to read before upgrading rather than after. Upgrading cost is concentrated in two places: the estimator API, if you have written custom estimators against the extension templates, and the adapters, if an upstream library such as statsmodels or tsfresh changes its own interface.
The licence is BSD-3-Clause, which is a permissive licence that generally allows use, modification and redistribution provided the copyright notice and licence text are retained, and it does not carry the copyleft obligations of a GPL-style licence. It also includes a clause restricting the use of contributor names for endorsement. This is a description of what the licence identifier means, not legal advice; if you are redistributing sktime inside a product, have your own counsel read the LICENSE file in the repository.
Who should adopt sktime, and what to verify first
Adopt it if your team already writes scikit-learn style code and you have more than one time series task in scope. The reduction mechanism is the strongest argument: it lets a tabular regressor enter a forecasting workflow without a separate code path, and it lets tuning and validation be shared rather than reimplemented per task. Adopt it also if you want statsmodels, tsfresh, PyOD or prophet models to sit behind a common interface so that swapping one for another is a constructor change.
Do not adopt it for a single univariate forecast where statsmodels or Prophet would be a direct fit, and do not adopt it expecting the data container conventions to be obvious from the README alone. The material here does not document the index and column requirements in enough detail to guess them.
What to verify before you commit: install a pinned version (v1.1.0 is the current release listed), run one estimator end to end on a series shaped like your production data, and confirm the exact input layout it accepts. Then check which adapters you actually need and install only those, because statsmodels, tsfresh, PyOD and prophet each bring their own dependency tree. If the first fit call fails on shape or index, that is the interface telling you the container conventions are the real entry cost, not the modelling.
Editorial conclusion
Adopt sktime if you already work in scikit-learn idioms and need one interface across several time series tasks, or if you want to reduce a forecasting problem to a tabular regression problem without rewriting your validation code. Do not adopt it if you only need a handful of classical forecasting models with fixed assumptions; statsmodels or Prophet cover that with fewer moving parts. Before committing, run one estimator end to end on your own series and check the exact index and column layout it expects, then confirm which optional adapters (statsmodels, tsfresh, PyOD, prophet) you actually need, because each pulls its own dependency tree into your environment.
Community notes