Jupyter AI turns JupyterLab into an ACP client, not a chatbot

The chat panel is a front end for someone else's agent

The panel you open in JupyterLab is a client, and the intelligence sits in an agent you install separately. The listed agents are Claude, Codex, GitHub Copilot, Gemini, Goose, Kiro, Mistral Vibe and OpenCode. What Jupyter AI contributes is the Agent Client Protocol, ACP, on the browser side of the conversation. Detection is dependency driven: an agent shows up in the interface once its dependencies are present in the same environment, which is why the project describes setup as installing Jupyter AI plus the agent of your choice.

That design has a consequence for anyone evaluating it. Capability tracks the agent, not the extension. Jupyter AI cannot add a tool the underlying agent does not expose, and it cannot give a local model a chat interface it cannot speak ACP to. The trade is that you are not locked into one vendor's model lineup, and in exchange you take on the job of choosing and installing a client yourself.

Nine pinned JupyterLab packages sit under the chat panel

The cost of that design shows up in pyproject.toml, which lists a strict upper bound on every direct dependency. jupyterlab_chat is held between 0.25.0 and 0.26.0, jupyter_ai_router between 0.1.1 and 0.2.0, jupyter_ai_persona_manager between 0.2.0 and 0.3.0, jupyter_ai_chat_commands between 0.0.4 and 0.1.0, and jupyter_ai_acp_client between 0.3.0 and 0.4.0. Tool access arrives as jupyter_server_mcp between 0.3.0 and 0.4.0, jupyter_ai_tools between 0.7.0 and 0.8.0, and jupyterlab_commands_toolkit between 0.2.0 and 0.3.0.

This is worth reading twice before an upgrade. All of those packages are below 1.0, one (jupyter_ai_chat_commands) sits below 0.1.0, and each range forbids the next minor version. On a shared server that already carries other JupyterLab extensions, a resolver conflict is a realistic outcome, and the fix is not documented in the README. One detail that a skim misses: the version field is declared dynamic in pyproject.toml and the build backend is hatchling, so the version is not readable from the file you would normally check. Python 3.9 is the floor, and classifiers stop at 3.13. Distribution is BSD-3-Clause, written in pyproject.toml as a file reference to LICENSE rather than an SPDX string, and the last push was on 2026-10-31 on a repository that is not archived.

Optional groups decide whether magic commands and RTC exist at all

Features are split into optional extras rather than bundled. The magics group pulls jupyter_ai_litellm between 0.1.0 and 0.2.0 together with jupyter_ai_magic_commands between 0.0.4 and 0.1.0, which is what gives you percent magic syntax inside a cell. The jupyternaut group swaps the magic command package for jupyter_ai_jupyternaut, itself ranged from 0.1.0rc0 up to below 0.2.0, a pre-1.0 range. Real-time collaboration is described in a comment inside pyproject.toml as optional: you install one of two groups, rtc, which uses jupyter-collaboration, or rtc-jsd. jupyter_live_content between 0.1.1 and 0.2.0 is listed as a hard dependency rather than an extra.

So installing the base package does not give you the jupyternaut package or a collaboration server. If a colleague claims RTC works on their machine, they installed a different group than you did.

Agents write files and run commands, gated by an approval prompt

The permission system is the reason to care about this extension. Agents in Jupyter AI can read and write files, execute terminal commands, and work with notebooks through a built-in MCP server, and they request approval before writing or executing. On a server where a notebook kernel already has shell access under the same Unix account, that prompt is the only place where a human can stop a bad command. It is a consent step, not a sandbox. Nothing in the repository layout indicates container isolation, a restricted UID, or a filesystem allowlist, and the README does not document a rollback path if an agent edits a file before you read it.

The practical precaution is external to this project: start such sessions in a repository with a clean working tree so that whatever the agent changes, diff can show.

Context arrives by drag and drop, and custom MCP servers widen the blast radius

Bringing files or notebook cells into a conversation works by dragging them into the chat, which turns a selected cell into context without a copy and paste step. Multiple concurrent chats are supported, so you can keep one thread per task instead of one growing transcript. Real-time editing with other users on the same server follows the same path as any other JupyterLab RTC session once the right extra is installed.

Custom MCP servers are the extension point with the highest consequence. Registering one grants every connected agent access to domain-specific tools, resources and prompts. Persona registration through the entry points API sits on top of this, letting developers ship a named assistant rather than the default behaviour. Both are developer surfaces, not user settings.

Why Cursor or a plain notebook client is a different decision

Cursor is a separate editor, not an extension inside a shared JupyterLab server where other collaborators are typing. Jupyter AI inverts that: the notebook and its state are the workspace, and the agent arrives as a protocol client with an MCP server for the kernel side.

The genuine overlap is the ACP agent list. If your team has already standardised on one of those agents for local editing, Jupyter AI's value is not a better model but a shared, permission-gated surface inside a server you already run. Running the agent alone gives you the same reasoning without Jupyter AI's built-in notebook tools.

The README hands installation off to a documentation site

There is no install command anywhere in this repository's README, only a link to the getting started page at jupyter-ai.readthedocs.io, which is where installation, agent setup and the first chat are documented. Separate pages cover chat features and notebook tools, contribution, building custom agents and MCP servers, and troubleshooting. The project also states that it is under incubation as part of the JupyterLab organisation, which is a governance note rather than an API stability promise.

Because the steps live off the repository, pin the documentation version you follow rather than reading whatever stable resolves to on the day. The dependency ranges in pyproject.toml will tell you more about what a given release expects than the prose will.

Editorial conclusion

Adopt Jupyter AI if your team already runs a shared JupyterLab server and wants named agents such as Claude, Codex or Copilot inside the notebook, with an approval prompt standing between the agent and your files and shell. Skip it if you work in plain Jupyter Notebook on one machine, if you cannot accept a dependency chain that pins nine JupyterLab packages below their next minor, or if your chosen agent does not speak the Agent Client Protocol, since Jupyter AI integrates agents through ACP. Check first that the agent you want publishes an ACP endpoint and that your server's existing extension set resolves against the ranges in pyproject.toml, because that conflict is the failure mode the README does not describe.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes