# SpikeInterface: one Python interface over many spike sorters

> SpikeInterface does not sort spikes itself so much as it standardises the neighbourhood: one way to read extracellular recordings, one way to launch a dozen third-party sorters without installing them, and one way to post-process, curate, compare and visualise whatever comes back. The version numbers, the git-based dependencies and the packaging details are where the practical surprises are.

**SpikeInterface/spikeinterface** — A Python-based module for creating flexible and robust spike sorting pipelines.

- Repository: https://github.com/SpikeInterface/spikeinterface
- Website: https://spikeinterface.readthedocs.io
- Stars: 870 · Forks: 284
- Language: Python
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/spikeinterface-spikeinterface

## A framework whose own code base is deliberately thin

SpikeInterface is described as a Python package designed to unify preexisting spike sorting technologies into a single code base, and the repository description calls it a Python-based module for building flexible spike sorting pipelines.

The README then makes a point that reframes the whole project. If you use SpikeInterface you are also using code and ideas from many other projects, and the codebase would be tiny without the algorithms and formats it interfaces with. There is a references page that lists them all and explains how to cite them, which is the correct academic practice and a rare thing to see done carefully.

The pace of new integrations is the evidence that the strategy works. The README lists the tools added in the past year: dartsort, a modular drift tracking sorter for high density multi-electrode probes, Bombcell for automated curation and cell classification, SLAy for over-splitting errors, Lupin, Spykingcircus2 and Tridesclous2 from the modular spike sorting paper, rtsort for real time detection, MEDiCINe for motion correction, and UnitRefine, a community toolbox for automated sorting curation.

The audience is neuroscientists and electrophysiology groups, and the project is published on PyPI with the documentation on readthedocs, split into a stable version for the latest release and a development version. The version in the project file is 0.106.0, the licence is MIT, and the package requires Python 3.11 or newer.

The last push was on 2026-10-19, and there are no GitHub releases, so the version history lives on PyPI and the documentation badge tracks the published release.

## One sorter list, run either locally or in a container

The capability list in the README is the best description of what the framework actually does for a user, and the sorter entries are the centre of it.

The popular semi-automatic sorters supported are Kilosort 1 to 4, MountainSort 4 and 5, Spykingcircus, Tridesclous, IronClust, HerdingSpikes, YASS and WaveClus. On top of that there are sorters developed in house, listed as Lupin, Spykingcircus2, Tridesclous2 and Simple, and the README describes them as competing with Kilosort4.

That in-house line is worth pausing on, because it is the one place where the project does not just wrap. A modular sorting approach, where the components of a sorter are separated and recombined, is the direction the papers it cites describe, and having three such sorters in one repository means the framework can compare a classic sorter against a modular one on the same data through the same interface.

The second half of the answer is the container support. The README states that you can run these popular sorters without installation using containers, with Docker and Singularity both named. For a group that has to run Kilosort on a cluster, or reproduce a figure from a paper, that removes the worst part of the work, which is not the sorting but the environment.

Around the sorters sit the other capabilities: reading and writing many extracellular file formats, preprocessing recordings, and a full motion and drift correction framework.

## The SortingAnalyzer is where the real comparison work happens

After the sorting, the README lists post-processing of sorted datasets using the SortingAnalyzer, computing quality metrics to validate and curate the outputs, comparing and benchmarking spike sorting outputs, and exporting a report or exporting to Phy.

That is the part of the framework that distinguishes it from a launcher. A sorter produces a set of units, and the units from two different sorters are not directly comparable, because each sorter has its own clustering, its own templates and its own noise estimate. Putting them in one analysis structure and computing the same metrics over each is what makes a benchmark meaningful rather than a set of numbers from different pipelines.

Curation is the second half. The README lists several strategies, machine learning based, metrics based and manual, and a separate package, spikeinterface-gui, which offers a Qt-based or a web-based viewer for manual curation that replaces Phy. Keeping the viewer in a separate package is a sensible boundary, because the interface is a different kind of software from the analysis core and it has its own dependencies.

Visualisation is listed as one of the framework's capabilities with several routes: matplotlib, SortingView, Jupyter, and ephyviewer. The presence of several backends is the practical answer to the question of who is using this, since a lab that has standardised on one of those tools needs its output in a form it can already open.

The README also mentions having reusable sorting components to build your own sorter, which is the framework's long game: if the components are reusable, writing a new sorter is a matter of assembling them rather than starting from nothing.

## The dependencies are pinned by Python version and partly installed from git

The project file is where the practical surprises are, and there are two of them.

The first is that the numeric stack is conditional on the interpreter. numpy is required at 2.0.0 or newer below Python 3.14 and at 2.3.2 or newer from 3.14 onwards, zarr is pinned below version 3 for older interpreters and at version 3 or newer for 3.14, and numcodecs is likewise split, with the comment that the older bound is there to support zarr below 3. Another comment on the zarr 3 line says that zarr writing is not yet supported with zarr 3, which is a specific, checkable limitation rather than a vague one.

The second is that two dependencies are installed straight from git rather than from an index:

```toml
dependencies = [
    "numpy>=2.0.0;python_version<'3.14'",
    "numpy>=2.3.2;python_version>='3.14'",
    "threadpoolctl>=3.0.0",
    "tqdm",
    "zarr>=2.18,<3;python_version<'3.14'",
]
```

The neo and probeinterface packages are pulled from their git repositories, and the project file keeps commented out lines for the published versions with a note that the release needs PyPI. In other words, the published package depends on the tip of two other projects, which means a reproducible environment needs those commits pinned.

