Norse: Spiking Neural Network Primitives for PyTorch
Deep learning with spiking neural networks (SNNs) in PyTorch.
At a glance
- What is it?
- Norse adds leaky integrate-and-fire cells and stateful sequential layers to PyTorch, so you can build event-driven networks without leaving the autograd ecosystem. It is a tool for researchers who already know PyTorch and want spiking dynamics, not a shortcut to neuromorphic hardware.
- Who is it for?
- Norse is worth adopting if you already write PyTorch training loops, need leaky integrate-and-fire or recurrent LSNN layers, and want neuron state handled outside the layer so you can carry it across timesteps yourself.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 70 days 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 Norse fills between PyTorch tensors and spike trains
Standard PyTorch layers pass dense floating point activations forward. Spiking networks do something different: a neuron accumulates input over time and emits a binary event when its membrane potential crosses a threshold. That means a layer has to remember state between calls, and the state has to survive backpropagation through time. Norse supplies that missing piece. Its documentation describes the goal as expanding PyTorch with primitives for bio-inspired neural components, and the README frames the appeal as sparse, event-driven computation that differs fundamentally from artificial neural networks. The audience is narrow and specific: people who already run PyTorch training loops and want spiking dynamics inside them, rather than a separate simulator with its own graph format. If you have never written a custom nn.Module or a manual training loop, Norse will not hold your hand. The bundled tasks exist to show the pattern, not to replace your own pipeline.
How SequentialState and the LIF cell carry neuron state through time
The mechanism is visible in the README's convolutional classifier example. SequentialState wraps ordinary PyTorch modules and Norse cells in a chain, and calling the model returns a tuple: the output tensor and the neuron state. In the sample, a Conv2d layer feeds a LIFCell, which is the leaky integrate-and-fire activation, then pooling, another convolution, another LIFCell, flattening, a linear layer, and finally an LICell, described in the code as a non-spiking integrator. The state tuple is the important part. Because the state comes back to the caller, you decide whether to reset it between batches, detach it, or feed it into the next timestep. That is a deliberate design choice and it pushes bookkeeping onto you. The recurrent example is more explicit still: LSNNRecurrent is constructed with 2 input neurons and 10 output neurons, and the data tensor is shaped 20 timesteps by 8 batch items by 2 neurons. The time dimension sits first. Getting that axis order wrong is the most common way to produce a model that trains but learns nothing useful. The README attributes the LSNN architecture to Bellec, Salaj, Subramoney, Legenstein and Maass (2018), so the layer is a direct implementation of a published recurrent spiking model rather than an ad hoc invention.
Installing Norse and running the bundled tasks
The README states the prerequisites as Python 3.8 or higher and PyTorch 1.9 or higher. Four install paths are documented: pip install norse from PyPI, pip install -qU git+https://github.com/norse/norse from source, docker pull quay.io/norse/norse, and conda install norse. The example tasks are invoked as modules from the repository base directory. python -m norse.task.mnist trains an MNIST classifier, python -m norse.task.cifar10 trains on CIFAR, and python -m norse.task.cartpole runs a policy gradient cartpole task. Each accepts flags, which you can list with python -m norse.task.<task> --help. A Lightning variant is also shipped: python -m norse.task.mnist_pl --gpus=4, which the README notes requires PyTorch Lightning installed separately. The README points to Jupyter notebooks on Google Colab as the fastest way to try the library without a local install, and describes the example tasks as short, self contained, correct examples. That phrase matters. These are reference implementations for reading, and the console help output is the authoritative list of options for each one.
The state tuple is a footgun, and the release cadence is slow
The stateful return value is the library's most consequential design decision, and it cuts both ways. Nothing in the material suggests Norse resets neuron state for you between training iterations. If you loop over batches and reuse the state without thinking, membrane potentials leak across unrelated samples, and the failure is quiet: loss curves look plausible while accuracy stalls. The README's own example calls the model once on random data, which sidesteps the question entirely. Treat state management as your responsibility and write a test that checks a fresh state per batch. The second limitation is tempo. The release history shows v1.0.0 in January 2023, v1.1.0 in March 2024 with support for NIR and torch.compile, and nothing tagged since, even though the repository shows later activity. If your project depends on a steady stream of upstream fixes, that gap is a planning risk. The third limitation is scope. Norse implements spiking dynamics on top of PyTorch autograd. It is not a neuromorphic compiler. Nothing in the supplied material promises that a trained Norse model maps onto Loihi, SpiNNaker or any other event-driven chip, and the NIR support added in v1.1.0 is the only interoperability signal available here. If hardware deployment is your end goal, confirm that path exists before committing.
Norse versus snnTorch: state management and surface area
The closest widely used alternative is snnTorch, which also targets PyTorch and also provides spiking neuron layers. The difference in approach is worth stating plainly. Norse leans on explicit state objects: SequentialState returns a state tuple, LSNNRecurrent is a self-contained recurrent layer, and the library ships a small set of named cells such as LIFCell and LICell. snnTorch takes a more tutorial-oriented route, wrapping spiking behaviour in layers that resemble standard PyTorch modules and aiming at a gentler learning curve. Neither is strictly better. Norse's explicit state makes it easier to reason about what is being carried across timesteps, which matters for recurrent spiking models and for anyone implementing a paper exactly. snnTorch's flatter API is easier to drop into an existing network when you only want one spiking activation in the middle of a conventional model. Norse also bundles runnable training tasks and a Lightning variant, which snnTorch's documentation does not emphasise in the same way. If your work is a faithful reproduction of a recurrent spiking architecture, Norse's state handling is the more natural fit. If you want the smallest possible change to a standard classifier, the other library will get you there with less ceremony.
Maintenance, licence and what LGPL-3.0 means for your build
Norse is licensed under LGPL-3.0, and that is a real constraint rather than a formality. The LGPL permits use in proprietary applications, but it imposes conditions when you link against the library and modify it, particularly around the ability to relink with a modified version. Norse is a Python library imported at runtime, which is a different situation from static linking in C, but the boundary is genuinely fact-specific. This article is not legal advice, and I am not going to pretend the analysis is settled. If Norse ends up inside a product you ship, run the dependency past whoever handles licensing at your organisation before you build on it. On maintenance cost: the repository is not archived, the default branch is main, and the most recent push recorded is 2026-07-07, so there is ongoing activity. But the newest tagged release in the supplied material is v1.1.0 from March 2024. Installing from PyPI or Conda gets you that tag. Installing from source with pip install -qU git+https://github.com/norse/norse gets you whatever is on main today, which may include unreleased changes and their bugs. Pick one and pin it, because the two paths will not behave identically.
Editorial conclusion
Norse is worth adopting if you already write PyTorch training loops, need leaky integrate-and-fire or recurrent LSNN layers, and want neuron state handled outside the layer so you can carry it across timesteps yourself. It is the wrong tool if you expect out-of-the-box deployment to Loihi or SpiNNaker, or if you want a maintained, frequently released dependency: the last tagged release is v1.1.0 from March 2024, and the LGPL-3.0 licence means you should check with your legal team before linking it into a closed-source product. Verify first that your PyTorch version satisfies the documented 1.9 or higher floor and that torch.compile works on your target device, since that support arrived only in v1.1.0.
Community notes