Pi 1.0: More Capability, Same Restraint

Pi 1.0: more capability, same restraint

On October 1, 2026, Pi 1.0 shipped with a change that is easy to miss in a feature list: it became more capable without becoming a bigger, noisier product. Launch it in a terminal and the experience still feels spare. The terminal user interface (TUI), a full-screen application drawn inside your terminal, now starts in fullscreen by default, while the new features stay behind a familiar set of commands instead of a wall of settings. (github.com)

That restraint is the most interesting part of the release. Pi is not a new artificial intelligence model. It is an AI agent harness: the software around a model that stores the conversation, chooses which model to call, exposes tools, runs those tools, and keeps the session moving. The large language model supplies the reasoning and language; the harness decides how that intelligence meets your files, shell, services, and workflow.

A harness, not another giant assistant

A lot of agent software tries to solve every problem in advance. Pi takes the opposite route. It starts with a small foundation and lets you add the behavior you actually need through extensions, scripts, model providers, and project configuration.

That makes Pi feel less like a finished appliance and more like a well-shaped workbench. You can use it as a coding agent in one terminal session, then reshape the same underlying pieces into a research helper, a release assistant, or a small internal automation tool.

Codemode turns a toolbox into a program

The clearest example is codemode. A tool is a callable capability, such as reading a file, running a shell command, or contacting an external service. Without codemode, a model may call those tools one at a time and pass every intermediate result back through the conversation.

With codemode, Pi can write a short JavaScript program that coordinates several tools, filters their output, and returns only the useful result. An illustrative script might look like this:

const commits = await tools.bash({
 command: `git log --since='7 days ago' --format='%h %s'`
});

return commits.output;

The important idea is not the particular command. It is the boundary. The script can gather a large amount of information, process it, and show the model a compact answer. It can also call specialized non-language models, such as a classifier that makes a narrow decision or an image model that creates a picture. Pi's codemode documentation describes this as a constrained sandbox: scripts reach the outside world through tools and model APIs rather than through unrestricted filesystem or network access. (github.com)

This is why the feature feels bigger than a new button. Instead of forcing every workflow into a sequence of chat turns, Pi gives the model a small programming surface for composing work.

Deferred tools keep the prompt quiet

The same thinking appears in deferred tool loading. Modern agents often connect to many services, especially through Model Context Protocol (MCP), a common format for giving AI applications access to external tools and data sources. A large MCP server can expose dozens or hundreds of tool definitions, and placing all of them in the model's initial prompt consumes context before any useful work begins.

Pi can leave those tools out of the active tool list until they are needed. A search or loader can discover the right capability, activate it, and keep the rest out of the conversation. The result is a smaller prompt, fewer irrelevant choices, and a better chance that the model notices the tools that matter. (pi.dev)

This is a quiet improvement, but quiet improvements often determine whether an agent remains pleasant after a few weeks of real use.

Virtual models make routing part of the workflow

Pi 1.0 also makes model routing feel like a normal extension point. A virtual model is a selectable model name that chooses a real, physical model for each request. You might select router/auto, while the router sends planning work to one provider and implementation work to another.

That opens the door to a more deliberate division of labor. A strong model can study a problem and outline a plan. A faster or less expensive model can carry out repetitive edits. A classifier such as Jev can decide when the conversation has moved from planning into implementation, allowing the handoff to happen without making you manually switch models.

Pi keeps the selected virtual model separate from the physical model that actually answered. That distinction matters for debugging and cost control: the transcript can show what was chosen, while /session can report usage by the models that handled the requests.

Conversations can change without being erased

Agents become awkward when their tools or instructions change halfway through a task. Pi addresses that with transcript-aware system messages. A system message is an instruction supplied to the model outside the user's ordinary conversation. It can describe the agent's role, available tools, project rules, or a temporary change in behavior.

Pi records the starting prompt and tool set in the session transcript, then appends later changes as the session evolves. The transcript is the durable record of the conversation, so reloading an extension or activating a tool does not require pretending the earlier history never happened. This also gives providers a clearer representation of what changed and when.

That detail sounds technical because it is technical. It is also the sort of detail that makes resuming, branching, and experimenting feel reliable instead of mysterious.

The quiet improvements are the point

Several Pi 1.0 changes aim at the parts of an agent you notice only when they go wrong. Prompt-cache warming keeps a reusable prefix of the request available while a long tool run is in progress, or while the session is idle, when the expected savings justify the refresh. Pi exposes those decisions through session accounting rather than hiding them behind an unexplained performance claim.

The release also trims codemode's prompt overhead. In one example from the v1.0 release notes, a request using the default tools and codemode fell from roughly 5,300 prompt tokens to about 3,300. That is the kind of change that leaves the interface looking almost identical while giving the model more room for the task itself.

Pi Durable is a different shape

Pi Durable addresses a separate problem. The coding agent is designed for a person working with Pi in a terminal. If the process stops, you inspect the state and continue. Durable agents need more: conversations that last for days, tasks that survive failures, multiple ways to reach the same running agent, and possibly several people steering it.

Pi Durable is an experimental package for building those applications. A durable harness combines conversation storage with the machinery needed to run model calls, tools, and execution environments over time. It does not replace the Pi coding agent; it extends the same ideas of minimalism and malleability into a longer-lived setting. (earendil.com)

The extension point is the product

An extension is executable TypeScript that adds behavior to Pi. It can register a command, create a tool, connect an MCP server, change the terminal display, or define a virtual model. Because extensions run inside the Pi process with the operating system permissions available to Pi, they should be treated as trusted code rather than harmless configuration files.

That warning also explains the appeal. Pi does not need to predict every workflow because it gives you a direct place to build the missing piece. Pi 1.0 is less a feature pile than a carefully chosen set of seams: codemode for composing actions, deferred tools for controlling context, virtual models for routing decisions, and extensions for everything specific to your work.

The result still feels like Pi because the defaults remain small. The release adds room to bend without asking the core tool to become everything at once.