Pi 2.0 (Codemode, Durable Tools & More!): Native via Codemode, Custom Model Routing & Pi Durable

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Pi 2.0 (Codemode, Durable Tools & More!): Native via Codemode, Custom Model Routing & Pi Durable · Channel: AICodeKing · 16:34 · Watch on YouTube

Topics: AI agents, AI developer tools, Model inference and optimization

Summary

The video reviews Pi 1.0, highlighting native MCP support through code mode, custom model routing, deferred tool loading, cache warming, conversation-state tracking, and terminal interface updates. It explains how code mode can orchestrate tools and specialist models while limiting the data returned to the main conversation. The video also introduces Pi Durable, an experimental foundation for persistent, concurrent agent conversations, and describes its storage and replay limitations. It closes with installation guidance and emphasizes evaluating complete workflow accuracy, reliability, and cost.

Key points

Pi is an open-source agent harness that can be customized with skills, extensions, interface changes, and user-defined workflows.
Code mode lets the agent write JavaScript to call tools, combine results, and return selected output; tool permissions and side effects still apply.
Pi supports local and remote MCP servers, with tools discoverable through code mode by default when configured for that exposure.
Specialist classifiers and image models can be called through code mode, but their judgments should be checked and generated images are not automatically saved to disk.
Virtual models let extensions route requests to different physical models, with trade-offs including added latency and possible loss of prompt-cache reuse.
Deferred tool loading, cache warming, and support for system-message changes during a conversation offer additional ways to manage context and session behavior.
The terminal interface adds a system-derived theme and makes full-screen mode the default, while retaining alternative settings.
Pi Durable is an experimental package for persistent, concurrent conversations, branching, connected clients, and application data; storage and replay behavior have important limitations.
Both Pi and Pi Durable are MIT licensed, but users still need to account for connected models, services, hardware, or hosting costs.

Chapters

Start	Chapter	Summary
00:02	Pi 1.0 overview and code mode	The video introduces Pi and explains its native MCP support, code-mode orchestration, configuration options, and specialist model access.
04:39	Model routing and context management	The video covers virtual models that route requests and describes deferred tool loading and the trade-offs involved in routing.
07:14	Cache, conversation state, and terminal updates	The video explains cache warming and system-message history before describing the new terminal theme and full-screen default.
10:22	Final Pi 1.0 changes	The video summarizes reported prompt-token reductions, improved code-mode errors, authentication updates, and quieter startup options.
11:23	Pi Durable and its limitations	The video introduces Pi Durable’s persistent conversations, storage and replay behavior, examples, and experimental status.
14:30	Installation, costs, and overall assessment	The video gives setup guidance, discusses costs and workflow evaluation, and concludes with the main appeal of Pi 1.0.

Quotes

With code mode, the agent writes a small JavaScript program that can call tools, combine the results, and return the useful output. — 02:05

An extension can register one selectable model that acts as a router. — 05:10

Pi durable is an experimental foundation for building applications with long running agent conversations. — 11:23

A tool interrupted during execution is only automatically replayed if it declares that replay is safe. — 12:25

Does the answer stay accurate? Does the agent finish with fewer retries? Does the total cost go down? — 15:33

Concepts and entities

Pi, Code Mode, MCP, Jev, virtual models, deferred tools, Pi Durable, SQLite, Claude Opus, GPT-6 Luna, Anthropic

Full transcript (original language)

00:02 [music] Hi, welcome to another video. So, PI 1.0 is out and there is quite a bit to talk about here. We have native MCP support through code mode, custom model routing, improvements to how tools and prompts enter the conversation, and a refresh terminal interface. Arendelle also released PI durable, which takes some of these ideas into applications that need to keep working across restarts. The announcement came out on October 1st. Some of these capabilities arrived during the releases leading up to 1.0.

00:33 So, this is the full launch picture, including the smaller changes in the final release. So, let’s get right into it. If you’re new to PI, it is an open source agent harness. That means it handles the conversation, gives the model tools, runs those tools, and brings the results back so the model can continue working. You can use it from the terminal to inspect a project, edit files, run commands, or work through tasks involving documents and data. You connect the model you want to use. A lot of PI’s appeal comes from customization. You can add skills and extensions,

