nanobind: near-pybind11 syntax, a compiled src tree, and benchmarks aimed at two rivals

The tree carries a src directory, so this is not header-only

The question of whether nanobind can be used header-only has a direct answer in the repository layout. The top-level entries include `include/`, `src/`, `ext/`, `cmake/`, and `tests/`, alongside `nanobind-backend/`, `CMakeLists.txt`, and `pyproject.toml`. A library with only headers would not need a `src/` tree to compile, and this one has both a build configuration of its own and a tests directory, which means code generation and compilation are part of how it is used. The presence of `nanobind-backend/` is the other structural clue: that is where the CPython backend integration sits, which lines up with the packaging metadata declaring a CPython-only implementation and a Python 3 only classifier. The build backend is scikit-build-core at 0.10 or newer, and `requires-python` is 3.10 or newer, so you consume nanobind as a normal Python dependency that builds native code rather than as a single header you drop into a project.

Version 3.2.0-dev1 with no GitHub releases behind it

The packaging metadata names the project `nanobind`, version `3.2.0-dev1`, authored by Wenzel Jakob at EPFL, described in one line as tiny and efficient C++/Python bindings. Two facts sit next to each other and are worth separating. The version string carries a development suffix, which is what a pre-release build of the next minor looks like. And the repository has no GitHub releases at all, so there is no tag on this repository to pin a build to, even though the README badge points at the PyPI project and another badge points at the Read the Docs changelog. Practically that means the published versions live on PyPI while the repository history lives on the master branch, whose last push was 2026-09-28. If your build needs reproducibility, the PyPI index is where you resolve a concrete version, not the tag list.

Three benchmark axes against pybind11, two more against Cython

The performance claim is stated as a set of ratios rather than absolute numbers, and it is attributed to a benchmarks page rather than to the project itself. Against pybind11 the README gives up to 4 times faster compile time, up to 5 times smaller binaries, and up to 10 times lower runtime overheads. Against Cython it gives 3 to 12 times binary size reduction, 1.6 to 4 times compilation time reduction, and similar runtime performance. Three things about how these are framed matter when you read them. Every ratio is qualified with up to, so the 10 times figure is a best case rather than a typical one. The Cython comparison ends at similar runtime performance, so the win there is size and build time rather than dispatch speed. And the source is the project's own benchmark page, which is where the methodology lives; the README itself reports only the conclusions. The library is also described as reminiscent of Boost.Python and pybind11 with near-identical syntax, which is the practical starting point for anyone arriving from either.

The Stable ABI is the reason JAX names it in a commit message

Of the six testimonials on the page, the one that explains a decision rather than a speedup comes from JAX, and its reason is packaging. The stated main reason for the switch is that nanobind can target the Python Stable ABI starting with Python 3.12, which means JAX will not need to ship per-Python-version CUDA plugins from that version onward. That is a different class of benefit from the benchmark ratios: it removes artifacts from the release matrix rather than shaving seconds off a build. The related measurement in the same area comes from the XLA/MLIR testimonial, where an MLIR lowering step for a Google-internal JAX model improves by around 5 seconds out of around 30. FEniCS and DOLFINx add a third axis, citing significantly improved support for wrapping multi-dimensional arrays, which they use heavily, and documentation that is easier to follow on low-level details, which makes the memory management in the wrapper layer easier to understand.

Six testimonials, three of them from Google, two on the same project

Reading the testimonial table as a distribution rather than a highlight reel changes what it tells you. There are six entries: IREE, XLA/MLIR, Apple MLX, JAX, FEniCS and DOLFINx, and PennyLane, the last of which is a release note quote rather than a named individual. Of the named attributions, three are Google, and two of those three concern the same effort, since XLA/MLIR and JAX are both quoted from Peter Hawkins. IREE is quoted from Stella Laurenzo, also at Google. That is a real pattern rather than a criticism: LLVM and JAX are the projects most likely to hit nanobind's specific combination of compile speed and Stable ABI targeting, and they are large enough to have measured it properly. The Apple entry, from MLX, credits nanobind with making it easy to move arrays between frameworks. The PennyLane note calls nanobind a natural successor to pybind11, citing the Stable ABI again.

The README carries no code, so the tutorial lives in two places

There is no code example in the README to copy. The only fenced block on the page is a BibTeX template for citing the library in scientific discourse, naming the author, the year 2022, and the repository URL as a note. Everything a new user needs is therefore external: the tutorial and reference documentation are offered in HTML and as a PDF, both from Read the Docs, the CI workflow is a separate badge, and a companion repository named nanobind_example is linked separately from the library itself. The documentation is built from the `docs/` directory using `.readthedocs.yaml`, and a changelog link sits alongside the badge row. So the reading order for a new user is the docs site for the tutorial, the example repository for a working setup, and the changelog for what changed, with the README serving as the project's positioning statement rather than its manual. That is a deliberate arrangement for a library whose selling point is near-identical syntax to something you may already know, but it does mean nothing on this page verifies the claims for you.

Licensing is a three-clause BSD, and the logo credit is separate

All material in the repository is licensed under a three-clause BSD license, and a `LICENSE` file sits at the root next to `CMakeLists.txt` and `.gitmodules`. The packaging metadata agrees, with an OSI Approved BSD License classifier, so license and metadata do not conflict here. `.gitmodules` indicates at least one dependency arrives as a git submodule rather than through the package index, which matters for build reproducibility since a submodule pin and a PyPI pin are different things to track. The last piece of attribution is cosmetic but worth recording: the nanobind logo was designed by AndoTwin Studio, with separate high-resolution downloads for the light and dark variants, so if you need the mark at print size it is not in the repository and has to be fetched from the design studio's link.

Editorial conclusion

Take nanobind if you are moving a pybind11 binding and want faster compiles, smaller wheels, or the ability to target the Python Stable ABI from 3.12 onwards, and expect to read the Read the Docs tutorial rather than the README, since the page carries no code example of its own. Check three things first: there are no GitHub releases for this repository, so `3.2.0-dev1` in `pyproject.toml` is what master claims to be and nothing here gives you a tag to pin. The adoption evidence is heavily concentrated, with three of the six testimonials coming from Google staff, two of them about the same project. And the speed numbers are the author's own benchmarks linked from a separate page, so read the methodology there before treating them as a guarantee for your own binding.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. wjakob/nanobind on GitHub