Monty: weekly minor releases, a benchmark suite as the gate, and a classifier that still says Alpha

The classifier says Alpha and the page says early beta

The two official signals about maturity disagree, and the metadata explains why it is behind. The package classifier reads Development Status 3, Alpha, and carries an inline comment saying to update it to Beta when the project starts using semver. The releases already look like semver, v0.52.0, v0.51.0 and v0.50.0, each with a v prefix and three numbers, so the condition the comment waits for appears to have arrived already. The disclaimer in the readme is the more informative statement: this is not production-ready code, it is an early beta version that is under active development, functional but evolving, and the page asks you to expect frequent changes as core features are developed. Read together, the intent is clear enough, a working research system that will move under you, with a stale classifier left behind by the versioning decision.

One minor release a week, with a benchmark rerun attached

The release history is dense and regular. v0.50.0 was published on 2026-09-17, v0.51.0 on 2026-09-24 and v0.52.0 on 2026-10-01, one minor version a week for three consecutive weeks, and the last commit on the default branch carries the same 2026-10-01 date. A weekly minor bump in a system at this stage of development implies that anything can change between versions, including the parts you depend on. What keeps that from being reckless is the policy described in the performance section: the system is regularly evaluated against a set of sensorimotor tasks, the experiments are rerun any time a functional change is made to the code, and the results are updated. So a weekly release is a weekly re-measurement, which is the arrangement you want from a research codebase even though the version numbers themselves promise no stability.

The benchmark experiments are the acceptance gate

The benchmark setup is where a change is judged, and it is organised so that anyone can rerun it. Results live in the benchmarks/ directory, and the configuration for each experiment sits under src/tbp/monty/conf/experiment/, so the run is defined by files in the tree rather than by a command line a maintainer remembers. The page describes the current numbers and an explanation of what they mean on the documentation site, which keeps the repository focused on the machinery. The policy statement is the part worth internalising: any functional change triggers a rerun and an update of the results. That is a stronger claim than a continuous integration badge, because it ties a specific number to a specific commit. It also means the honest way to evaluate a change of your own is to run the same suite, not to trust that the maintainers already did.

Two environment systems share one dependency list

The dependency block is written for both conda and uv at once, and the comments show it. Several entries carry a note that they are imported via conda with the conda-forge or PyTorch channel spelled out, while others carry environment markers splitting Python 3.8 from 3.9 and above, with one comment saying the newer scikit-learn line is for the uv environment. Alongside pyproject.toml and uv.lock the tree carries environment.yml, a separate environment_arm64.yml for Apple Silicon, and a UV_PROTOTYPE.md that reads like a note to self about the migration. One dependency carries a lifespan comment rather than a version: eval_type_backport is there to make pydantic work with future annotations and the note says it can be removed when the project reaches Python 3.10, which is also the boundary the markers describe. Anyone setting this up should decide whether they are a conda or a uv user first, because the two paths are maintained in parallel rather than unified.

Contributing requires signing a CLA on top of the MIT licence

The contribution path has a step that MIT projects often do not have. Before contributing, the page asks you to sign the project's Contributor License Agreement, with the document and the guidelines linked from the documentation site, and contributing guidance on a separate page. That means two separate instruments apply to a contribution: the MIT licence that covers the repository, whose LICENSE file is named in the licence section, and a CLA that is specific to this project. For an independent non-profit research organisation that may want rights beyond a bare licence grant, that is an ordinary arrangement, but it is worth knowing before you open a pull request rather than after. The root of the repository carries the paperwork, with CONTRIBUTING.md, CODE_OF_CONDUCT.md and a MAINTAINERS.md that names who to contact.

The root directory carries research process, not only code

The top-level entries describe how the project works as much as what it contains. There is an rfcs/ directory, which is where design proposals live before they become code, and a UV_PROTOTYPE.md sitting next to it as a working note rather than a document. Prose is linted: .vale.ini and a .vale/ directory mean documentation is checked for style in the same pipeline as code. There is a .git-blame-ignore-revs file, which lists revision ranges to exclude from blame, a normal thing to do after a reformat and a sign that one has happened here. A recipe/ directory suggests a conda recipe is maintained for packaging, and run.py and run_parallel.py sit at the root as the two entry points for single and parallel runs. The rest follows the expected layout with src/, tests/, tools/, docs/ and benchmarks/, so a reader can tell which parts of the repository are infrastructure and which are the system itself.

Three domains carry the documentation

The documentation is spread across three addresses and the repository does not reconcile them. The homepage field in the package metadata points at thousandbrainsproject.readme.io, the readme links the full documentation to docs.thousandbrains.org, and the API reference is hosted separately at api-monty.thousandbrains.org. An API reference on its own domain usually means a documentation generator publishing a build, which is convenient to consume programmatically and awkward to keep in step with a repository. The readme itself is thin by design: getting started is delegated entirely to the documentation site, and so are the application criteria, the list of current capabilities, the project road map and the contributing guidelines. The remaining local content is the benchmark explanation and the citation section. This is a deliberate split, but it means the repository cannot be read as a standalone introduction.

Monty is named after Mountcastle and the project began at Numenta

The origin story is short and worth quoting because it explains the vocabulary. This is the first implementation of a sensorimotor learning system from the Thousand Brains Project, and the name Monty comes from Vernon Mountcastle, who proposed cortical columns as a repeating functional unit across the neocortex. The project was started at Numenta and is now an independent non-profit, partially funded by the Gates Foundation, which is also why the repository is hosted under a project organisation rather than a company. Two citations are offered, and they are different in kind: the first is the 2024 Thousand Brains Project white paper for referencing the project itself, authored by Viviane Clay, Niels Leadholm and Jeff Hawkins, and the second is a 2026 Neural Computation article for referencing what Monty can do, with a wider author list. The community layer is a forum, a YouTube channel of meeting recordings, and a set of social accounts.

Editorial conclusion

Monty is worth reading and evaluating rather than adopting today, and the project is honest about which of the two it is offering. The disclaimer is unambiguous about not being production-ready, while the weekly tag cadence and the rule that any functional change reruns the benchmark experiments describe a research system held together by continuous measurement, which is a better position than an untested release. Three practical notes before you build on it. A Contributor License Agreement has to be signed before contributing, which is an extra step beyond the MIT licence the code ships under. The environment is described in two systems at once, conda files including a separate ARM variant and a uv lock file, so pick one. And the package classifier still reads Alpha with an inline note about switching to Beta when the project starts using semver, while the releases already carry a v prefix, so the metadata lags the repository.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thousandbrainsproject/tbp.monty on GitHub