SapientML keeps the pipeline engine in a separate 0.8.x package while the wrapper ships 0.4.x

Two version lines: the wrapper at 0.4.x, the engine at 0.8.x

The idea is generative rather than search-based. Instead of trying many model families and picking the best score, SapientML learns from a corpus of existing datasets together with the pipelines people wrote for them, then generates a pipeline for a predictive task on a new dataset. The distribution arrangement splits that in half. The package you install depends on `sapientml-core` at `>=0.8.3,<0.9.0`, a separate distribution on its own version line, while the public package itself is published as 0.4.18 and 0.4.20. The two numbers move independently, so a working combination is a pairing of two version lines rather than a single pin. Around the core sit vector and search libraries, `lancedb` and `tantivy`, plus numpy held below 3.0.0, numba, pandas 2.x and pydantic 2.x. `nest-asyncio` is a dependency too, which is what lets a synchronous call site such as a notebook drive the asynchronous parts.

codegen_only is the product, and the second snippet renames the variable

The quick start fits a model and prints a score:

import pandas as pd
from sapientml import SapientML
from sklearn.metrics import f1_score
from sklearn.model_selection import train_test_split

train_data = pd.read_csv("https://github.com/sapientml/sapientml/files/12481088/titanic.csv")
train_data, test_data = train_test_split(train_data)
y_true = test_data["survived"].reset_index(drop=True)
test_data.drop(["survived"], axis=1, inplace=True)

cls = SapientML(["survived"])

cls.fit(train_data)
y_pred = cls.predict(test_data)

The interesting part is the second block, which reaches for the generated code itself through the `model` field and passes `codegen_only=True`:

model = sml.fit(train_data, codegen_only=True).model

model.fit(X_train, y_train) # build a model by using another data and the same generated code

y_pred = model.predict(X_test) # prediction by using generated code

model.save("/path/to/output") # save generated code to `path/to/output`

Note the variable: the first snippet calls the estimator `cls`, the second calls it `sml`, so the code that produces the artifact does not follow from the code above it as printed. The `model` object is what carries the output, with fit, predict and save, and `save` writes generated code to a directory rather than serialising a fitted object.

The quick example splits without a seed and drops a column in place

Three details in that snippet make its printed number illustrative rather than a measurement. `train_test_split` is called with no `random_state` and no `test_size`, so the split is re-randomised on every run and the F1 the example prints moves with it. `y_true` is taken with a `reset_index(drop=True)` while the predictions are compared against it, which is the right defensive move and shows the example was written by someone who hit that error before. The third is `test_data.drop(["survived"], axis=1, inplace=True)`: dropping in place on the second frame returned by a split mutates a slice of the parent frame, which is the pattern that produces pandas' chained-assignment warning and behaves differently across pandas versions. Nothing here invalidates the demonstration, but a reader copying it into a pipeline inherits all three habits.

Four examples, two dataset links, Colab as the only artifact

The examples table lists four datasets with their task type and target column: Titanic for classification on `survived`, Hotel Cancellation for classification on `Status`, Housing Prices for regression on `SalePrice`, and Medical Insurance Charges for regression on `charges`. Each row's code column is a link into a Colab notebook stored in the repository's `static/` directory. Two rows carry a dataset link, Titanic pointing at OpenML and Medical Insurance pointing at Kaggle; the Hotel Cancellation and Housing Prices rows have none, so those two notebooks have to fetch their data from somewhere the table does not say. The quick start above is a fifth path to the same data, and it does not use OpenML: it reads a CSV straight from a GitHub attachment URL under `files/12481088`, which is a pinned upload rather than a version-controlled dataset or a tagged release artifact.

The corpus that defines the tool is documented off this page

The mechanism depends on one input that this page never explains: where the corpus of datasets and human-written pipelines comes from and in what format it is supplied. The project describes itself as learning from that corpus and generating a pipeline for a predictive task, and the target column is passed as a list, `SapientML(["survived"])`, which is the only visible hint about how a task is described. Everything else is deferred to a single pointer, a documentation link to the hosted usage page on readthedocs, and the tree holds no dataset format, no corpus schema and no example corpus directory. The examples directory is absent too; the only notebooks are the four Colab files under `static/`. So the part of the system that decides what a good pipeline looks like is specified in prose and demonstrated on four datasets, with no worked corpus to inspect.

Version 0 in pyproject and a tomlkit ceiling for the linter

The packaging metadata carries one version field that reads `0`, while the published releases are numbered 0.4.17, 0.4.18 and 0.4.20, so the version is supplied by the release process rather than committed in the file. The release list also skips a number: 0.4.18 was published on 2026-10-01 and 0.4.20 on 2026-10-02, with no 0.4.19 appearing between them, while 0.4.17 dates from 2026-03-23. The dependency section has its own hard edges. Python is held to `>=3.10,<3.14`, which matches the 3.10 to 3.13 range stated in the installation notes, and one dev dependency is capped for a specific reason: `tomlkit = "<0.15.1"`, because the comment above it records that the pysen TOML exporter is incompatible with tomlkit 0.15.1's multiline comment validation. That is a real constraint on anyone's toolchain rather than a style preference.

A 2022 ICSE paper, two Fujitsu maintainers, one unfinished citation

The technique comes from a paper presented at ICSE 2022, SapientML: Synthesizing Machine Learning Pipelines by Learning from Human-Written Solutions, with a DOI and an arXiv entry, and the repository embeds the BibTeX record for it. That record is cut off partway through the abstract field, so anyone copying it gets an entry with a truncated abstract. The provenance is Fujitsu: the maintainers listed in the packaging metadata are two addresses at fujitsu.com, the authors field is the generic SapientML Authors, and the repository carries the governance furniture of a foundation-style project, with GOVERNANCE.md, CODEOWNERS, CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md and an AGENTS.md, plus a `.pysen` configuration for the Python linter the project uses. The last push is dated 2026-10-01 and the releases from that same week are 0.4.18 and 0.4.20, so the package is moving quickly even though the paper it implements is four years old.

Editorial conclusion

This is a code generator with a thin distribution layer, which makes it interesting for anyone who wants readable pipeline output rather than a black box score, and uninteresting for anyone who wanted a tuned model. Check three things first. The generated pipeline depends on a separate sapientml-core package on an independent version line, so pin both and expect to upgrade them together. The corpus that defines the tool's behaviour is documented on a hosted usage page rather than in the repository, so read that before designing around it. And treat the printed F1 as illustrative rather than measured, since the example splits without a seed and the paper behind the technique is from ICSE 2022.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sapientml/sapientml on GitHub