tbp.monty: a sensorimotor learning framework built on cortical column theory
Monty is a sensorimotor learning framework based on the thousand brains theory of the neocortex.
At a glance
- What is it?
- Monty is the Thousand Brains Project's reference implementation of sensorimotor learning, where many small models each learn a complete object model and vote on what the sensor is touching. It is an early beta, explicitly not production-ready, and the interesting question is whether its architecture is worth the integration cost today.
- Who is it for?
- Adopt Monty if you are researching sensorimotor inference or want to run the benchmark experiments in ./benchmarks/ and inspect the configs under src/tbp/monty/conf/experiment/ yourself. Do not adopt it if you need a stable inference API for a shipped product, since the README describes it as an early beta with frequent changes to core features.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Monty is aimed at, and the audience it assumes
Most machine learning systems that touch the physical world are trained on large static datasets and then deployed. Monty starts from a different premise: that learning should happen through movement, with a sensor gathering a stream of observations as it moves relative to an object, and that the resulting model should be updated continuously rather than frozen after training. The repository describes itself as an open-source, sensorimotor learning system following the principles of the neocortex, and the name is a nod to Vernon Mountcastle, who proposed cortical columns as a repeating functional unit across the neocortex.
The audience is narrow. This is not a library you drop into an application to classify images faster. The README states plainly that it is not production-ready code and calls it an early beta version that is functional but evolving. The documentation points readers to an application criteria page and a project roadmap, which is the right framing: this is a research codebase for people who want to work on the theory, reproduce the benchmark experiments, or contribute to the implementation. If you need a supported inference runtime, Monty is not competing for that slot.
How the learning loop is structured: sensor modules, learning modules, and voting
The architectural idea that separates Monty from a standard neural network is that the system is not one model. It is a collection of learning modules, each of which builds its own model of an object from the sensorimotor observations it receives, and the modules then exchange votes about what they think they are sensing. The README frames the project as following the principles of the neocortex, and the cortical column reference is the key: a column is treated as a repeating unit that can learn a complete model on its own, rather than as a layer in a hierarchy that only becomes useful in aggregate.
That design has a direct consequence for how data flows. Observations arrive from a sensor, they are routed to learning modules, each module updates its internal model, and the modules reach a consensus through voting. Because each module is a full model rather than a partial feature extractor, the system is intended to handle learning from few exposures and to keep working when parts of the input change. The README does not spell out the voting mechanism in the top-level text, so the precise voting algorithm and the module-to-module message format have to be read from the full documentation and the API reference rather than inferred from the repository front page. That is a real gap for anyone evaluating the approach from the README alone.
What the README does make concrete is that the system is evaluated against a defined set of sensorimotor tasks, with results published in the benchmarks directory and configs under src/tbp/monty/conf/experiment/. Those benchmark runs are rerun whenever a functional change lands, and results are updated. That is a useful discipline: it means the project treats performance as something that must be re-established after each change, not as a one-time claim.
Getting it running: what the repository actually tells you
The README does not inline installation commands. It points to a getting started page in the documentation for installing project requirements and running the system. The only environment detail visible in the repository front matter is the Python version badge, which shows 3.8. Anyone planning to install Monty should treat the documentation page as the source of truth for setup, because the README deliberately does not duplicate it.
The parts of the repository layout that are visible are the ones that matter for running experiments. Benchmark configs live in src/tbp/monty/conf/experiment/, and the benchmark results and explanations live in ./benchmarks/ and on the benchmark experiments documentation page. That structure tells you the intended workflow: you select or write an experiment config, point the framework at it, and compare the result against the published benchmark numbers. It is a configuration-driven setup rather than a scripted demo, which fits a research project where the variables under study are the sensorimotor tasks themselves.
If you want to contribute rather than just run it, the README states that you must sign a Contributor License Agreement before contributing, with the CLA and guidelines linked from the contributing page. That is a gate worth knowing about before you start writing patches.
The early beta label is not boilerplate
Many projects describe themselves as beta and then behave like stable software. The disclaimer here is more specific than that. The README says to expect frequent changes as core features are developed. Combined with a release cadence visible in the repository metadata, where v0.49.0, v0.48.0 and v0.47.0 land roughly a week apart, the practical implication is that interfaces and config schemas can move between releases. If you build on Monty, you should expect to track releases rather than pin one and forget it, and you should expect that a config written against one version may need adjustment against the next.
The second limitation is documentation depth at the entry point. The README is a signpost, not a manual. It links to full documentation, API documentation, a roadmap, and application criteria, but the front page itself does not describe the voting algorithm, the sensor abstraction, or the module lifecycle in enough detail to reason about the system from the repository alone. That is a reasonable choice for a project with a separate docs site, but it means an evaluation of Monty requires reading at least three external pages before you can judge whether the architecture fits your problem.
The third constraint is scope. This is a sensorimotor learning framework, so problems that are purely static classification or purely offline batch training are outside what it is designed for. Using it as a general-purpose model library would mean fighting the architecture rather than using it.
How Monty differs from end-to-end deep learning
The natural alternative for most teams is an end-to-end deep learning model trained on a dataset of sensor readings or images. The difference in approach is structural, not just a matter of accuracy. An end-to-end model learns a single set of weights that maps input to output, and its internal representations are not organized around objects or reference frames. Monty instead decomposes the problem into many learning modules, each maintaining its own model, with voting to reconcile them. The claim in the project's own framing, which the README supports by citing a Neural Computation paper titled Thousand-Brains Systems: Sensorimotor Intelligence for Rapid, Robust Learning and Inference, is that this structure supports rapid learning and inference in a way that deep learning does not.
That claim is worth testing against your own requirements rather than accepting. The trade-off is that a multi-module system with voting has more moving parts than a single network: more configuration, more places for a module to diverge, and a consensus step that has to be tuned. In exchange, you get a system whose components correspond to interpretable units and whose learning is incremental by design. If your problem is well served by a pretrained model and a fixed dataset, the added structure buys you nothing. If your problem involves an agent that must learn about objects by moving a sensor over them, the mismatch between that problem and a static dataset is exactly what Monty is built to address.
There is also a citation path for the theory itself, with a list of neuroscience theory papers linked from the documentation. That matters if you are evaluating Monty as a research artifact rather than as a tool: the project expects to be read alongside the theory, not in isolation.
Licence, funding, and what that means for adoption
Monty is released under the MIT License, with the LICENSE file in the repository. MIT is permissive: it allows use, modification, and redistribution with minimal conditions, typically requiring preservation of the copyright notice and licence text. That is a permissive starting point for commercial evaluation, though the usual caveat applies that licence terms interact with your own dependencies and jurisdiction, and this is not legal advice.
Two governance details are visible and relevant. The project was initially started at Numenta and is now an independent non-profit, partially funded by the Gates Foundation. Independent non-profit stewardship is a different risk profile from a single-vendor project: the funding is disclosed, and the project publishes meeting recordings on YouTube and runs a Discourse forum, which gives a public record of how decisions are made. The flip side is that a research non-profit's roadmap is driven by research questions, not by user demand. Feature requests that do not serve the theory may sit.
The contributor path has its own gate: the CLA. If your organization wants to contribute code, the CLA is a prerequisite, and it is worth reading before you invest engineering time in a patch.
Editorial conclusion
Adopt Monty if you are researching sensorimotor inference or want to run the benchmark experiments in ./benchmarks/ and inspect the configs under src/tbp/monty/conf/experiment/ yourself. Do not adopt it if you need a stable inference API for a shipped product, since the README describes it as an early beta with frequent changes to core features. Before committing, read the application criteria page linked from the README, check the project roadmap for what is still unimplemented, and confirm that your Python environment matches the 3.8 badge shown in the repository.
Community notes