stan-dev/stan: the C++ core behind Stan's Bayesian inference

What stan-dev/stan actually is, and who it is not for

The repository is the C++ package that performs the inference. According to the README, it provides full Bayesian inference using the No-U-Turn sampler (NUTS), a variant of Hamiltonian Monte Carlo; approximate Bayesian inference using automatic differentiation variational inference (ADVI); and penalized maximum likelihood estimation using L-BFGS optimization. Those three are the computational methods the project ships, and everything else in the repository exists to serve them.

The audience is narrow. If you write a model in the Stan language and fit it from R or Python, you are not the primary user of this repository; you are a user of an interface that links against it. The README states that interfaces exist in R, Python, MATLAB, Julia, Stata, Mathematica, and for the command line, and that these live in separate repositories under the stan-dev organization. The people who need stan-dev/stan directly are the ones compiling the language, building a new interface, or working on the sampler and optimizer code itself.

That distinction matters because it changes what you install and what you can expect to find documented here. The README points to mc-stan.org for the home page and to the wiki for developer process, which is a signal that this repository is maintained as a component rather than as a product with an onboarding path.

The Stan Math dependency and the automatic differentiation layer

The inference algorithms do not stand alone. The README describes Stan as built on top of the Stan Math library, which supplies a full first- and higher-order automatic differentiation library based on C++ template overloads, plus a fully templated matrix, linear algebra, and probability special function library. The repository layout reflects this: there is a lib/ directory and a .gitmodules file at the top level, which is consistent with the math library being pulled in as a submodule rather than vendored.

This is the mechanism that makes the three methods possible. NUTS needs gradients of the log density with respect to the parameters; ADVI needs gradients for the variational objective; L-BFGS needs gradients for the penalized likelihood. All three get them from the same template-based differentiation layer in Stan Math rather than from hand-written derivatives.

The cost is that the C++ core is coupled to the math library's version. A change in the differentiation layer propagates into the sampler, and the .gitmodules entry is the place where that coupling is pinned. Anyone building from source should treat the submodule state as part of the build contract, not as an incidental detail.

Building from source: what the repository gives you

The top level contains a makefile, a make/ directory, runTests.py, src/, and lib/. That is a make-driven C++ build with a Python test runner, not a package manager workflow. The README does not provide install steps for the core library, so the commands below come from the repository layout rather than from documented instructions; treat them as a starting point for reading the build files, not as a supported procedure.

A typical invocation against this layout looks like this:

git clone https://github.com/stan-dev/stan.git
cd stan
git submodule update --init --recursive
make

The submodule step matters because of the lib/ and .gitmodules entries: without it the math library is absent and the build has nothing to compile against. The makefile at the root is the entry point the repository provides.

Testing is separate. The runTests.py script at the top level is the test driver the repository ships, and it is the file to read before assuming a particular test command. Because the README documents no install sequence, anyone adopting this should read makefile, make/, and runTests.py directly and confirm the toolchain requirements on their own platform.

The release cadence and the develop branch

The repository description states that the master branch contains the current release and the develop branch contains the latest stable development, and the default branch is develop. That is a meaningful choice: cloning the repository without specifying a branch gives you development code, not the released code.

The release history is regular. v2.40.0 was released on 2026-09-16, with v2.40.0-rc1 on 2026-09-09, and v2.39.0 on 2026-05-19. The last push to the repository was on 2026-09-23, five days after the v2.40.0 release, which is consistent with continued work on develop after a release rather than a dormant repository.

For anyone building against this, the branch question is the first decision. If you want what the interfaces ship against, you want the release branch. If you want the latest stable development, you want develop, and you accept that it moved after the last tag. The RELEASE-NOTES.txt file at the top level is where the changes between releases are recorded.

Where this is the wrong tool

The clearest failure mode is treating the repository as a way to do Bayesian inference. It is a C++ library. There is no command here that takes a model file and returns posterior draws; that comes from CmdStan or from one of the language interfaces, which the README lists as separate repositories.

The second limitation is licensing complexity, which the README spells out rather than hides. The Stan math library, core Stan code, and CmdStan are licensed under new BSD. RStan and PyStan are under GPLv3, with other interfaces having other open-source licenses. The README then notes that the math library depends on the Intel TBB library, licensed under Apache 2.0, and that this dependency implies an additional restriction compared to the new BSD license alone. Specifically, the README states that Apache 2.0 is incompatible with GPL-2 licensed code if distributed as a unitary binary, and points to the Licensing page on the Stan wiki. That is a real constraint for anyone embedding the core in a GPL-2 product, and it is not something a license file alone will surface.

The third case is platform support. The README does not document supported compilers, platforms, or a rollback path. If your environment is unusual, the repository does not answer whether it will build there.

How this differs from PyStan and RStan

The difference is architectural, not a matter of preference. PyStan and RStan are interfaces: they give you a way to express a model and call the sampler from Python or R, and they are licensed under GPLv3 per the README. stan-dev/stan is the C++ package that implements NUTS, ADVI and L-BFGS, licensed under new BSD along with the math library and CmdStan.

In practice this means the interfaces carry the inference code as a dependency rather than reimplementing it. If you want to change how NUTS behaves, or add a method, you work here. If you want to fit a model and get draws into a dataframe, you work in PyStan or RStan and never touch this repository.

The licensing split reinforces the separation. Choosing an interface also chooses its license, and the README is explicit that RStan and PyStan are GPLv3 while the core is new BSD. That is a decision point independent of which language you prefer.

Upgrade cost and what to verify before adopting

The release cadence is roughly every four months based on the tags shown: v2.39.0 on 2026-05-19 and v2.40.0 on 2026-09-16. For a downstream interface, that means tracking a moving core. The RELEASE-NOTES.txt file at the top level is the record of what changed, and the release candidate pattern (v2.40.0-rc1 nine days before the final tag) suggests a short stabilization window rather than a long one.

The upgrade cost is concentrated in the submodule pin and the C++ ABI surface. Because the math library is pulled in via .gitmodules, an upgrade means moving that pin, rebuilding, and re-running the test suite through runTests.py. The README does not describe a compatibility policy for downstream interfaces, so that question has to be answered by reading the release notes and the wiki.

On licensing, the practical check is the TBB dependency. If you distribute a unitary binary that combines this core with GPL-2 code, the README's note about Apache 2.0 incompatibility applies, and the wiki Licensing page is the referenced source. This is not legal advice; it is a pointer to the constraint the project itself documents.

Editorial conclusion

Adopt stan-dev/stan only if you are building or compiling the Stan language itself, or need the C++ core directly; users who just want to fit a model should install RStan or CmdStan instead, since this repository is the engine those interfaces call. Before relying on it, check the develop branch state against the v2.40.0 release, confirm the TBB and Apache 2.0 licensing note in the wiki, and verify the build works on your platform because the README does not document rollback or platform support.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. stan-dev/stan on GitHub