The rest of the packaging is conventional. The build backend is setuptools with 78.0.2 or newer, the sources live under src/ with the package discovery pointed there, and the package data configuration includes matlab and parameter files for the sorters, with patterns for m, prm, params and yaml, which is how the sorters that ship configuration templates carry them. The test files are excluded from the package data.

Those two details together are the practical advice: install with care, and expect the environment to be defined by the git state of its dependencies rather than by a lock file in this repository.

## Installing is one command, and the extras are wide

The install instructions are short, and the extra syntax is the main decision.

```bash
pip install "spikeinterface[full]"
```

The README notes that the quotes ensure the command works in all terminals and shells, which is a small detail that saves a confusing error on Windows. The full option installs all the extra dependencies for all the different sub-modules, which is the sensible default given how many optional backends the framework has, from sorters to viewers to exporters.

Interactive widget backends are a separate extra:

```bash
 pip install "spikeinterface[full,widgets]"
```

And there is a source installation for the latest updates, which clones the repository and installs it in editable mode:

```bash
git clone https://github.com/SpikeInterface/spikeinterface.git
cd spikeinterface
pip install -e .
cd ..
```

Beyond the package itself, the README points at several other resources rather than trying to fold them into the main documentation. There is a separate tutorials repository, spiketutorials, a YouTube channel with video tutorials, and a set of notebooks on the project blog that cover advanced benchmarking and sorting components, which is where the research-level notebooks live.

The repository itself is arranged the way you would expect a project with this many extras to be. There is a doc/ directory, an examples/ directory split into get started, how to, for how to and tutorials, an installation_tips/ directory, a conftest.py at the root for the test configuration, a codecov.yml, a readthedocs.yml, a pre-commit configuration, an AGENTS.md and a code of conduct.

## What to record when you publish a result

Two practical points are worth making before anyone builds a pipeline on this.

The first is that SpikeInterface standardises the interface, not the science. The sorters it wraps are different tools with different assumptions, and the metrics it computes are only as good as the sorting that produced the units. When a paper reports a comparison, the sorter name and version are part of the result, and the framework's own references page exists to make that citation possible. The README is unusually direct about this: you are using other people's code and ideas, and the project asks that they be cited.

The second is the release channel. There are no GitHub releases, so the version you get is whatever PyPI currently serves, and the documentation has a stable branch for the latest release and a latest branch for the development version. The version in the project file is 0.106.0, which is still a zero-major version, and the classifier set covers Linux, Windows, macOS and OS independent, with the intended audience declared as science and research.

There is also a documentation split worth knowing about. The detailed documentation of the latest PyPI release and the documentation of the development version are separate links, so a page you land on from a search result may describe a different version from the one in your environment. Reading the stable documentation when reproducing a published result, and the latest documentation when working with the source, is the rule that keeps the two apart.

For a group standardising on this framework, the practical win is consistency: one way to read the data, one way to launch the tools, one way to compute the metrics, and one place where the citations live.

## Conclusion

Adopt SpikeInterface if your work involves several spike sorters, or if you need to run a sorter you do not want to install, since the container path and the common interface remove the per-tool setup and the per-tool output handling. Do not adopt it expecting it to replace the sorters themselves, because the project's own framing is that it is a wrapper around other people's algorithms and formats, with its in-house sorters described as competing with Kilosort4 rather than replacing the field. Before you rely on a result, check which sorter produced it and record that, and confirm the zarr and numpy versions your Python version resolves to, since the manifest pins them conditionally and zarr 3 writing is not yet supported.

## FAQ

### What is SpikeInterface and what does it do?

It is a Python toolkit for analysis, visualisation and comparison of spike sorting output, designed to unify preexisting spike sorting technologies into a single code base. It reads and writes many extracellular file formats, preprocesses recordings, runs many spike sorters, computes quality metrics, supports curation strategies and provides several visualisation backends.

### Which spike sorters does SpikeInterface support?

The README lists Kilosort 1 to 4, MountainSort 4 and 5, Spykingcircus, Tridesclous, IronClust, HerdingSpikes, YASS and WaveClus, plus sorters developed in house, namely Lupin, Spykingcircus2, Tridesclous2 and Simple, which the README says compete with Kilosort4. The popular sorters can also be run without installation using Docker or Singularity containers.

### How do I install SpikeInterface?

The README gives pip install "spikeinterface[full]", where the full option installs all the extra dependencies for the sub-modules, and pip install "spikeinterface[full,widgets]" if you want the interactive widget backends. A source install clones the repository and runs pip install -e . from the project directory.

### What is the SortingAnalyzer used for?

For post-processing sorted datasets, so that the output of different sorters can be analysed the same way. The framework also computes quality metrics to validate and curate the outputs, compares and benchmarks sorter outputs, and can export a report or export to Phy.

### Does SpikeInterface have a graphical interface for manual curation?

The manual curation viewer lives in a separate package, spikeinterface-gui, which the README describes as a Qt-based or web-based viewer that replaces Phy. The framework itself is the analysis core, and the curation interface is deliberately kept apart from it.

## Sources

- [Issues](https://github.com/SpikeInterface/spikeinterface/issues)
- [License: MIT](https://github.com/SpikeInterface/spikeinterface/blob/main/LICENSE)
- [Project website](https://spikeinterface.readthedocs.io)
- [README](https://github.com/SpikeInterface/spikeinterface/blob/main/README.md)
- [SpikeInterface/spikeinterface on GitHub](https://github.com/SpikeInterface/spikeinterface)

---

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