FLAML: A Budget-Aware AutoML and Tuning Library for Python

The Budget Problem FLAML Targets

Most AutoML frameworks answer the question "which model is best" without answering "best within what". FLAML frames the task the other way around. The README describes it as enabling economical automation and tuning for ML and AI workflows, with model selection and hyperparameter optimization under resource constraints. That constraint-first framing is the actual product. If you have a fixed compute envelope, a deadline, or a per-call cost for evaluating a configuration, the search needs to spend its budget where it expects the largest return, not enumerate a grid. The library is aimed at Python users who already work with scikit-learn style APIs and want the search handled for them. The README also lists a .NET implementation in ML.NET, so the same approach exists outside Python, but that is a separate codebase with its own documentation. FLAML's own scope is the Python package, published on PyPI and conda-forge, with the source repository written primarily in Jupyter Notebook, which tells you the maintainers treat runnable examples as first-class documentation rather than an afterthought.

Two Entry Points: AutoML and tune

The library exposes two layers that share a search core. The first is the AutoML class, used as a scikit-learn style estimator. You construct it, call fit with your training data and a task string, and it returns a fitted object. The second is flaml.tune, which takes an arbitrary Python function plus a configuration space and searches it. The README's example for the second layer passes evaluation_function, a config dictionary, a low_cost_partial_config, and time_budget_s. That low_cost_partial_config argument is the mechanism worth noting: it lets you supply a cheap partial evaluation of your objective, so the search can rank candidates before paying for a full run. That is how the library handles heterogeneous evaluation cost, which the README names explicitly alongside complex constraints and early stopping. The two layers are not separate products. AutoML is the task-oriented wrapper; tune is the generic search underneath. If your objective is not a model fit (a pipeline configuration, a statistical model, an algorithm parameter set), the tune layer is the part you use, and the AutoML conveniences do not apply.

Constraining the Learner Set with estimator_list

A default FLAML run searches across model families. The README shows how to narrow that: automl.fit(X_train, y_train, task="classification", estimator_list=["lgbm"]) restricts the search to LightGBM. This matters for two reasons. First, it makes the result more predictable, since you know which library produced the final model and can reason about its behaviour and deployment footprint. Second, it converts FLAML from an AutoML tool into a hyperparameter tuner for a specific learner, which the README states directly: you can use FLAML as a fast hyperparameter tuning tool for XGBoost, LightGBM, Random Forest, or a customized learner. The trade-off is real. Restricting estimator_list removes the model-selection benefit that is the library's main selling point, and you are then paying the FLAML dependency cost for a search loop you could point at a single estimator. The README also points to documentation for supplying a custom estimator and its search space, which is the path when none of the built-in learners fit.

Zero-Shot Defaults Without a Search Loop

The flaml.default module takes a different approach to the same problem. Instead of searching at fit time, it ships precomputed hyperparameter configurations and selects one based on the training data. The README's example imports LGBMRegressor from flaml.default and states it is used in the same way as lightgbm.LGBMRegressor, with hyperparameters set automatically according to the training data. This is the cheapest option in the package: no search budget is consumed because no search happens. The cost is that you get whatever configuration the default lookup selects, with no per-task optimization beyond that lookup. For teams that need a fast baseline before deciding whether a full search is worth the compute, this is the natural first step. It is also the option most likely to be misunderstood, since the API surface looks identical to the upstream library and the automatic behaviour is easy to forget when reading a later diff.

Installing FLAML and Choosing Extras

The base install is pip install flaml, which the README says brings in minimal dependencies. Feature-specific dependencies come through extras. For the task-oriented AutoML module the command is pip install "flaml[automl]". The README notes that each notebook example may require a specific option, and points to the installation page for the full list, so the extras you need depend on which notebooks or modules you intend to run. The interpreter constraint is stated plainly: the latest version requires Python >= 3.10 and < 3.14, and while other versions may work for core components, full model support is not guaranteed. That upper bound is worth checking before you plan an upgrade, because it is a hard ceiling on the supported range rather than a recommendation. Conda users can install from conda-forge. A minimal tuning-only workflow starts with the base package and the tune import; a classification or regression workflow that relies on the built-in learners needs the automl extra.

