Lazy Predict: fitting 40-plus scikit-learn models in one call, and what that call does not tell you
Lazy Predict help build a lot of basic models without much code and helps understand which models works better without any parameter tuning
At a glance
- What is it?
- Lazy Predict fits a large set of untuned classifiers and regressors against a single train and test split and returns a leaderboard. It is useful for the first hour of a modelling problem and misleading if you treat the ranking as a final answer.
- Who is it for?
- Adopt Lazy Predict if your first task on a tabular problem is to see which model families are worth tuning, and you accept that the output is a screening list rather than a result. Do not adopt it if you need hyperparameter search, calibration, leakage-safe preprocessing, or a defensible final number, because none of those are what the fit call produces.
- 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 3 days 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 blank-notebook problem Lazy Predict addresses
Starting a supervised learning task on tabular data usually means writing the same twenty lines before you learn anything. Import a dozen estimators, loop over them, catch the ones that throw on your data, time each fit, score each one, sort the results. Lazy Predict collapses that into a single fit call and returns a DataFrame you can print. The README's own framing is that it helps you understand which models work better without any parameter tuning. That sentence is the whole product. It is a screening tool for the moment when you know your features and your target but not which model family deserves your attention. The intended user is someone who already knows scikit-learn and does not want to hand-write the loop. It is not aimed at people who want an AutoML system to hand them a tuned, deployable pipeline, and the README never claims that.
What fit actually does with your train and test split
The classification example in the README is explicit about the data flow. You split X and y yourself with train_test_split, then pass X_train, X_test, y_train and y_test into LazyClassifier.fit. The object fits every estimator in its registry on the training half and scores it on the test half, returning two things: a models DataFrame and a predictions DataFrame. The printed table has one row per model and columns for Accuracy, Balanced Accuracy, ROC AUC, F1 Score and Time Taken. The README's sample output shows LinearSVC at the top with an accuracy around 0.989 and a time near 0.015 seconds, with RandomForestClassifier further down at roughly 0.972 and MLPClassifier taking about 0.426 seconds. Those numbers come from a breast cancer dataset with a 0.5 test split and random_state 123, so they describe that one run, not a general ranking. The Time Taken column is the part people skip and shouldn't: on that table the fastest models are also the most accurate, which is a property of that dataset, not a rule.
The constructor arguments that change the run
The advanced example in the README passes verbose, ignore_warnings, custom_metric, predictions, classifiers, categorical_encoder, timeout, cv and use_gpu. Most of these are self-explanatory. Three are worth dwelling on. categorical_encoder accepts 'onehot', 'ordinal', 'target' or 'binary', and the README notes that the target and binary strategies require the category-encoders package, so those two are not available on a bare pip install. timeout caps the seconds spent per model, which matters because a single slow estimator can otherwise dominate wall clock time on a large dataset. cv sets the number of cross-validation folds and is described as optional, meaning the default is a single train and test evaluation. That default is the source of most of the tool's weaknesses. A single split gives you one number per model, and the gap between the top two rows in the README's table is under three percentage points on a test set of a few hundred rows.
Time series, GPU and the extras that are not in the base install
The feature list has grown well past classifiers and regressors. The README advertises over 40 built-in models, automatic model selection for classification, regression and time series forecasting, and more than 20 forecasting models spanning statistical methods (ETS, ARIMA, Theta), machine learning (Random Forest, XGBoost), deep learning (LSTM, GRU) and pretrained foundation models (TimesFM). Seasonal period detection is done via ACF. None of that arrives with a plain pip install lazypredict. The extras are split: lazypredict[timeseries] pulls statsmodels and pmdarima, adding deeplearning brings PyTorch for LSTM and GRU, and adding foundation brings Google TimesFM with the constraint that it supports Python 3.10 and 3.11 only. The README also lists MLflow integration for experiment tracking, Intel Extension for Scikit-learn acceleration, and GPU acceleration for XGBoost, LightGBM, CatBoost, cuML and the deep learning models, enabled through use_gpu=True. Treat the feature list as a menu of optional installs rather than a description of the default package.
Where the leaderboard stops being trustworthy
The central limitation is stated by the project itself: no parameter tuning. Every model runs at its library defaults. That means the ranking compares default configurations, and a model with poor defaults can lose to a model with good ones regardless of which is better suited to your data. A single train and test split compounds this, because the ordering near the top of the table is within noise on small datasets. The README's own example shows several models clustered within a fraction of a percentage point of each other, and nothing in the output tells you whether those differences would survive a different random_state. Encoding is another sharp edge. Categorical handling is chosen by a constructor argument rather than inferred, and target encoding in particular is a leakage-prone transform that the README does not describe fitting inside a cross-validation fold, so passing categorical_encoder='target' alongside cv is a combination you should reason about yourself. Finally, the tool is the wrong choice when your data is not tabular, when you need a calibrated probability output, or when the deliverable is a tuned model rather than a shortlist.
How it differs from a full AutoML search
The obvious comparison is a hyperparameter search framework such as Optuna or a scikit-learn Pipeline wrapped in GridSearchCV or RandomizedSearchCV. The difference is not quality, it is what gets spent. A search framework takes a search space you define, a budget you set, and a cross-validation scheme, then spends that budget optimising a small number of estimators. Lazy Predict spends almost nothing per model and covers a wide set of estimators at their defaults, which is the opposite trade. The two compose naturally: use Lazy Predict to pick two or three families off the leaderboard, then hand those to a search framework with a proper cross-validation split and a real search space. Running the search first is the mistake, because you pay tuning cost on families that were never going to be competitive. A second comparison point is scikit-learn's own model selection utilities, which give you cross_val_score and the estimator list but no registry, no timing column and no assembled table, so the loop Lazy Predict replaces is one you would otherwise write and maintain.
Install, licence and upgrade surface
Installation is a single command from PyPI (pip install lazypredict) or conda-forge (conda install -c conda-forge lazypredict), with lazypredict[boost] for XGBoost, LightGBM and CatBoost and lazypredict[all] for everything. The project is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained; that is a description of the licence text, not legal advice, and you should read the LICENSE file in the repository if the distinction matters to your organisation. The package supports Python 3.9 through 3.13 according to the README, with the TimesFM foundation extra restricted to 3.10 and 3.11, so a Python 3.13 environment cannot install every extra at once. Maintenance cost is mostly the cost of the dependency tree rather than the package itself. The extras pull in statsmodels, pmdarima, PyTorch and TimesFM, each with its own release cadence, and the optional GPU path adds cuML and RAPIDS, which pin to specific CUDA versions. The release history shows v0.3.0 in March 2026 followed by v0.3.1 in August 2026, with the time series and GPU features landing in the 0.3 line, so anything written against an earlier version will not match the parameter list above.
Editorial conclusion
Adopt Lazy Predict if your first task on a tabular problem is to see which model families are worth tuning, and you accept that the output is a screening list rather than a result. Do not adopt it if you need hyperparameter search, calibration, leakage-safe preprocessing, or a defensible final number, because none of those are what the fit call produces. Before you rely on it, verify the version you installed, since the classifier and regressor parameters described here come from the current README and the time series and foundation model extras are recent additions that older releases will not have.
Community notes