Open source IDE for Jupyter · 2.1.0
Zasper is an IDE for Jupyter, built in Go. It runs the notebooks and kernels you already have in a fraction of the memory, with your coding agent beside them to read, edit and run cells.
Written about, talked about, and supported by
Supporter
Supporter
Agents
Claude Code, Gemini CLI, Codex or any agent that speaks ACP, in a panel beside the notebook it is working on. Zasper gives it the live kernel, and every change it makes is yours to review and undo.
Signed in with your own subscription. Zasper holds no key and sends none of the conversation anywhere.
It reads cells and outputs, edits cells, runs them, and inspects variables and dataframes. Plots come back to it as images.
It asks before it edits a file or runs a command, unless you allow it. Each run shows in its cell, under the agent's name.
Every file a turn changed is listed with a diff. Put back one change, one file, or the whole turn.
zasper mcp.Zasper is an MCP server too. Register it once, and Claude Code, Codex, Cursor or Gemini CLI drives the notebooks you have open, each run landing in its cell as you watch.
Coding agents covers the panel, its permissions and undo; MCP server covers agents you run outside Zasper.
Open by design
A hosted notebook keeps your work in its cloud, in its format, and on its bill. Zasper is a binary you run, on files you already have.
Notebooks stay in your own folder, saved as Jupyter saves them. Nothing to import, and nothing lost on the way out.
Claude Code, Gemini CLI, Codex or any ACP agent, on your own subscription. No AI credits to buy, and no key held.
Code, data and outputs stay where you put them. Run it for a team on a box you control.
AGPL-3.0: install it, run it, change it. A commercial license is there for products that need one.
Weighing it against a hosted platform? Zasper and Hex, side by side.
Benchmarks
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 uses less of both at every load, and the RAM gap grows with concurrency, from about 4× at 2 kernels to 38× at 100. At 64 kernels Jupyter Server begins losing kernel connections, and by 100 it has lost all of them, while Zasper answers every request at both loads.
100 concurrent kernels
38× less RAM
1.1× less CPU
Jupyter Server is dropping replies
CPU is averaged across each run; RAM is the highest figure observed. The figures above round the widest gaps: 4.5× less CPU at 4 kernels and 38× less RAM at 100. At 2 kernels the difference is about 3× for CPU and 4× for RAM. The CPU gap does not grow with load, while the RAM gap does. The crosses are measured the same way as the lines, as replies received against requests sent, which is flat at five replies per request until a server stops answering. Jupyter's 14% CPU at 100 kernels is 14% while returning nothing. Every point is recomputed from the raw runs in zasper-benchmark, where the harness and the methodology are public.
Features
Every screen below is from a running session.
Query PostgreSQL, DuckDB, Snowflake and more, or your DataFrames, and get a DataFrame back for the next cell.
Your registered kernels, conda environments and project .venv, one click
from a new notebook.
Your own shell, in a panel below the notebook you are working in.
Branch, stage, commit and diff without leaving the window. No extension to install.
Zasper reads and writes .ipynb at each file's own nbformat version and runs the
kernels you already have, so the notebooks in the screenshots above are ordinary Jupyter
notebooks.
Also included
Smaller features, in the same download.
Page, sort, filter and chart a frame in its cell, and turn the chart into code.
Close the tab or lose the connection mid-run; every line the cell printed is there when you come back.
What changed, cell by cell, with execution counts left out of it.
Completions, go to definition, find references, rename, and quick fixes, in notebook cells as well as in files.
A word in any file, notebooks read as cells rather than as JSON, and a replace you see before it happens.
Every cell and what it printed. Matches in outputs are shown but not replaced.
Rendered in a tab, side by side with their source where that helps.
A notebook as an HTML page, as Markdown, or as a plain script in the kernel's language.
Your headings, in a column beside the cells, for the notebook that got long.
Per project, across a restart, reading each file only when you first switch to it.
Every command with its key binding beside it, and files in the same box.
Four hues, light and dark, and the editor's syntax colours follow.
Kernels
Zasper launches kernels through Jupyter's own kernelspec mechanism, so a kernel that runs under Jupyter runs here without being registered again.
Python covers two implementations, ipykernel and Xeus (xeus-python).
Every registered kernel is listed, and so is any Python environment Zasper finds with
ipykernel in it. The launcher above shows three Python kernels, one of them Xeus.
Installing kernels walks through adding your own.
Deployment
The same binary either way. Run it on the machine in front of you, or put it on a box and open it from anywhere. A footprint this small is what makes a shared server cheap.
Every server starts with an access token. Sign in with the link it prints, or paste the token; set it yourself to keep it across restarts.
A reverse proxy in front, WebSockets passed through, and the certificate you already have.
A Dockerfile and a Compose file to build and run it in a container, and a systemd unit for when it should come back up with the machine.
Deploying on Cloud walks through all three, and both ways to sign in.
Get started
Ten minutes from nothing to a notebook you have run and saved.
Homebrew, snap, conda, or the binary for your platform. No runtime for Zasper
itself; notebooks need a Jupyter kernel, and pip install ipykernel is
enough to start.
Make one, put it on a kernel, run a cell, write down what it was for, and save it, step by step, with a picture of each.
Your first notebookRegister the conda or uv environment you already work in as a Jupyter kernel, and it appears in the kernel list.
Working with CondaLicense
Zasper is dual-licensed. Use it under the GNU Affero General Public License, or under a commercial license when the AGPL's terms do not fit what you are building.
Running Zasper, on your own machine or on a server, needs nothing more. If you distribute Zasper, or let people use a modified version over a network, the AGPL requires you to make the corresponding source, including your changes, available under the same license.
Read the licenseFor organizations that want to build Zasper into a proprietary product, keep their modifications private, or need terms the AGPL does not offer.
prasun@zasper.ioContributions are accepted under the Contributor License Agreement, which is what lets Zasper be offered under both licenses.
FAQ
For your notebooks and your kernels, yes: the same files, the same kernelspecs, the same wire protocol. For JupyterLab itself, no. This is a separate implementation with its own interface, not a re-creation of Lab's UI or its extension API.
A hosted platform runs your code in its own cloud and keeps projects in its own format.
Zasper runs on your machine or your server, your notebooks stay .ipynb files
in your folder, and your agent runs on your own subscription. Hex does more for a team
publishing dashboards to people who do not code; Zasper is for the people writing the
notebooks. Zasper and Hex, side by side has the details.
No. Zasper has its own extension model rather than Lab's, so a lab extension will not load. If an extension is the reason you are staying, that is a fair reason to stay.
Yes, and there is a Windows build. The one part that needs WSL is the built-in terminal, which is built on a Unix pseudo-terminal; running the server under WSL gives you that too and is the setup we recommend.
Yes, under the AGPL-3.0: install it, run it, put it on your own server, change it. The commercial license is for building Zasper into a proprietary product, which the AGPL does not allow.
One registered as a Jupyter kernel appears in the launcher as it does in Jupyter,
without being registered again. Without a kernelspec, Zasper still lists one with
ipykernel in it if it is active when Zasper starts, is your base conda
install, or is the project's .venv in a trusted folder.
Claude Code, Gemini CLI and Codex, and any other agent that speaks ACP; Claude Code is the one tested most. Each runs on your own account and subscription, so Zasper adds no cost and holds no key. Agents you run outside Zasper can use it through its MCP server.
No. Zasper runs a server on your own machine and your files stay on it. A coding agent you
start talks to its own provider, as it does in a terminal. It sends
anonymous usage data, with no file names, paths, contents or IP address, and
ZASPER_TELEMETRY=0 switches it off;
PRIVACY.md is
the complete list. It also asks zasper.io once a day whether there is a newer
version, and loads widget libraries it does not bundle from jsDelivr unless
Load widget libraries from the internet is off in Settings.
Community
Zasper is developed in the open, by people who use it. What to know before you depend on it.
The open issues on GitHub, and a developer guide that gets you building from source in two commands.
Open issuesQuestions, ideas and "is this supposed to happen", in the open, where the answer is findable afterwards.
GitHub DiscussionsNo account to make, and your files stay on your machine.
A high performance IDE for Jupyter notebooks. Any Jupyter kernel, one static binary, and a fraction of JupyterLab's resource use.