The autogen Removal and What It Breaks

The README carries a heads-up that AutoGen has moved to a dedicated repository and that FLAML no longer includes the autogen module. Any code that imports autogen through a FLAML installation will fail, and the fix is to depend on AutoGen directly rather than through this package. This is the clearest failure mode documented in the material. It also signals something about the project's direction: the LLM-agent functionality that once lived here is now maintained separately, and FLAML's stated scope has narrowed to automation and tuning, including tuning of inference hyperparameters for foundation models and configurations in MLOps and LMOps workflows. Teams that adopted FLAML partly for agent orchestration should treat that as a migration, not a version bump. The README does not describe a compatibility shim, so the import change is on you.

Where FLAML Is the Wrong Tool

The library optimizes a search, and a search needs something to search. If your model definition is fixed by policy, by a regulatory review, or by a paper you are reproducing, then an AutoML run that selects a different learner is not a benefit. You want a pinned configuration and a reproducible fit, and FLAML's value proposition does not apply. The same holds if your evaluation is expensive enough that you can afford only a handful of trials: the search still needs enough budget to explore, and with very few evaluations a hand-chosen configuration informed by domain knowledge is likely to beat an automated one. The README's emphasis on low computational resources describes the library's efficiency, not a guarantee that any budget suffices. There is also a version-boundary case. If your environment is pinned to Python 3.9 or earlier, or you are planning a move to 3.14, the stated support range excludes you, and the README's caveat about core components working on other versions is not a commitment to full model support. Finally, if your objective is not a Python function you can call and score, the tune layer has nothing to work with.

How This Differs from Optuna and Hyperopt

The closest comparison in the Python tuning space is Optuna, and the difference is in what the library assumes you are doing. Optuna is built around defining a search space and an objective, then running a study; model selection across families is your problem, not the library's. FLAML's AutoML class assumes the common tabular case and handles family selection as part of the search, which is why the three-line classification example works without you naming a learner. FLAML's tune layer is the comparable surface to Optuna's study API, and the distinguishing feature there is the budget framing: time_budget_s and low_cost_partial_config are first-class arguments in the README's example, not add-ons. Hyperopt occupies similar ground with a different search algorithm lineage. The practical question is whether you want a library that picks the model family for you. If you do, FLAML's AutoML layer saves configuration work. If you have already decided on LightGBM and only need the hyperparameters, the estimator_list restriction puts you in the same position as using a dedicated tuner, and the choice comes down to which search behaviour you prefer on your objective. The README does not publish comparison numbers, so that decision needs your own measurements.

Maintenance, Versions and the MIT Licence

FLAML ships under the MIT licence, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement with few obligations, and it is compatible with proprietary downstream products. This is a description of the licence text, not legal advice; if your organisation has specific compliance requirements, route the licence file through your own review. On cadence, the recent release history shows v2.4.1 in January 2026, v2.5.0 later that same month, and v2.6.0 in April 2026, with repository activity continuing into September 2026. The README attributes Python 3.11+ support, new estimators, and MLflow integration to contributions from the Microsoft Fabric product team, and FLAML is described as supported in Microsoft Fabric Data Science. That is a meaningful maintenance signal: there is a commercial product depending on the library, which tends to keep releases flowing. The offsetting cost is that the Python version window is narrow and moves. An upgrade path that keeps you inside >= 3.10 and < 3.14 needs planning, and the autogen removal shows that a module can leave the package between releases. Pin your FLAML version in production and read the release notes before bumping.

Editorial conclusion

Adopt FLAML if you want a scikit-learn style estimator that searches model families and hyperparameters within a declared time budget, or if you need the same search loop for a non-ML objective. Skip it if you need a fixed, auditable model definition, if you are pinned to Python 3.9 or earlier, or if you still import autogen from this package. Before committing, verify the installed extras match your task, confirm your interpreter falls inside the >= 3.10 and < 3.14 window, and run flaml.tune.run on a small slice of your own objective to see how the search behaves against your evaluation cost.

Official sources

1. License: MIT
2. microsoft/FLAML on GitHub
3. Project website
4. README
5. Releases