BindsNET: Spiking Neural Networks on PyTorch Tensors
Simulation of spiking neural networks (SNNs) using PyTorch.
At a glance
- What is it?
- BindsNET simulates spiking neural networks by converting neuron ODEs into difference equations and solving them on torch.Tensor objects, so the same code runs on CPU or GPU. It is a research library for STDP-based learning, not a drop-in deep learning framework.
- Who is it for?
- Adopt BindsNET if you are doing biologically inspired SNN research with STDP and want tensor-level control over neuron and synapse state on CPU or GPU. Do not adopt it if you need a maintained general-purpose SNN framework with a large user base, or if AGPL-3.0 is incompatible with how you plan to distribute your work.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- 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 gap BindsNET fills: spiking dynamics without leaving PyTorch
Most neural network code in PyTorch assumes continuous activations and backpropagation. Spiking neurons do not work that way. Their behaviour is described by ordinary differential equations, and the README is explicit that PyTorch does not support solving differential equations directly. BindsNET's answer is to convert those ODEs into difference equations and solve them at short regular intervals, described in the README as a dt on the order of 1 millisecond. The project frames this as an approximation, and notes that packages like brian2 do the same thing under the hood. The audience is narrow and stated: researchers applying spiking networks to machine learning and reinforcement learning, specifically work connected to the BINDS lab at UMass and the Allen Discovery Center at Tufts. If you want a production inference runtime for neuromorphic hardware, this is not that. If you want to express a neuron model as a tensor computation you can move to a GPU, this is aimed at you.
How the simulation actually runs: tensors, dt steps, and STDP
The mechanism is a state update loop over torch.Tensor objects. Because the state lives in tensors, the README points out two consequences: state can be transferred to and from GPU devices, and functions from torch.nn.functional such as convolution and pooling can be reused instead of reimplemented. Learning is handled by spike-timing-dependent plasticity. The README traces the idea from Hebb through Markram et al. (1997), and states that BindsNET uses STDP to modify the weights of synapses connecting pairs or populations of neurons. The stated goal in the ML case is to learn a synapse weight setting that produces data-dependent spiking activity, which is then used for a task such as discriminating or clustering input data. That is the whole data flow: input is encoded into spikes, the network is stepped forward at each dt, neuron state and synapse weights are updated as tensors, and the resulting spike activity is read out. Nothing in the supplied material describes a compiled graph, a scheduler, or a hardware backend, so treat this as a Python-level simulation loop whose speed depends on how well the operations map onto tensor kernels.
Installing BindsNET and running the MNIST example
Python support is stated as >=3.11,<3.14, continuously tested on 3.11, 3.12 and 3.13. Two install paths are documented. For a pinned environment, the README gives poetry install against the committed poetry.lock. For pip, the stable release comes from the repository with pip install git+https://github.com/BindsNET/bindsnet.git, or from a clone with pip install . and pip install -e . for editable mode. A Dockerfile is provided, and the README gives the sequence docker build ., then docker tag <IMAGE_ID> <NEW_IMAGE_ID>, then docker run -it <NEW_IMAGE_ID> bash. The first thing to run is the Diehl and Cook 2015 MNIST replication: cd examples/mnist followed by python eth_mnist.py. That script takes command-line arguments, including --plot for monitoring figures, --n_neurons [int] for the number of excitatory and inhibitory neurons, and --mode ['train' | 'test']. The README directs you to --help for the rest. Tests run with python -m pytest test/, and the README warns that some tests fail if OpenAI gym is not installed. Datasets are not bundled: loaders fetch them from upstream, and DATA.md is declared as the place where each dataset's source, retrieval method, license pointer and spike-encoding preprocessing are listed. REPRODUCING.md maps each shipped model and published claim to its model class, script, exact command, seed and expected output.
Where BindsNET stops being the right tool
The README's own framing is the clearest limitation. Calling the difference-equation approach an approximation, at a dt on the order of 1 millisecond, means accuracy is a function of a timestep you choose, and the project does not present an adaptive solver. The learning story is STDP, which is local and unsupervised in the way the README describes it. If your problem needs gradient-based training through time, this is not the library for it. Second, the optional dependency situation is real: the README states that some tests fail without OpenAI gym, so a clean pytest run is not guaranteed on a minimal install. Third, the release cadence is uneven. Version 0.3.1 landed in February 2022, 0.3.3 in October 2024, and 0.3.4 in June 2026. That is not abandonment, but it is not a project where you should expect same-week fixes either. Fourth, the licence is AGPL-3.0, which is a strong copyleft. For research code this is usually fine; for a product you distribute, it changes what you can do with the source, and that is a question for your own legal review, not something this article can settle.
BindsNET versus Brian2: tensors against a dedicated simulator
The README names brian2 directly, and the comparison is honest about the trade. Brian2 is a simulator built for solving differential equations, with its own equation syntax and code generation. BindsNET does not compete on that ground. It gives up a purpose-built ODE front end in exchange for living inside PyTorch, which buys two things the README calls out: torch.Tensor state that can move to a GPU, and reuse of torch.nn.functional operations like convolution and pooling. So the decision is not which simulator is more accurate. It is whether your work benefits more from a differential-equation DSL or from being able to mix spiking layers with ordinary PyTorch modules and tensor operations in one process. If your pipeline is already PyTorch and you want spiking dynamics inside it, BindsNET's approach fits. If your work is primarily about neuron model fidelity and you want a mature equation language, Brian2 is the more direct instrument, and the README effectively concedes that point by noting both packages do the same numerical thing underneath.
Maintenance, versioning and the AGPL-3.0 licence
BindsNET has no homepage listed, and its releases are tagged rather than continuously delivered: 0.3.1 in 2022, 0.3.3 in 2024, 0.3.4 in 2026. The 0.3.3 tag carries the name Multicompartment Connection, which suggests the project is still adding modelling capability rather than only patching. The repository is not archived, and the last push date is recent relative to the 0.3.4 release. The pinned poetry.lock and the Dockerfile are the practical answer to upgrade risk: if you need a reproducible environment, the README's recommended path is poetry install or the Docker image, not an unpinned pip install. The licence is AGPL-3.0. That is a copyleft licence with a network-use clause, and it is the single constraint most likely to matter to a team that wants to embed this in a hosted service. Nothing here is legal advice; the point is simply that AGPL-3.0 is a deliberate choice by the maintainers and you should read it before you build on top of the code.
Who should adopt BindsNET, and what to check first
The fit is a researcher or lab engineer who wants to express spiking neuron and synapse dynamics as PyTorch tensors, run them on a GPU, and use STDP for unsupervised learning on tasks like MNIST digit discrimination. The example set, the REPRODUCING.md mapping from claims to commands and seeds, and the DATA.md dataset inventory are the parts that make this adoptable for that work, because they let someone else rerun your result. The misfit is anyone who needs a general-purpose SNN framework with a large community, or who needs permissive licensing for a distributed product. Before you invest, do three concrete things. Run python eth_mnist.py from examples/mnist and confirm it completes on your hardware. Check that your interpreter is inside the stated 3.11 to 3.13 window, since the README gives no support statement outside it. And read DATA.md and REPRODUCING.md before you build a pipeline, because the datasets are fetched from upstream rather than shipped, and the spike-encoding preprocessing for each one is declared there rather than in the code you are about to write.
Editorial conclusion
Adopt BindsNET if you are doing biologically inspired SNN research with STDP and want tensor-level control over neuron and synapse state on CPU or GPU. Do not adopt it if you need a maintained general-purpose SNN framework with a large user base, or if AGPL-3.0 is incompatible with how you plan to distribute your work. Before committing, verify that your Python version falls inside the stated 3.11 to 3.13 range, run the eth_mnist.py example to confirm the stack works on your hardware, and read the README's own admission that some tests fail without OpenAI gym installed.
Community notes