# We Gave AI Agents a Live Jupyter Kernel in PyCharm > Source: > Published: 2026-08-12 12:00:34+00:00 # We Gave AI Agents a Live Jupyter Kernel in PyCharm If you’ve handed notebook work to an AI agent, you know how it tends to go: More often than not, it corrupts your .ipynb, loses your trained model the moment the run finishes, or burns budget sitting idle through a long job while you watch. To solve this, we’re introducing a brand-new Jupyter skill. Built directly into [PyCharm,](https://www.jetbrains.com/pycharm/) it lets your AI agent work inside a live Jupyter kernel instead of handing the job to a subprocess and losing your progress. This one change means state persists across cells, the `.ipynb` isn’t corrupted, and long jobs wait until execution is completed instead of constantly checking and wasting precious tokens. ## For Opus, the kernel ran cheaper than the shell We tested the efficiency of the Jupyter skill by comparing the performance of agents when solving twelve different machine learning problems. We compared three different modes: strictly using bash, strictly using the kernel via the Jupyter skill, and a mixture of both. While the agent was able to solve all twelve tasks in every mode, there was a difference in how much each mode spent. For Claude Opus 5, working through the kernel cost 59.09 USD versus 67.06 USD through the shell – about 12% cheaper. Here’s the counterintuitive part: The kernel used more tokens, yet cost less. That’s because it keeps the prompt cache warm. 98% of its input was cache reads, versus 82% for the shell – and cache reads incur only 1/12 of the cost of creating a fresh cache. ## Why we built this Notebooks are where coding agents tend to fall apart. Most AI tools treat an `.ipynb` like a plain text file: They hand-edit the JSON (and corrupt it), and then run code by running a subprocess. The moment an agent starts the subprocess, the kernel state – the trained model, the loaded dataframe, and every import – lives in the child process, and vanishes when that process exits. The agent can’t inspect it, checkpoint it, or reuse it. Output is buffered until the run ends, so progress is invisible, and long training jobs get babysat – blind until the connection times out. We asked the obvious question: What if the agent operated a live Jupyter kernel through the IDE? So we built our new Jupyter skill, which exposes PyCharm’s own notebook intelligence – its notebook model and live-kernel control – to the agent. It does this through a single MCP wrapper, `execute_tool` , which covers the core notebook operations, including creating, editing, and reading notebooks; running cells; waiting on long runs; probing a running kernel; and controlling its lifecycle. The skill tells the agent when and how to use them. ## How it works The agent: **Runs directly in the kernel.** The agent writes real Python into a cell and runs it, so variables, models, and data persist across cells – exactly like a human working in a notebook.**Waits instead of polling.** Rather than polling on a fixed timer and re-billing context on every idle call,`wait_cell_execution` is blocked until the cell finishes (or a safe cap), and then hands control back. This helps reduce idle round-trips.**Reads only what’s new.** As a long run streams output, the agent reads the*delta*– just the lines since its last check – instead of re-sending the whole, ever-growing cell output every time. This PyCharm functionality is available with a JetBrains AI subscription. ## Methodology We used twelve tasks from the MLGym machine-learning benchmark – classification, regression, and reinforcement-learning problems, each of which requires the agent to load data, train, evaluate, and save a result. We ran them across Claude Opus 5 and OpenAI’s GPT-5.6 models, Sol and Terra, through Codex. We compared three modes: through the kernel only, through the kernel plus the shell, and through the shell alone. As these benchmark tasks expose test labels to the agent, we treat cost – not accuracy – as the reliable signal. One caveat, for transparency: An audit found that one of the twelve tasks, Titanic, was contaminated – the agent could peek at the test set, and each agent used this to select the best model to present as the final solution. Titanic is a well-known, easy task for LLMs, and the issue appeared consistently across all three modes, so it doesn’t skew the comparison. The pattern holds even with Titanic removed – the kernel still ran 10% cheaper than the shell for Opus (56.34 USD versus 62.65 USD). ## Results The cost win is model- and task-dependent. It was clearest for Claude Opus on long, stateful jobs, while the shell came out cheaper on short tasks and for the Codex models – which already use the cache efficiently, so there the skill earns its place on workflow, not cost. ## Where it still falls short Two things are worth keeping in mind: **Tell the agent to save its artifacts.** In one run, the agent trained a solid model but never saved the submission file before finishing. This is easy to prevent from your side: Just add a clear instruction in your context file (e.g.`CLAUDE.md` ) or a skill so the agent saves any model the moment it clears your target metric.**Some tasks are still beyond agents.** On a hard task, the agent’s approach simply wasn’t strong enough to clear the bar. That’s genuine ML difficulty, not a tooling gap – some complex problems still need a human in the loop. The skill removes the *mechanical* waste, but doesn’t turn a weak approach into a strong one. ## Want to try it? Open the AI chat in [PyCharm 2026.2.1](https://www.jetbrains.com/pycharm/download/) and ask your agent to work in a notebook – create one, load a dataset, or kick off a training run. The agent will operate the kernel directly instead of running commands in the shell. You can also browse and manage skills directly from the IDE, expand the built-in library with external registries like public GitHub repositories, or let PyCharm import skills you’ve already set up for Claude Code or Codex. *Prev post*Unbundling and Deprecating Low-Usage Plugins in PyCharm[We Stopped AI Agents From Installing Into the Wrong Python: Task Success Rates Jumped to 95%+](https://blog.jetbrains.com/pycharm/2026/08/we-stopped-ai-agents-from-installing-into-the-wrong-python-task-success-rates-jumped-to-95/) *Next post*#### Subscribe to PyCharm Blog updates