# nengo: neural modelling built on the Neural Engineering Framework

> nengo is a Python library for building and simulating large-scale neural models, spiking or not, with the Neural Engineering Framework as its organising idea. It gives you sensible defaults in a few lines and lets you replace neuron types, learning rules or the simulator itself, which is exactly what makes it a research tool rather than a deep learning framework.

**nengo/nengo** — A Python library for creating and simulating large-scale brain models

- Repository: https://github.com/nengo/nengo
- Website: https://www.nengo.ai/nengo
- Stars: 954 · Forks: 198
- Language: Python
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/nengo-nengo

## The framework is the abstraction, not the neuron model

Nengo is described as a Python library for building and simulating large-scale neural models. It can create sophisticated spiking and non-spiking neural simulations with sensible defaults in a few lines of code, and the readme stresses that it is highly extensible and flexible.

The organising idea is the Neural Engineering Framework, and the readme's own illustration points at a paper on the three principles of the NEF. That is the useful way to think about the library. It is not a collection of neuron models that happen to be spiking, it is a way of building networks in which populations, connections and computations are expressed in terms of decoded representations rather than raw synaptic weights.

What that buys you is a consistent way to say what a part of a network computes. A population represents a vector, a connection between two populations performs a particular operation on that vector, and the framework handles the encoding and decoding. The alternative, hand wiring weights for a specific computation, is exactly the work the abstraction removes.

The scope goes beyond simulation on a laptop. The readme lists defining your own neuron types and learning rules, getting input directly from hardware, building and running deep neural networks, driving robots, and simulating a model on a completely different neural simulator or on neuromorphic hardware.

That last item is the one to hold on to. Portability of a model between backends is the property that separates Nengo from a research script written against one particular simulator.

## Installing nengo and its NumPy dependency

Installation is a pip install, with one recommendation attached.

```bash
pip install nengo
```

Nengo depends on NumPy, and the readme recommends installing NumPy before installing Nengo, pointing at Anaconda as the route if you are unsure how. If the install gives trouble, the readme sends you to the more detailed installation instructions in the documentation before anything else.

For a source install, the readme points to the developer installation instructions rather than giving commands.

The dependency list in setup.py is short and stable. The only hard requirement is `numpy>=1.19`. There is an `optional` extra with `scipy>=0.13` and `scikit-learn`, a `docs` extra with Sphinx, Jupyter, matplotlib, nbsphinx, numpydoc and the nengo sphinx theme, a `tests` extra with pytest and the plugins described later, and an `all` extra that combines them.

The package version is read at build time by running `nengo/version.py` through `runpy`, so the version lives in the source tree rather than in setup.py, and setup.py itself is generated by nengo-bones, as are the pyproject settings for black, isort and docformatter. That generated-file discipline is worth knowing if you contribute, since it means formatting and packaging configuration are not edited by hand.

## Six examples that show what the abstraction buys

The readme points at a set of examples, and the selection is a better argument for the library than any description.

The first is 100 LIF neurons representing a sine wave, which is the smallest useful demonstration: a population, a decoded value, a periodic input. The second computes the square across a neural connection, which is the classic demonstration that a nonlinear operation can be implemented by a population and a connection rather than by a hand derived nonlinearity.

The third is controlled oscillatory dynamics with a recurrent connection, which shows what happens when a network is defined by its own dynamics rather than by a feedforward path. The fourth learns a communication channel with the PES rule, so it moves from a fixed network to a trainable one.

The fifth is simple question answering with the Semantic Pointer Architecture, which is a different layer again: vectors as symbolic items rather than as quantities. The sixth is a summary of the principles underlying all of these, which is the readme's own pointer to the NEF summary material.

Read as a set, they form a progression from a single population to recurrent dynamics, to learning, to symbolic structure. Each is a few lines of code in the library's own framing, and each is documented on the examples site with the code inline.

The point for an adopter is that the same abstractions hold across all six. You are not learning a different API for the learning example than for the oscillator.

## Extensibility is the reason to pick Nengo over a script

Three extensibility claims carry most of the weight in the readme, and they are the reason a research group chooses this kind of library over writing a script.

First, you can define your own neuron types and learning rules. The library does not insist on a fixed catalogue of neurons, so a group studying a novel neuron model implements it as a type and uses it inside a standard network. The same applies to learning rules, which matters when the learning rule is the object of study rather than a detail.

Second, you can get input directly from hardware. That is the bridge between a simulation and a physical system, and it is the part that turns a model into an experiment.

Third, you can simulate your model on a completely different neural simulator or on neuromorphic hardware. The model definition is the portable artefact, and the backend is swappable underneath it.

Two further capabilities are in the same list: building and running deep neural networks inside a Nengo model, and driving robots.

Together these describe a library whose unit of work is a model definition rather than a training run. If your research question is about dynamics, representation or learning rules, that framing fits. If your question is about gradient descent on a fixed architecture, it does not, and the abstraction adds indirection you would have to work around rather than benefit from.

## Testing leans on fixed randomness and closeness checks

The repository layout shows a testing setup that is more considered than a default pytest scaffold.