01:03 change the interface, and build your own workflows around the agent. And I like that approach. When you spend a lot of time with a coding tool, eventually you run into something you wish it handled differently. Being able to change that behavior yourself is useful. 1.0 builds on that idea. The interesting part is how much control these updates give you over the work happening inside a session. Now the first big change is MCP because PI previously made a point of not including native MCP support. The team has explained why they changed their minds. They wanted a better way to

01:33 combine tool calls and the infrastructure for that also turned out to be useful for things like classifiers. Their criticism of MCP was partly about how integrations dump tool descriptions and large text results into the model’s context. They now favor discovering tools when needed and getting structured data that a script can work with. That makes sense to me. Imagine looking through a busy issue tracker. You probably want to collect the relevant issues, filter them, and then read the useful results. Making the main model read every field from every

02:05 intermediate response is an expensive way to get there. Pi’s answer is to put a JavaScript orchestration environment around those calls. That is where code mode comes in. With code mode, the agent writes a small JavaScript program that can call tools, combine the results, and return the useful output. For example, suppose you want to report on a project’s recent activity. A script could fetch several independent pieces of information in parallel, group the results, and send back a compact report. The practical benefit is that the intermediate data can stay inside the script. You control how much of it comes

02:35 back into the conversation. Code mode also has explicit storage helpers for JSON data that should survive between calls. Ordinary JavaScript variables do not automatically stay alive between separate executions. And there is a distinction here. The JavaScript runs in a sandbox, but the tools it calls still have their own permissions. A shell tool can still change files and external integration can still perform an action. Also, if a script fails halfway through, tool calls that already completed are not automatically undone. So, the

03:05 workflow still needs sensible error handling. For MCP setup, PI supports local servers over standard input and output and remote servers over HTTP. Configuration can live at the user level or inside a project. MCP servers using code mode exposure enable it automatically. That is the default, so their tools are discovered through code mode instead of all being placed directly in front of the model. You can choose a different exposure mode for tools you want the model to see immediately. There is also OOTH support for servers that need account signin. So

03:37 if your workflow already depends on MCP integrations, this is a meaningful change. You can bring those integrations into PI and decide how the agent discovers and combines them. I would start with one integration you already use and give it a bounded task. Something like collecting unresolved issues for a release that gives you a useful result to inspect before you build a more complicated workflow around it. Code mode also gives the agent access to specialist models, including Jev and image generation models. Jev is a classifier. You give it structured state and questions and it returns

04:08 choices, yes or no answers or scores with probabilities. For example, a workflow could ask whether an issue describes a bug or a feature request. Those probabilities are still model judgments. So, I would check a sample before relying on the classification. Image models can take a text prompt and optional reference images. Code mode can call them using the session’s configured credentials and attach the generated images to its result. These specialist models do not appear in the normal chat model picker. The main agent reaches them through code mode and extensions

04:39 can call them too. Image and classifier usage contributes to session accounting when reported. However, missing catalog pricing can mean usage appears without a dollar cost. Generated images also are not automatically saved to disk. So, if you want an asset file for your project, includes saving that file in the workflow. Now, let’s talk about virtual models. I think this is one of the most useful additions for people who already switch between several models. An extension can register one selectable model that acts as a router. Before each

05:10 request, it chooses the physical model that should handle that request. You could create a policy that uses a stronger model for difficult planning and a cheaper model for routine implementation. The routing logic can inspect the conversation and choose an appropriate thinking level too. PI keeps the actual responding model and its usage visible so you can inspect what happened underneath your router, but the policy comes from your extension. You still need to decide what a good routing decision looks like. There are trade-offs as well. Changing physical models can lose prompt cache reuse, and

05:42 a classifier used to make routing decisions adds latency. I would compare a router against a single model baseline on real tasks. A cheaper request is only useful if the whole job still finishes correctly and costs less. The launch demo shows PI writing an extension that plans with Claude Opus and implements with GPT with Jev deciding when to switch. After reloading and selecting the custom router, the demo moves from Opus to GPT 6 Luna for implementation. It then shows the session’s model costs

