The manifest says alpha, the tags say 0.27.0, and the version is not in the manifest at all

Two interface tiers and two method families, split by what you are optimising

The package is organised around one choice made twice. The first is how much control you want. Low-level interfaces let you fine-tune many aspects of the inference process; high-level interfaces exist so complex inference tasks can be set up quickly. The second choice is between method families, and the documentation is explicit about the trade. Amortized methods let you reuse a posterior estimator across multiple observations without retraining, which is the cheap path when you have many datasets. Sequential methods focus on individual observations and optimise the number of simulations required, which is the cheap path when simulations are expensive. The whole workflow is short enough to read in four lines, and its shape is the API contract:

from sbi.inference import NPE
# Given: parameters theta and corresponding simulations x
inference = NPE(prior=prior)
inference.append_simulations(theta, x).train()
posterior = inference.build_posterior()

Data goes in with `append_simulations`, training happens on the same object, and the posterior comes back from `build_posterior`, so the same estimator object carries the state through.

The classifier says alpha while the tags, the DOI and the feedstock say otherwise

The package metadata carries `Development Status :: 3 - Alpha` in its classifier list, which is a PyPI field people read before installing. Around it sit several signals of a settled project. The header links a journal article by DOI, 10.21105/joss.07754, and a NumFOCUS affiliated projects page, and the release list shows v0.27.0 published on 2026-08-04 after v0.26.1 on 2026-04-09 and v0.26.0 on 2026-04-02. There is a conda-forge feedstock, a codecov badge, a readthedocs configuration, and a `CITATION.cff` alongside a `codemeta.json`, which is two separate citation metadata files for one repository. The distribution also declares itself natural language English only, with no other language classifier. So the alpha marker is the one field in that list that has not been revisited, and it is the field a new user reads first.

The version is marked dynamic, so the manifest never states it

The project table has `dynamic = ["version"]`, which means the version is resolved at build time from somewhere else in the source tree rather than being written in the manifest. There is consequently no line in `pyproject.toml` to compare against a tag, and the only numbers a reader can find are the release tags. Those tags show a pattern worth noting: two patch-level releases three days apart in April 2026, then nothing until a minor release four months later in August. The last push to the main branch is dated 2026-10-02, roughly two months after the newest tag, so the working tree is ahead of the last release again. For a package where a trained estimator is a compatibility concern rather than a function signature, that gap is the number to keep an eye on rather than the alpha classifier.

One install line, three extras, and a pymc pin that only applies above Python 3.12

Installation asks for Python 3.10 or higher, says a GPU is not necessary though it can improve performance in some cases, and recommends uv for package management with a single command:

uv pip install sbi

The optional samplers are the interesting part. Pyro and PyMC samplers are described as optional and installed as extras: `sbi[pyro]` for Pyro samplers covering HMC and NUTS, `sbi[pymc]` for PyMC samplers covering HMC, NUTS and Slice, and `sbi[all]` for both. The manifest explains the pymc extra in a comment rather than leaving it implicit: pymc is required at 5.28.1 or newer only when the interpreter is 3.12 or newer, and the stated reason is that it avoids the pymc and arviz 1.x import break, with a pull request number. Conda, pixi and plain pip are handled by a separate installation guide. Two further extras exist, one for a tabular foundation model dependency and one for notebook tooling.

Two of the twelve runtime dependencies are there to draw things

The dependency list is PyTorch-centric and short enough to read: joblib, matplotlib, numpy, pillow, nflows at 0.14 or newer, scikit-learn, scipy, skorch, tensorboard, torch at 1.13 or newer, tqdm, and zuko at 1.2 or newer. The two entries that stand out are matplotlib and pillow, which are plotting and image libraries installed as hard requirements rather than extras, and tensorboard, which is a training visualisation tool and a default part of every install even when you never open it. The pair nflows and zuko are the normalising flow libraries behind the flow matching and flow based estimators, and skorch is the scikit-learn wrapper that lets a network be trained with the same interface as a scikit-learn estimator. So the practical cost of the package is a full PyTorch stack plus two display-oriented libraries, and the documentation does note that a GPU can help in some cases rather than promising a speedup.

The estimator names are the citations, one per paper

The methods section lists classes rather than concepts, and each class carries the paper it comes from. Neural posterior estimation appears in three numbered variants: the A variant, which also covers the amortized single-round NPE, from Papamakarios and Murray in 2016; the B variant from Lueckmann and colleagues in 2017; and the C variant, also called automatic posterior transformation, from Greenberg and colleagues in 2019. Beyond those sit TSNPE for truncated proposals from 2022, FMPE for flow matching from 2023, and NPSE for compositional score modeling from 2023. Neural likelihood estimation, the NLE or SNL pair, goes back to 2019, and neural ratio estimation starts with the A variant. The naming carries the family in the prefix and the variant in the suffix, with an S marking the sequential form, so the same paper appears under two class names depending on whether you want it amortized or sequential.

Verification is a three line import, and a test duration file is committed

The file tells you how to check an install, and it is the shortest section in it:

from sbi.examples.minimal import simple
posterior = simple()
print(posterior)

What that verifies is a working example end to end rather than a version string. The repository root tells you about the rest of the project's shape: a committed `.test_durations` file, which is how a test runner records which tests are slow so the suite can be ordered and sharded, a `pre-commit-config.yaml`, a `MANIFEST.in`, a readthedocs configuration, and both `AGENTS.md` and `CLAUDE.md` in the root. The documentation side is a Read the Docs project with Sphinx, myst-nb and jupytext, and the tutorials are Jupyter notebooks kept in the repository under `docs/tutorials`, so a tutorial you read in the docs is a file you can run. A separate 2025 tutorial paper with an arXiv identifier is recommended alongside them for the workflow and its diagnostics.

The licence badge points at master while the branch is main

Two small inconsistencies sit in a project that is otherwise careful about provenance. The header links the licence file at a URL containing the branch name master, while the repository's default branch is main, so that badge follows wherever GitHub redirects it or lands on a stale path. The second is in the documentation links: the navigation bar sends you to the Getting Started page under the stable documentation path, and a few paragraphs later the sentence recommending that same tutorial links to the latest path instead. Both are cosmetic rather than broken, since both targets exist. What they suggest is that the header block and the body were written at different times and are maintained separately, which is worth keeping in mind when you cite a specific documentation version, since the two links resolve to different builds of the same page.

Editorial conclusion

sbi suits a group with a working simulator and a real posterior to estimate, particularly one that wants to move between a high-level call and a low-level one without changing libraries. The choice that matters first is the method family: amortized if you will reuse one estimator across many observations, sequential if you want fewer simulations per observation. Before you build on it, read the coverage of your own language, since the extras are pinned per interpreter, and check the diagnostics rather than the posterior alone, because validation tooling is part of the package rather than something you add. And decide deliberately about the alpha classifier, which has survived every release up to 0.27.0.

Frequently asked questions

Official sources

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