Zasper is built from the ground up for massive concurrency: a minimal memory footprint, exceptional speed, and thousands of connections at once.
It speaks Jupyter's wire protocol, so it runs the notebooks you already have.
Both servers were run against the same workload — 10 requests per second per kernel, on an Apple M4 — from 2 concurrent kernels up to 100. Zasper starts ahead and stays ahead, and the distance grows with concurrency rather than shrinking.
CPU is averaged across each run; RAM is the highest figure observed, which is what “up to 40×” reports. At light load the difference is closer to 3–4× on both — the advantage is a function of concurrency, not a constant. Every point is recomputed from the raw runs in zasper-benchmark, where the harness and the methodology are public.
The numbers above are only half the question. Every screen below is a running session, not a mock-up.
Conda, uv, venv and every Jupyter kernel you have installed — detected on open and one click from a blank notebook or a shell. Nothing to register by hand.
Not an emulation. A full terminal that restores its session on reopen, in a tab beside the notebook it belongs to.
Underneath both: Zasper speaks Jupyter's wire protocol, reads and writes .ipynb at
its own nbformat version, and runs the kernels you already have — so the notebooks in the
screenshots above are the notebooks you have now.
Zasper launches kernels through Jupyter's own kernelspec mechanism, so a kernel that runs under Jupyter runs here — without being registered again.
Python covers both implementations: ipykernel and Xeus (xeus-python).
Conda, uv and venv environments are detected on open — the launcher above is showing nine of
them, two of which are Xeus kernels.
Installing kernels walks through adding your own.