06:12 and cache usage. That is their demonstration and it gives us a concrete example of how these pieces fit together. It would be interesting to test how consistently that routing decision works across different coding tasks. The next update is deferred tool loading. When you add more integrations, you also add more tool descriptions and argument definitions. Loading all of that upfront uses context before the agent has even started your task. PI now lets extension authors distinguish between tools that are declared directly, tools reached through code mode, and deferred tools

06:43 that search can find and activate. Some tools can also be restricted to direct model calls, which is useful for operations that coordinate other tools or need user interaction. Think about a project with several integrations installed. A small local code edit should not need detailed instructions for every unrelated service. Deferred loading gives you a way to keep those capabilities available while bringing in their declarations when needed. The quality of the tool description still matters because the agent needs to find the right operation. I would test discovery with ordinary requests, not

07:14 just prompts that already name the exact tool. So, this is a practical context management improvement, especially as your setup grows. Now, cache warming is another update I like, especially for anthropic workflows with a large amount of contact. A long tool run can outlast a prompt cache. Pi can issue a refresh to keep an eligible cache warm when it estimates that doing so is worthwhile. The default streaming setting applies during active runs. You can also enable idle warming between runs or turn warming off. PI requires cash lifetime

07:45 information for the model and it only warms when it estimates at least 5 cents in avoided cash miss cost. That refresh still uses resources. PI includes the usage in the session totals while keeping the refresh out of the model’s conversation context. You can inspect the next warming decision through / session. So I would look at the actual session accounting before deciding whether idle warming makes sense for my workload. Someone who comes back every few minutes has a different usage pattern from someone who leaves the session open all weekend. There is also support for system messages in the middle of a conversation. These are the harness’s instructions and tool

08:17 definitions. A session starts with its initial configuration and later system messages can record changes to individual instruction sections or available tools. For example, imagine an extension changes the agents role or adds a tool after work has started. PI can record that change at the point where it happened. When you resume or navigate a branch, it can reconstruct the corresponding prompt and tool state from the transcript. I like this because a long conversation can contain decisions made under different instructions. Keeping track of those

08:48 changes makes the history more useful. It also helps with prompt caching on supported models. PI can preserve an earlier cache prefix while representing later changes in the conversation. That support depends on the model and provider. I would treat cache preservation as a supported capability to check for your setup rather than assume every endpoint handles it identically. Now the terminal gets a new default theme called system pi reads the terminals foreground background and ani colors then builds its interface around that palette. It also adjusts contrast

09:20 so the text remains readable. If your terminal changes between light and dark pi can query the colors again and update the theme. There are fallbacks for terminals that report only part of that information and you can still select the built-in light or dark themes or use your own. You change the theme through / settings. This is a smaller feature, but I appreciate it. If I have already configured a terminal that is comfortable to read for hours, I want the tools inside it to fit that setup. You should spend your time checking the agents work, not fixing a color combination that makes the output

09:51 difficult to read. The other visible change is that full screen mode is now the default. The prompt editor and status area stay fixed while the conversation scrolls inside the terminal window. That keeps the input area available while you look through earlier output. If you prefer normal terminal scroll back, regular mode is still available through slash settings. You can also start pi with the–2e mode flag followed by regular. So you can try the new default and switch back if it does not fit how you work. For me, this is the kind of interface choice where both

10:22 options make sense. When I am having a long conversation with an agent, a fixed editor is useful. When I want everything in my usual terminal history, regular mode is convenient. There are a few more changes in the final 1.0 release. The team reports that a GPT 5.6 request with the default tools and code mode drops from about 5,300 prompt tokens to 3,300. That is roughly 40% in that specific setup. So, it should not be read as a 40% reduction in every task’s total cost. Code mode errors now provide more

10:52 useful recovery hints, including suggestions for incorrect tool names and guidance on malformed arguments. Radius signin is available through /lo with an option to configure its MCP server. Anthropic also gets a copycode login flow for setups where the browser runs on another machine. MCP authentication receives stronger issuer checks, support for overwriting authorization server metadata, separate credentials by server name and URL, and better handling of additional permission requests. There is also a quieter startup option that keeps