There is a top level `conftest.py`, a `pytest_nengo.py` module and a `.nengobones.yml` configuration file, along with a `nengo-data/` directory. The test dependencies list includes `pytest-allclose`, `pytest-rng` and `pytest-plt` alongside pytest itself.

The randomness plugin is the important one for a neural simulator. Spiking models are stochastic by construction, since spike timing varies run to run, so a test suite that asserts on exact values would be unusable. Fixing the random seed through a plugin makes those tests reproducible while still exercising stochastic behaviour.

The `nengo-data/` directory at the repository root suggests the library keeps some persistent data outside the package, and the fact that the project ships a plotting-based test plugin at all is a signal about the audience: people checking that a model behaves as expected, not just that code runs.

## Where Nengo is the wrong choice

The clearest case is a project that wants a trained feedforward network. Nengo is not a gradient descent framework, and the readme does not describe an automatic differentiation path or a training loop of that kind. Learning in Nengo, as the examples show, is rule based, for instance the PES rule for learning a communication channel. If your requirement is to fit a network to data with SGD and Adam, this is the wrong library and it will cost you time.

The second case is scale of raw computation. A Python library with NumPy as its only hard dependency is not where you go for throughput on large matrix work. The readme does not document a GPU path or a compiled backend, so any such route would come from an external project or hardware integration.

The third is the version story. The newest release is 4.0.0, published on 2023-11-17, preceded by 3.2.0 in 2022 and 3.1.0 in 2020. The last push to the default branch was on 2026-08-02, so work continues, but the gap between branch activity and published releases is large enough to ask about.

The readme's support statement is also dated. It says Nengo is tested to work on Python 3.6 and above, that Python 2.7 and 3.4 were supported up to and including Nengo 2.8.0, and that Python 3.5 was supported up to and including Nengo 3.1. Meanwhile the formatting configuration targets `py38` and the NumPy floor is `numpy>=1.19`, which is a much newer dependency than Python 3.6 would normally carry. Treat the readme's Python support line as historical and check the release notes for the current requirement.

## How Nengo differs from a deep learning framework

The comparison worth making is not with one particular library but with the standard approach to neural networks.

A deep learning framework starts from a tensor computation graph, trains it by differentiating a loss, and treats the trained weights as the model. The model is defined by its architecture and its data. Simulation is a by-product of the training run, and the trained network is what you deploy.

Nengo inverts that order. The model is defined first, as populations and connections that compute particular functions, and the simulator is a separate concern that happens to run that model. Learning is one of several ways to set the weights, alongside hand specified ones, and the framework does not require that you train at all.

That inversion has direct consequences. A model in Nengo is inspectable before it runs, which is what makes the square across a connection example possible, since the intended computation is stated rather than discovered. And because the model is separate from the backend, the same model can be run on a different simulator or on neuromorphic hardware, which is the portability claim in the readme.

The cost is that you are learning a vocabulary of representations and connections rather than a tensor API, and the model is only as good as the framework's assumptions about neural computation. For a neuroscientist or someone building spiking hardware, those assumptions are the point. For an engineer with a classification problem, they are overhead, and a conventional framework with a training loop will get there faster.

## Conclusion

nengo suits a researcher or engineer who wants to build biologically inspired spiking networks, connect them to real hardware, or run the same model on more than one simulator, and it is the wrong tool for a project whose only requirement is a trained feedforward network with standard gradient descent. Before adopting it, check that your Python version is covered by the current release rather than the older support statement in the readme, and confirm that the GPL version 2 licence in setup.py fits your distribution model, since that obligation is what distinguishes it from a permissively licensed numerical library.

## FAQ

### What is nengo?

It is a Python library for building and simulating large-scale neural models, spiking and non-spiking, organised around the Neural Engineering Framework. The readme says it creates sophisticated simulations with sensible defaults in a few lines of code while remaining extensible.

### How do I install nengo?

Run `pip install nengo`. Nengo depends on NumPy, and the readme recommends installing NumPy first, pointing at Anaconda if you are unsure how. The only hard dependency is `numpy>=1.19`.

### What can nengo models be used for?

The readme lists defining your own neuron types and learning rules, getting input directly from hardware, building and running deep neural networks, driving robots, and simulating a model on a completely different neural simulator or on neuromorphic hardware.

### Does nengo use gradient descent to train networks?

The examples show rule based learning, such as learning a communication channel with the PES rule, rather than a gradient descent loop. The readme does not describe an automatic differentiation based training path.

### Under what licence is nengo released?

setup.py declares the licence as the GNU General Public License, version 2, with the licence text in the LICENSE.rst file at the repository root. That is a copyleft obligation, which matters if you intend to distribute a product that embeds nengo.

## Sources

- [Issues](https://github.com/nengo/nengo/issues)
- [nengo/nengo on GitHub](https://github.com/nengo/nengo)
- [Project website](https://www.nengo.ai/nengo)
- [README](https://github.com/nengo/nengo/blob/main/README.md)
- [Releases](https://github.com/nengo/nengo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nengo-nengo