sb3-contrib points you at its parent's paper for citation and at master for install

The install instructions point at two git repositories and pin neither

There are three install commands here, and the third pair has no version in it at all:

pip install sb3-contrib

pip install git+https://github.com/DLR-RM/stable-baselines3
pip install git+https://github.com/Stable-Baselines-Team/stable-baselines3-contrib

The second block is the one the project actually recommends. It asks you to use the master version of Stable-Baselines3, and it points at two different organisations along the way: the parent lives under DLR-RM and this package under Stable-Baselines-Team. Neither git URL carries a tag, a branch other than master, or a commit, so a fresh install tracks the tip of both repositories and the two can move independently of each other.

For a research package that is a defensible choice, since the whole point is to track implementations of recent publications. It also means the version you get has no relationship to the release tags: v2.9.0 came out on 2026-06-15, but the documented install path never mentions it, and the last push to the repository was 2026-07-24.

The citation block describes the parent repository

The citing section opens by telling you not to cite this repository. It asks you to cite SB3 directly, and the BibTeX entry that follows has the key stable-baselines3 and describes Stable-Baselines3: Reliable Reinforcement Learning Implementations, six authors, Journal of Machine Learning Research, 2021, volume 22, number 268, pages 1 to 8, with a JMLR URL. There is no entry for the contrib package anywhere in it.

So the citation guidance is a routing decision rather than an oversight: implementations here are meant to be reported as part of the parent work, and anyone who needs a reference for a specific algorithm in this package is expected to cite that algorithm's own paper instead. Each algorithm in the feature list links directly to its publication, an arXiv identifier for most of them and an OpenReview forum for CrossQ.

A CITATION.bib file also sits at the repository root. The visible instructions cover the case of citing the project in a publication, and do not cover the case of listing dependencies or of acknowledging a specific contributed algorithm.

pyproject.toml configures tools while setup.py configures the package

The two configuration files do not overlap. pyproject.toml contains no project table and no build system table at all. It starts at the ruff section and carries the lint rule set, the black line length, the mypy settings, the pytest options, and the coverage options. Everything a user installs is declared in setup.py, which reads the version out of a version.txt file inside the package directory and holds the long description as a Python string rather than pointing at the README file.

The split has consequences worth knowing. Metadata changes require editing Python; formatting changes require editing TOML. And because the long description is a copy, the text a person reads on the package index is a snapshot that has to be kept in step with the README by hand, including the install commands, which are the part most likely to drift.

The lint configuration itself is modern and specific. Ruff runs at line length 127 with target version py310, selecting E, F, B, UP, C90 and RUF, and ignoring B028 for explicit stacklevel and RUF013 for implicit optionals. Black is pinned to the same 127, and the complexity ceiling is raised from the ruff default of 10 to 15.

mypy is switched off for five named files

The mypy block in pyproject.toml carries an exclusion pattern that names five paths individually rather than skipping a whole directory. Two are algorithms: sb3_contrib/ppo_recurrent/ppo_recurrent.py and sb3_contrib/ars/ars.py. Two are the recurrent infrastructure they depend on, sb3_contrib/common/recurrent/policies.py and sb3_contrib/common/recurrent/buffers.py. The fifth is a test, tests/test_train_eval_mode.py.

That is a deliberate cluster rather than scattered debt. Recurrent policies are exactly where the tensor shapes vary with sequence length, so the two algorithms that consume them plus the two modules that build them are the parts a type checker will complain about most, and they are turned off together.

The surrounding settings are permissive in a deliberate way: ignore_missing_imports is true, follow_imports is silent, and error codes are shown so a failure names its rule. Read together, the arrangement means the package is type checked everywhere except where the recurrent code is hardest to annotate, which is a sensible trade and also the honest answer to how much of this code is statically verified.

make lint fails on four rules and warns about the rest

The Makefile runs the linter twice for one reason, spelled out in its own comments. The first invocation selects E9, F63, F7 and F82 with full output, and the comment above it says to stop the build on Python syntax errors and undefined names. The second runs over the same paths with exit-zero, and the comment says exit-zero treats all errors as warnings.

So make lint is a syntax and undefined-name gate wearing a linter's clothes. The rest of the rule set, including the bugbear, pyupgrade and ruff-specific checks that the configuration selects, is reported and then ignored by the build. The same split shows up in formatting: make format sorts imports with a fix flag and then runs black, while make check-codestyle runs the import check without the fix flag and black with its check flag.

The phony declaration at the bottom lists lint, format, check-codestyle, commit-checks, doc and spelling. It leaves out pytest, mypy, type, release and test-release, even though all five are targets in the same file. The commit hook target is called commit-checks and runs format, type and lint, so the gate a commit passes through is narrower than the set of checks the file can run.

Deterministic test ordering is configured and then commented out

The pytest section carries a line that is present but switched off: an environment setting for PYTHONHASHSEED at zero, with a comment saying deterministic ordering for tests is useful with pytest-xdist. As written, nothing sets the seed, so test ordering under parallel execution is left to the interpreter.

Two warning filters are active. Deprecation warnings coming from tensorboard are ignored, and a warning whose text begins rich is experimental is ignored as well, which points at rich being used somewhere in the reporting path. A custom marker named slow is registered, with the deselection syntax spelled out in the marker's own description, so the slow tests are separable from the default run.

Coverage is configured to skip branch coverage entirely, with branch set to false, and to omit both tests and setup.py from measurement. Three line patterns are excluded from the report: the usual pragma comment, a bare NotImplementedError raise, and the type-checking-only import guard. The commented-out pyright block at the bottom points extraPaths at a sibling directory named torchy-baselines, which does not exist in this repository.

Seven algorithms and one gym wrapper sit under a full list elsewhere

The features section opens by sending you to the documentation for the full list, then gives eight items. Seven are algorithms: Augmented Random Search, Quantile Regression DQN, PPO with invalid action masking, PPO with a recurrent policy, Truncated Quantile Critics, Trust Region Policy Optimization, and CrossQ, which is batch normalization applied to deep reinforcement learning. The eighth is the only gym wrapper named, a Time Feature Wrapper that appends time to the observation.

One wrapper against seven algorithms is an odd ratio for a repository whose stated purpose includes environment wrappers, and it is worth reading against the mission statement. The project describes itself as the place for code that was too niche for the parent or too awkward to integrate cleanly there, and says almost everything remotely useful goes. The narrower visible list is consistent with that: the algorithms are the things worth announcing, while the wrapper surface is expected to be discovered in the documentation.

Documentation is hosted at sb3-contrib.readthedocs.io, built from the docs directory with a readthedocs configuration at the root, and the contributing guide is a single file the project asks you to read before sending anything.

Editorial conclusion

Use sb3-contrib when you specifically want one of the seven named algorithms, because that is the whole contract: anything considered too niche for the parent repository lands here, along with environment wrappers and extended action space support. Two things to settle first. Installation is unpinned by design, since the documented route installs both this package and Stable-Baselines3 straight from git master, so decide whether you want a moving target or a released version before you start. And if you cite this work, cite the parent's JMLR paper, because the citation the project hands you describes stable-baselines3 and not this repository. The typing story is worth knowing about too, since five files, including the recurrent policy and buffer code and the ARS implementation, are excluded from mypy. Documentation lives at sb3-contrib.readthedocs.io, not in this file.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Stable-Baselines-Team/stable-baselines3-contrib on GitHub