article feature
Persistent IPython: the single model-facing tool
Prime Agent exposes one built-in model tool: a persistent IPython kernel that keeps variables, imports, and functions across ordinary calls and compaction. File edits, shell commands, skills, and subagent calls are invoked through Python code. The kernel runs with your OS permissions and is not a security sandbox.
Pinned repository file/line or test referenced in the audit.
How the kernel persists
Prime Agent keeps one IPython process attached to the session instead of starting a fresh interpreter for every tool call. Variables, imports, functions, and the current working directory can therefore be reused by later calls, which makes multi-step inspection and editing possible without repeatedly reconstructing local state.
Persistence applies to the live IPython namespace. A temporary shell launched from a %%bash cell has its own process state, while IPython operations such as %cd affect subsequent work in the kernel.
Host trust boundary
The kernel is a model-controlled execution surface inside the user's account. Python can reach files, invoke shell commands, load skills, and contact subagents with the same permissions available to the Prime Agent process.
Use an externally restricted or disposable environment for untrusted repositories. The kernel architecture improves continuity; it does not confine generated code or remove the need to review sensitive actions.
Surviving compaction
Context compaction shortens the message history sent back to the model, but it does not deliberately replace the running IPython process. Objects already held in the namespace can remain available after older conversation turns have been summarized.
That separation is useful when a long task exceeds the model's context window: the summary carries conversational intent while the kernel carries executable state. Neither layer is a complete substitute for durable files or a clear written handoff.
Kernel snapshots
Kernel snapshots support recovery after a worker restart by preserving recoverable session state alongside the transcript. They are recovery artifacts, not a promise that every live object, external process, or side effect can be reconstructed exactly.
A snapshot exists only after the relevant snapshot path has been used. Work performed after the latest snapshot may need to be rerun, so important results should also be written to ordinary project files or other durable artifacts.
What this does not mean
Persistent does not mean permanent, isolated, or infallible. A crash can still lose state newer than the latest snapshot, compaction can omit conversational detail, and shell subprocess state does not automatically become IPython state.
It also does not turn the kernel into a sandbox. The practical benefit is continuity across calls and compaction, bounded by the session lifecycle and the host's normal permissions.