At OpenTeams, my colleagues and I have contributed upstream to AI in Jupyter over the years: from the implementation of the inline completion API, which shipped in JupyterLab 4.1, through multiple versions of Jupyter AI, to in-browser JupyterLite AI. We have always cheered on other efforts to bring AI to Jupyter, whether they came from other maintainers or from new contributors, and whether they were under the official Project Jupyter umbrella or not. We love sharing the interesting extensions with the community and the discussions around the new ideas.

Over time the number of extensions grew until it became hard to keep track. The ease of extension development in the agentic LLM era and low maintenance cost due to stable APIs (which keep a solution developed years ago usable today) contributed to the increasing selection of extensions that users now have. We have now systematically catalogued AI extensions for Jupyter in openteams-ai/awesome-jupyter-ai, and I want to share a few lessons and observations.

Navigating the space of Jupyter AI extensions

New AI integrations keep popping up weekly. Many JupyterLab extensions are created to serve users at a university or a specific company, and are rarely announced to the outside world. A quick web search will only find the ones that were loudly marketed, not the ones that were quietly maintained for a narrow group of users. This means that it is hard to get a full picture of all the exciting work happening throughout the ecosystem. I would like the community to be able to map out which ideas have already been explored and which remain uncharted.

For that reason, we started the list from over 1,200 PyPI packages that carry a JupyterLab classifier, searched them for AI terms and model SDKs, added a few npm and GitHub searches, and screened the licence of each candidate (see method for details).

The extension API of JupyterLab has been stable since the 4.0 release, so the list includes extensions developed since. Extensions developed since 2023 usually still work today, as long as the associated AI service has not shut down. We moved the ones that are no longer worked on, or whose service has shut down, to a separate historical document. Although we find many of the listed extensions excellent, inclusion is not endorsement.

What is in the list

The main list has 103 entries in ten sections, and a separate historical file has 19 more:

How to choose one

Depending on what you need, this is where I would start:

What the list shows about the ecosystem

Chat panels are the most common interface, with 28 entries. These either use standalone LLM calls or agentic APIs. Coding agents connect from inside JupyterLab in two ways. Jupyter AI v3 connects Claude, Codex, GitHub Copilot, Gemini and four more agents over the open Agent Client Protocol, so changing the agent does not mean changing the extension. Six extensions connect the Claude Code and Codex command line tools to the notebook instead, through a side panel, an IPython magic or cell comments.

The Model Context Protocol (MCP) works in both directions. An agent outside JupyterLab can read, write and run cells through an MCP server such as Jupyter MCP Server. With jupyter-mcp-tools installed, Jupyter MCP Server can also run JupyterLab commands, such as opening a notebook. In the other direction, Jupyter AI v3 gives its agents access to the MCP servers you add. Some agents do not use the browser at all, e.g. nb-cli gives them a command line for notebooks, with a markdown format written for agents.

Agents have made the lack of hot reload a bigger problem. When an agent writes to the .ipynb file while the notebook is open, JupyterLab by default keeps showing the old cells. The extensions in the live reload section address this. One solution is to reuse the out-of-band reload of real time collaboration (jupyter-collaboration), which also enables agents to appear in the UI as collaborators, just like human colleagues. We proposed upstreaming a lightweight file-change detection to JupyterLab itself, so that it refreshes open documents when their files change.

There is strong interest in privacy. jupyterlab-browser-ai needs no API key: it uses the AI APIs built into Chrome and sends no data off the machine. Other extensions, such as Notebook Intelligence, can run a local model through Ollama.

Research and teaching are a growing use case. InstrMCP lets a model read physics lab instruments through QCodes, and Jupyter AI Tutor adds an Explain Code button for students. Research prototypes come from Microsoft Research (CoML), Georgia Tech (LLM Attributor) and a CHI’25 paper (Xavier).

Standalone inline completion extensions are less common now, partly because the feature ships inside broader extensions such as JupyterLite AI and Notebook Intelligence. The stable inline completion API makes the feature easy to maintain.

The timeline

The ecosystem is the work of a wide community. These are some of its milestones:

%%{init: {"theme": "base", "timeline": {"disableMulticolor": true}, "themeVariables": {"cScale0": "#e3ecf7", "cScaleLabel0": "#1f2937", "cScaleInv0": "#1f2937", "lineColor": "#6b7280"}}}%%
timeline TD
    2019 to 2022 : Tabnine completion for Jupyter Notebook
                 : jupyterlab-codex on the Codex beta
                 : genai magics
    2023 : Jupyter AI
         : Chapyter chat magic
         : JupyterLab 4.0, the latest major release
    2024 : Jupyter Chat
         : jupyter-copilot and Mito AI
         : JupyterLite AI and Magic Wand
    2025 : Jupyter MCP Server
         : Notebook Intelligence, Jupyter AI Agents
         : jupyter-ai-contrib organisation
    2026 : The first AI in Jupyter workshop
         : nb-cli, a notebook CLI for agents
         : Jupyter AI 3.0 connects agents over ACP

The first AI in Jupyter workshop brought contributors together in Paris and Seattle in March 2026 to work on a shared, extensible framework for AI in notebooks. The Jupyter AI Developer Summits, in San Francisco and London. Both were funded by the Jupyter Foundation, and I attended both for OpenTeams. I am looking forward to the next summit, and would love to connect with more of the wider community there.

Lessons about choosing wisely

Earlier attempts show which approaches did not stand the test of time. I believe that relying on open-source tools, models and code gives a better outcome in the long term than chasing the latest pitch from a closed-source vendor, or from a fork that fenced itself off. Looking back, several cases support this:

1. In 2024, Pretzel hard-forked JupyterLab 4.2 to add AI features, and licensed its changes under AGPLv3, so BSD-licensed JupyterLab could not upstream them. Development stopped the same year. Since then, JupyterLab has published ten security advisories that affect 4.2, four of them rated high, and Pretzel users got none of the fixes. It was a lose-lose scenario.
2. Kite’s JupyterLab extension, one of the first AI extensions for JupyterLab, started in 2020 as a copy of my jupyterlab-lsp. The copy was last updated in 2021, and Kite shut down in 2022, while jupyterlab-lsp is still maintained.
3. When a vendor changes course, work on its extension stops. Tabnine’s JupyterLab client stopped two months after its first release and is now archived. Codeium’s own client has not changed since 2024, and Codeium is now Windsurf. Einblick was acquired, and its prompt extension is still on PyPI while the source repository returns 404.
4. Open code and open models outlive the service. IBM discontinued the Qiskit Code Assistant service in 2026 and archived its JupyterLab extension, but the models are on Hugging Face under Apache-2.0, and the extension still supports Ollama and any OpenAI-compatible endpoint. Noteable shut down in 2023, and genai, a BSD-licensed set of IPython magics developed at Noteable, is still maintained.

Before you install

A few things to check before you install an extension:

1. Cross-check the licence in the PyPI classifier against the LICENSE file inside the wheel. Sometimes the two disagree, probably because the extension template fills in both places. RunCell’s classifier says BSD, for example, but its LICENSE file is a copyright line with no licence grant. Even when the licence is clear, it may restrict you: Notebook Intelligence and ai-jup are GPL-3.0, and Mito AI has a mixed licence, so check your distribution rules before you bundle them.
2. Some packages have no public source: all you get is the bundled code in the wheel, which is hard to read. Do not trust the package name alone either: some extensions reuse the name of another project on GitHub, and some publish under similar names on PyPI. Check whether the package uses trusted publishing, which PyPI shows as a verified repository link. It does not make the package safe, but it ties the package to its source repository.
3. How agents authenticate, and how extensions handle API keys, is not settled yet. Before you deploy an extension, check what it exposes over the network and how it handles keys. For example, jupyter-copilot disables authentication on its server extension. Reach out to us at OpenTeams if you need advice from a Jupyter expert.

Please add what is missing and leave a star

You are welcome to open a pull request that adds an extension, your own or someone else’s, or that updates any entry. Listing your own project is fine; just say so in the pull request. A project that has been public for less than a month, or has no readme that explains how to install it, will be asked to wait. See CONTRIBUTING.md for more.

A big shout-out to Jeremy Tuloup, who was the first to add a new package: xtralab, in pull request #1.

If you like the list, star the repository. It lets us know, and it makes the list easier to find in the future.