11:23 the version and keyboard hints visible while hiding the longer resource listing. Those are useful improvements for people who use PI everyday. Anyway, now let’s come to PI durable because this deserves its own explanation. Pi durable is an experimental foundation for building applications with long running agent conversations. It is a separate package alongside the coding agent. A single harness can run multiple conversations concurrently. Each conversation can have its own model, tools, instructions, and working directory. You can fork a conversation

11:53 at a particular point and continue independently from there. Multiple clients can connect to the same harness, follow its state, and steer work or add follow-ups. It also supports application data as typed JSON documents that can be committed together with transcript updates. That opens up useful possibilities for an application where the conversation and its work need to stay coordinated. For example, I could imagine a support workspace where several people follow an investigation and ask related questions in separate threads. The developer would still build that product experience, but PI durable

12:25 provides machinery underneath it. The durability comes from storing checkpoints for the work. After a process stops, a new process can reopen the same persistent storage and resume a unfinished tasks. A tool interrupted during execution is only automatically replayed if it declares that replay is safe. Otherwise, the agent receives information about the interruption and the output committed so far. That distinction matters. Retrying a search and retrying an action that changed an external system can have very different

12:56 consequences. Reusing the same request ID prevents a retrieded submission from being admitted twice. That does not make every external action automatically happen exactly once. PI durable offers memory, SQLite, and JSONL storage. Memory storage does not survive a restart, so the storage choice matters. There are also deployment limits. One process owns a storage backend at a time, and the default SQLite configuration does not guarantee that the newest commits survive a host or power failure. and the APIs are

13:27 experimental. I would account for changes if I were building a product on top of it. Longunning conversations still have model context limits. The supplied compaction example shows summarization and recovery from context overflow. So durability does not mean unlimited model memory. There is also an example of persistent background sub aents with their own conversations status and messaging while the main agent stays available. Those workflows are implemented using the underlying conversation and task primitives. Developers choose the behavior they

13:58 need. Another example shows updating an extension while an existing tool call finishes on its original implementation. Later calls use the replacement. I think that is a useful direction for agents that need to stay available while their application evolves. But these are building blocks and example implementations. So I would expect engineering work before turning them into a dependable service. So if you want to try the regular PI coding agent, start at pi.dev and use the installer for your operating system. There is also an npm installation option that requires

14:30 node 22.19 or newer and the current package is under the Irandil Works organization. After installing, run pi- version to check the version. Open your project folder. Run pi and use /lo to connect a supported account or API key. then use /model to choose the model you want. For a first task, I would ask it to explain the project structure and how to run its checks. You can review that answer before asking it to make changes. PI durable has its own npm package for

15:01 developers building applications. You do not need to install it just to use the terminal coding agent. Now, on pricing, both PI and PI durable are MIT licensed. You still need to account for the models and services you connect. An API bill, a supported subscription, local hardware, or hosting for your application can all be part of the cost. Open- source software gives you control over the tool, but you still have to decide how to pay for the work it performs. I would pay particular attention to the full session cost when combining a main model, a classifier, image generation, and a custom router. It is easy to focus

15:33 on one cheap component and miss the cost of the complete workflow. My favorite part of this release is the control over how much work reaches the main model. You can discover tools as needed, process intermediate results in code, and define your own model routing. That gives you several things to measure and improve. Does the answer stay accurate? Does the agent finish with fewer retries? Does the total cost go down? Those are the tests I would use to decide whether a custom workflow is worth keeping. PI still leaves things like a dedicated plan mode and sub agent

16:04 workflows to extensions or packages. If you enjoy configuring your tools, that flexibility is a big part of the appeal. If you want a particular workflow ready immediately, check that it is available before switching. Overall, I think 1.0 makes PI much more interesting for people who want to shape their coding agent. Native MCP removes a practical limitation and PI durable gives application developers a separate way to explore longer running work. Anyway, let me know your thoughts in the comments. Are you more interested in code mode, the custom model routing, or building

16:34 something with PI durable? Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. [music] If you like this video, consider donating through the super thanks option or becoming a member by clicking the join button. Also, give this video a [music] thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye. [music] >> [music]