Jupyter AI

Provides unified vendor-agnostic access to 1000+ language models across 100+ providers (OpenAI, Anthropic, Ollama, GPT4All, etc.) through a single LiteLLM abstraction layer. Jupyter AI v3 migrated from LangChain to LiteLLM, reducing startup time from 10s to 2.5s by eliminating heavy optional dependencies. The architecture uses a provider registry pattern where each model provider is registered with standardized request/response handling, enabling seamless model switching without code changes.

Provides a native JupyterLab chat UI built on the jupyterlab-chat framework with support for multiple concurrent chat sessions, real-time collaboration (RTC), and persistent storage as .chat files. Each chat maintains independent conversation history and can be saved/loaded independently. The architecture delegates UI rendering and state management to jupyterlab-chat while Jupyter AI handles AI persona selection, message routing, and LLM invocation. Chats are persisted as structured files enabling version control and sharing.

Saves chat conversations to .chat files (structured text format) that can be committed to version control, shared, and reopened in future sessions. The file format includes message history, metadata (timestamps, personas, model info), and RTC state. Files are stored in the notebook directory and can be manually edited or processed by external tools. The architecture uses a file-based persistence layer that serializes/deserializes chat state without requiring a database.

Provides a setuptools entry_points-based plugin system allowing third-party packages to extend Jupyter AI with custom personas, slash commands, and model providers without modifying core code. Extensions register handlers via entry_points in their setup.py/pyproject.toml, and Jupyter AI discovers and loads them at startup. The architecture uses a registry pattern where each extension type (persona, command, provider) has a well-defined interface that extensions must implement.

Provides native integration with local LLM runners (Ollama, GPT4All) through LiteLLM's provider support, enabling users to run models locally without cloud API calls. Models are specified by provider prefix (e.g., 'ollama/llama2', 'gpt4all/orca-mini') and Jupyter AI routes requests to the appropriate local endpoint. The architecture treats local models identically to cloud models through the LiteLLM abstraction, enabling seamless switching between local and cloud providers.

Provides line and cell magic commands (%ai for single-line, %%ai for multi-line blocks) that invoke LLMs directly from notebook code without opening the chat UI. These magics support variable interpolation (accessing notebook variables in prompts), output format control (returning raw text, structured data, or code), and reproducible execution. The magic system integrates with IPython's kernel extension architecture, making it available in any IPython environment (local notebooks, remote kernels, JupyterHub).

Implements a multi-assistant framework where different AI personas (e.g., @jupyternaut, custom personas) can be selected per chat or message via @-mention syntax. Each persona is a registered handler that can have custom system prompts, model preferences, and behavior. The architecture uses an entry points API (setuptools entry_points) allowing third-party extensions to register custom personas without modifying core code. Messages are routed to the selected persona's handler, which constructs the final prompt and invokes the LLM.

Provides slash-command syntax (@file:path/to/file, @selection) to attach notebook cells, file contents, or code selections as context to prompts. The system reads file contents or cell outputs at prompt time and injects them into the LLM context window. This enables AI to reason over actual code/data without manual copy-paste. The architecture uses a context resolver that normalizes different input types (files, cells, selections) into a unified context format before sending to the LLM.

Provides domain-specific slash commands that invoke pre-configured prompts and workflows for common tasks: /learn (explain concepts), /fix (debug code), /generate (create code), /export (format outputs). Each slash command is a registered handler that constructs a specialized system prompt and invokes the LLM with appropriate context. The architecture uses a command registry pattern similar to personas, allowing extensibility via entry_points. Commands can be chained or composed for multi-step workflows.

Provides context-aware code completion suggestions that appear inline in the notebook editor as users type, with streaming token-by-token display. The completion engine analyzes the current cell context (imports, variable definitions, function signatures) and sends a completion request to the LLM with surrounding code as context. Results stream back and are rendered as ghost text suggestions that users can accept or dismiss. The architecture uses JupyterLab's completion provider API for integration.

Provides a hierarchical configuration system that reads settings from multiple sources: environment variables, configuration files (jupyter_config.d), and JupyterLab UI settings. Configuration includes model provider selection, API keys, model parameters (temperature, max_tokens), and feature toggles. The system uses a config resolver that merges sources with precedence (UI > env vars > config files > defaults). Configuration is validated against a schema and cached for performance.

Integrates with the Jupyter kernel to access notebook execution context: variable values, cell outputs, execution history, and kernel state. AI requests can reference notebook variables (via magic command interpolation or context attachment) and receive responses that can be executed as code or stored as variables. The integration uses the IPython kernel's comm protocol to communicate between the JupyterLab frontend and kernel backend, enabling bidirectional context sharing.

Allows users to customize LLM behavior through model parameters (temperature, max_tokens, top_p, etc.) both globally and per-request. Parameters are passed through to the underlying LiteLLM provider, which normalizes them across different provider APIs (OpenAI, Anthropic, Ollama, etc.). The system validates parameters against provider-specific constraints and provides sensible defaults. Configuration can be set via UI settings, config files, or inline in magic commands.