Pi 2.0 (code mode, ferramentas duráveis e mais): suporte nativo via code mode, roteamento de modelos personalizado e Pi durable

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Pi 2.0 (Codemode, Durable Tools & More!): Native via Codemode, Custom Model Routing & Pi Durable · Canal: AICodeKing · 16:34 · Assistir no YouTube

Tópicos: Agentes de IA, Ferramentas de desenvolvimento com IA, Inferência e otimização de modelos

Resumo

O vídeo apresenta as novidades do lançamento Pi 1.0, incluindo suporte a MCP por meio de code mode, roteamento personalizado de modelos, carregamento adiado de ferramentas e melhorias de cache e interface. Code mode permite que o agent combine chamadas de ferramentas em JavaScript e controle quais dados retornam à conversa. Pi durable é apresentado como uma base experimental para aplicações com conversas de agent persistentes, retomáveis e compartilhadas entre clientes. O vídeo também aborda custos, limitações, instalação e aspectos que ainda exigem validação antes de uso em produção.

Pontos-chave

Code mode permite orquestrar ferramentas com JavaScript e limitar os dados intermediários enviados ao modelo principal.
O suporte a MCP inclui servidores locais e remotos, com ferramentas descobertas por code mode por padrão.
Modelos especializados, como Jev e modelos de geração de imagens, podem ser acessados por code mode.
Extensões podem registrar modelos virtuais que selecionam um modelo físico para cada solicitação.
Ferramentas adiadas podem ser descobertas e ativadas quando necessário, reduzindo declarações carregadas no contexto inicialmente.
O Pi pode aquecer o prompt cache e registrar mudanças de instruções e ferramentas no meio de uma conversa.
Pi durable oferece armazenamento persistente, retomada de conversas, múltiplos clientes e primitivas para aplicações com agents de longa duração.
Pi durable é experimental; replay seguro de ferramentas, limites de armazenamento e contexto precisam ser considerados.
O Pi e o Pi durable têm licença MIT, mas os modelos, serviços e infraestrutura utilizados ainda podem gerar custos.

Capítulos

Início	Capítulo	Resumo
00:02	Apresentação do Pi e suporte a MCP	O vídeo introduz o Pi, seu foco em personalização e a decisão de adicionar suporte nativo a MCP por meio de code mode.
03:37	Modelos especializados e roteamento personalizado	A demonstração aborda Jev, geração de imagens e extensões que escolhem dinamicamente o modelo físico para cada solicitação.
06:12	Ferramentas adiadas, cache e interface	São apresentadas melhorias de carregamento de ferramentas, aquecimento do prompt cache, registro de mudanças no system prompt e ajustes no terminal.
10:22	Ajustes finais do Pi 1.0 e introdução ao Pi durable	O vídeo resume outras mudanças do lançamento e apresenta o Pi durable como base experimental para aplicações com conversas persistentes.
11:23	Persistência, retomada e limitações do Pi durable	O trecho explica checkpoints, replay seguro, opções de armazenamento, subagents persistentes e os limites ainda presentes na ferramenta.
14:30	Instalação, custos e avaliação do fluxo	O encerramento cobre instalação, licenciamento e custos, além de sugerir avaliar a precisão, as tentativas e o custo total do workflow.

Citações

Com code mode, o agent escreve um pequeno programa JavaScript que pode chamar ferramentas, combinar os resultados e retornar a saída útil. — 02:05

Antes de cada solicitação, ele escolhe o modelo físico que deve atendê-la. — 05:10

Uma ferramenta interrompida durante a execução só é repetida automaticamente se declarar que o replay é seguro. — 12:25

Minha parte favorita deste lançamento é o controle sobre quanto trabalho chega ao modelo principal. — 15:33

Conceitos e entidades

Pi (ferramenta): Agent harness open source para trabalhar com projetos, arquivos, comandos e tarefas pelo terminal.
Code Mode (conceito): Ambiente de orquestração em JavaScript que permite ao agent chamar ferramentas, combinar resultados e devolver uma saída selecionada.
MCP (conceito): Protocolo cujas integrações podem ser conectadas ao Pi e descobertas por code mode ou expostas diretamente ao modelo.
Jev (modelo): Classificador especializado que recebe estado estruturado e retorna escolhas, respostas de sim ou não ou pontuações com probabilidades.
virtual models (conceito): Modelos selecionáveis registrados por extensões que encaminham cada solicitação a um modelo físico escolhido por uma política.
deferred tools (conceito): Ferramentas cujas declarações podem ser descobertas e ativadas quando necessário, em vez de serem carregadas todas no início.
Pi Durable (ferramenta): Pacote experimental para criar aplicações com conversas de agent persistentes, retomáveis e acessíveis por vários clientes.
SQLite (ferramenta): Uma das opções de armazenamento oferecidas pelo Pi durable, com ressalvas sobre a persistência dos commits mais recentes em caso de falha do host ou de energia.
Claude Opus (modelo): Modelo citado na demonstração como opção para planejamento em um fluxo com roteamento personalizado.
GPT-6 Luna (modelo): Modelo citado na demonstração como opção para implementação após o roteamento.
Anthropic (empresa): Empresa mencionada na discussão sobre prompt cache e fluxo de login por copycode.

Tradução completa (pt-BR)

00:02 [música] Oi, bem-vindos a mais um vídeo. Então, o Pi 1.0 foi lançado e há bastante coisa para comentar. Temos suporte nativo a MCP por meio de code mode, roteamento personalizado de modelos, melhorias na forma como ferramentas e prompts entram na conversa e uma interface de terminal renovada. A Arendelle também lançou o Pi durable, que leva algumas dessas ideias para aplicações que precisam continuar funcionando após reinicializações. O anúncio foi feito em 1º de outubro. Alguns desses recursos chegaram nas versões lançadas antes da 1.0.

00:33 Então, este é o panorama completo do lançamento, incluindo as mudanças menores da versão final. Vamos direto ao assunto. Se você ainda não conhece o Pi, ele é um agent harness open source. Isso significa que ele gerencia a conversa, disponibiliza ferramentas para o modelo, executa essas ferramentas e traz os resultados de volta para que o modelo possa continuar trabalhando. Você pode usá-lo pelo terminal para inspecionar um projeto, editar arquivos, executar comandos ou realizar tarefas que envolvam documentos e dados. Você conecta o modelo que quiser usar. Muito do apelo do Pi vem da possibilidade de personalização. Você pode adicionar skills e extensões,

01:03 mudar a interface e criar seus próprios workflows em torno do agent. E gosto dessa abordagem. Quando você passa muito tempo usando uma ferramenta de programação, acaba encontrando algo que gostaria que ela fizesse de outro jeito. Poder mudar esse comportamento por conta própria é útil. A versão 1.0 desenvolve essa ideia. O interessante é o quanto essas atualizações dão a você controle sobre o trabalho que acontece dentro de uma sessão. A primeira grande mudança é o MCP, porque antes o Pi fazia questão de não incluir suporte nativo a MCP. A equipe explicou por que mudou de ideia. Eles queriam uma maneira melhor de

01:33 combinar chamadas de ferramentas, e a infraestrutura para isso também acabou sendo útil para coisas como classificadores. A crítica deles ao MCP tinha a ver, em parte, com a forma como as integrações despejam descrições de ferramentas e grandes resultados de texto no context do modelo. Agora, eles preferem descobrir ferramentas quando necessário e obter dados estruturados com os quais um script possa trabalhar. Isso faz sentido para mim. Imagine procurar informações em um rastreador de issues movimentado. Provavelmente, você vai querer coletar as issues relevantes, filtrá-las e então ler os resultados úteis. Fazer o modelo principal ler todos os campos de cada

02:05 resposta intermediária é uma maneira cara de chegar lá. A solução do Pi é colocar um ambiente de orquestração em JavaScript em torno dessas chamadas. É aí que entra o code mode. Com o code mode, o agent escreve um pequeno programa em JavaScript que pode chamar ferramentas, combinar os resultados e retornar as informações úteis. Por exemplo, suponha que você queira gerar um relatório sobre a atividade recente de um projeto. Um script poderia buscar várias informações independentes em paralelo, agrupar os resultados e retornar um relatório compacto. O benefício prático é que os dados intermediários podem permanecer dentro do script. Você controla quanto deles volta

02:35 para a conversa. O code mode também tem funções explícitas de armazenamento para dados JSON que precisam persistir entre chamadas. Variáveis comuns de JavaScript não continuam disponíveis automaticamente entre execuções separadas. E há uma distinção importante: o JavaScript é executado em um ambiente isolado, mas as ferramentas chamadas por ele mantêm as próprias permissões. Uma ferramenta de shell ainda pode alterar arquivos, e uma integração externa ainda pode realizar uma ação. Além disso, se um script falhar no meio da execução, as chamadas de ferramentas que já foram concluídas não são desfeitas automaticamente. Portanto, o

03:05 workflow ainda precisa de um tratamento de erros adequado. Para configurar o MCP, o Pi oferece suporte a servidores locais por entrada e saída padrão e a servidores remotos por HTTP. A configuração pode ficar no nível do usuário ou dentro de um projeto. Servidores MCP configurados para serem expostos pelo code mode o ativam automaticamente. Essa é a configuração padrão: as ferramentas deles são descobertas pelo code mode, em vez de serem todas apresentadas diretamente ao modelo. Você pode escolher outro modo de exposição para as ferramentas que quiser que o modelo veja imediatamente. Também há suporte a OAuth para servidores que exigem acesso à conta. Então,

03:37 se o seu workflow já depende de integrações MCP, esta é uma mudança importante. Você pode trazer essas integrações para o Pi e decidir como o agent as descobre e combina. Eu começaria com uma integração que você já usa e daria a ela uma tarefa delimitada. Algo como coletar issues não resolvidas para uma versão. Isso dá um resultado útil para inspecionar antes de criar um workflow mais complexo em torno disso. O code mode também dá ao agent acesso a modelos especializados, incluindo Jev e modelos de geração de imagens. Jev é um classificador. Você fornece a ele um estado estruturado e perguntas, e ele retorna

04:08 opções, respostas de sim ou não ou pontuações com probabilidades. Por exemplo, um workflow poderia perguntar se uma issue descreve um bug ou uma solicitação de recurso. Essas probabilidades ainda são avaliações do modelo. Por isso, eu verificaria uma amostra antes de confiar na classificação. Modelos de imagem podem receber um prompt de texto e imagens de referência opcionais. O code mode pode chamá-los usando as credenciais configuradas para a sessão e anexar as imagens geradas ao resultado. Esses modelos especializados não aparecem no seletor normal de modelos de chat. O agent principal acessa esses modelos pelo code mode, e as extensões

04:39 também podem chamá-los. O uso de imagens e classificadores entra no registro de consumo da sessão quando é informado. No entanto, a falta de preços no catálogo pode fazer com que o uso apareça sem um custo em dólares. As imagens geradas também não são salvas automaticamente no disco. Então, se você quiser um arquivo de imagem para o seu projeto, inclua o salvamento desse arquivo no workflow. Agora, vamos falar sobre modelos virtuais. Acho que esta é uma das adições mais úteis para quem já alterna entre vários modelos. Uma extensão pode registrar um único modelo selecionável que funciona como roteador. Antes de cada

05:10 solicitação, ele escolhe o modelo físico que deve atendê-la. Você poderia criar uma política que use um modelo mais potente para o planejamento difícil e outro mais barato para a implementação rotineira. A lógica de roteamento também pode analisar a conversa e escolher um nível de raciocínio adequado. O Pi mantém visíveis o modelo que respondeu de fato e o uso dele, para que você possa inspecionar o que aconteceu por trás do roteador, mas a política é definida pela sua extensão. Você ainda precisa decidir como deve ser uma boa decisão de roteamento. Também há concessões. Trocar de modelo físico pode impedir o reaproveitamento do cache de prompt, e

05:42 um classificador usado para tomar decisões de roteamento aumenta a latência. Eu compararia um roteador com um modelo único como referência, usando tarefas reais. Uma solicitação mais barata só é útil se o trabalho inteiro ainda for concluído corretamente e custar menos. A demonstração do lançamento mostra o Pi escrevendo uma extensão que planeja com Claude Opus e implementa com GPT, enquanto Jev decide quando trocar. Depois de recarregar e selecionar o roteador personalizado, a demonstração passa do Opus para GPT 6 Luna para a implementação. Em seguida, mostra os custos de modelo da sessão

06:12 e o uso do cache. Essa é a demonstração deles, e ela nos dá um exemplo concreto de como essas peças se encaixam. Seria interessante testar com que consistência essa decisão de roteamento funciona em diferentes tarefas de programação. A próxima atualização é o carregamento adiado de ferramentas. Quando você adiciona mais integrações, também adiciona mais descrições de ferramentas e definições de argumentos. Carregar tudo de início usa espaço do context antes mesmo de o agent começar a sua tarefa. Agora, o Pi permite que autores de extensões diferenciem ferramentas declaradas diretamente, ferramentas acessadas pelo code mode e ferramentas adiadas

06:43 que a busca pode encontrar e ativar. Algumas ferramentas também podem ser restritas a chamadas diretas do modelo, o que é útil para operações que coordenam outras ferramentas ou precisam de interação do usuário. Pense em um projeto com várias integrações instaladas. Uma pequena edição de código local não deveria precisar de instruções detalhadas para todos os serviços que não têm relação com ela. O carregamento adiado permite manter esses recursos disponíveis e, ao mesmo tempo, carregar as declarações quando necessário. A qualidade da descrição da ferramenta continua sendo importante, porque o agent precisa encontrar a operação certa. Eu testaria a descoberta com solicitações comuns, não

07:14 apenas com prompts que já mencionam o nome exato da ferramenta. Então, esta é uma melhoria prática para o gerenciamento do context, especialmente à medida que a sua configuração cresce. Agora, o aquecimento do cache é outra atualização de que gosto, especialmente em workflows com Anthropic e muito context. Uma execução longa de ferramentas pode durar mais que o cache de prompt. O Pi pode enviar uma atualização para manter aquecido um cache compatível quando estima que isso vale a pena. A configuração padrão de streaming se aplica durante as execuções ativas. Você também pode ativar o aquecimento durante os períodos de inatividade entre execuções ou desativá-lo. O Pi exige que a duração do cache

07:45 informações para o modelo, e ele só faz o pré-carregamento quando estima que isso evitará pelo menos 5 centavos em custos de cache miss. Essa atualização ainda consome recursos. O PI inclui esse uso nos totais da sessão, mas mantém a atualização fora do contexto de conversa do modelo. Você pode inspecionar a próxima decisão de pré-carregamento usando /session. Então, eu consultaria os registros reais de uso da sessão antes de decidir se o pré-carregamento durante a inatividade faz sentido para minha carga de trabalho. Alguém que volta a cada poucos minutos tem um padrão de uso diferente de alguém que deixa a sessão aberta o fim de semana inteiro. Também há suporte para mensagens de sistema no meio de uma conversa. Essas são as instruções do harness e as definições das ferramentas.

08:17 Uma sessão começa com sua configuração inicial, e mensagens de sistema posteriores podem registrar alterações em seções específicas das instruções ou nas ferramentas disponíveis. Por exemplo, imagine que uma extensão altere o papel do agent ou adicione uma ferramenta depois que o trabalho já começou. O PI pode registrar essa alteração no ponto em que ela ocorreu. Quando você retoma ou navega por uma ramificação, ele pode reconstruir o prompt e o estado das ferramentas correspondentes a partir da transcrição. Gosto disso porque uma conversa longa pode conter decisões tomadas sob instruções diferentes. Manter o registro dessas alterações torna o histórico mais útil.

08:48 Isso também ajuda no cache de prompt em modelos compatíveis. O PI pode preservar um prefixo de cache anterior enquanto representa alterações posteriores na conversa. Esse suporte depende do modelo e do provedor. Eu trataria a preservação do cache como um recurso compatível que você deve verificar na sua configuração, em vez de presumir que todos os endpoints lidam com isso da mesma forma. Agora, o terminal ganha um novo tema padrão chamado system: o PI lê as cores de primeiro plano, de fundo e ANSI do terminal e, em seguida, constrói sua interface com base nessa paleta. Ele também ajusta o contraste

09:20 para que o texto continue legível. Se o terminal mudar entre os modos claro e escuro, o PI pode consultar as cores novamente e atualizar o tema. Há alternativas para terminais que informam apenas parte desses dados, e você ainda pode selecionar os temas claro ou escuro integrados ou usar o seu próprio. Você muda o tema usando /settings. É um recurso menor, mas gosto dele. Se já configurei um terminal que é confortável de ler por horas, quero que as ferramentas dentro dele se adaptem a essa configuração. Você deve gastar seu tempo verificando o trabalho do agent, não corrigindo uma combinação de cores que dificulte a leitura da saída.

09:51 A outra mudança visível é que o modo de tela cheia agora é o padrão. O editor de prompt e a área de status permanecem fixos enquanto a conversa rola dentro da janela do terminal. Isso mantém a área de entrada disponível enquanto você consulta saídas anteriores. Se preferir a rolagem normal do terminal, o modo regular continua disponível em /settings. Você também pode iniciar o PI com a flag –2e mode seguida de regular. Assim, você pode experimentar o novo padrão e voltar atrás se ele não se encaixar na sua forma de trabalhar. Para mim, esse é o tipo de escolha de interface em que as duas

10:22 opções fazem sentido. Quando estou tendo uma conversa longa com um agent, um editor fixo é útil. Quando quero tudo no histórico habitual do meu terminal, o modo regular é conveniente. Há mais algumas mudanças na versão final 1.0. A equipe informa que uma solicitação ao GPT 5.6 com as ferramentas padrão e o modo de código cai de cerca de 5.300 tokens de prompt para 3.300. Isso representa aproximadamente 40% nessa configuração específica. Portanto, não se deve interpretar isso como uma redução de 40% no custo total de todas as tarefas. Agora, os erros do modo de código fornecem dicas de recuperação mais

10:52 úteis, incluindo sugestões para nomes incorretos de ferramentas e orientações para argumentos malformados. O login do Radius está disponível por /lo, com uma opção para configurar o servidor MCP. O Anthropic também recebe um fluxo de login por código de cópia para configurações em que o navegador está em outra máquina. A autenticação MCP recebe verificações de emissor mais rigorosas, suporte para substituir metadados do servidor de autorização, credenciais separadas por nome e URL do servidor e um tratamento melhor para solicitações adicionais de permissões. Há também uma opção de inicialização mais discreta, que mantém visíveis a versão e as dicas de teclado, mas oculta a listagem mais longa de recursos.

11:23 Essas são melhorias úteis para quem usa o PI todos os dias. Enfim, agora vamos falar do PI durable, porque ele merece uma explicação própria. O Pi durable é uma base experimental para criar aplicações com conversas longas com agents. É um pacote separado, além do agent de programação. Um único harness pode executar várias conversas simultaneamente. Cada conversa pode ter seu próprio modelo, ferramentas, instruções e diretório de trabalho. Você pode criar uma ramificação de uma conversa em um ponto específico e continuar de forma independente a partir dali.

11:53 Vários clientes podem se conectar ao mesmo harness, acompanhar seu estado, direcionar o trabalho ou adicionar tarefas de acompanhamento. Ele também oferece suporte a dados de aplicação como documentos JSON tipados, que podem ser commitados junto com atualizações da transcrição. Isso abre possibilidades úteis para uma aplicação em que a conversa e o trabalho realizado precisam permanecer coordenados. Por exemplo, consigo imaginar um espaço de trabalho de suporte em que várias pessoas acompanhem uma investigação e façam perguntas relacionadas em threads separadas. O desenvolvedor ainda teria que criar essa experiência de produto, mas o PI durable

12:25 fornece a infraestrutura por baixo dela. A persistência vem do armazenamento de checkpoints do trabalho. Depois que um processo é encerrado, um novo processo pode reabrir o mesmo armazenamento persistente e retomar tarefas inacabadas. Uma ferramenta interrompida durante a execução só é repetida automaticamente se declarar que é seguro repeti-la. Caso contrário, o agent recebe informações sobre a interrupção e sobre a saída commitada até aquele momento. Essa distinção importa. Repetir uma busca e repetir uma ação que alterou um sistema externo podem ter consequências muito diferentes.

12:56 Reutilizar o mesmo ID de solicitação impede que uma submissão repetida seja admitida duas vezes. Isso não faz com que todas as ações externas aconteçam automaticamente exatamente uma vez. O PI durable oferece armazenamento em memória, SQLite e JSONL. O armazenamento em memória não sobrevive a uma reinicialização, então a escolha do armazenamento importa. Também há limites de deploy. Um processo por vez controla um backend de armazenamento, e a configuração padrão do SQLite não garante que os commits mais recentes sobrevivam a uma falha do host ou a uma queda de energia. E as APIs são experimentais.

13:27 Eu levaria em conta possíveis mudanças se estivesse criando um produto sobre essa base. Conversas longas ainda estão sujeitas aos limites de contexto dos modelos. O exemplo de compactação fornecido mostra sumarização e recuperação após o estouro do contexto. Portanto, persistência não significa memória ilimitada do modelo. Há também um exemplo de subagents persistentes em segundo plano, com conversas, status e mensagens próprios, enquanto o agent principal permanece disponível. Esses workflows são implementados usando as primitivas subjacentes de conversa e tarefa. Os desenvolvedores escolhem o comportamento de que

13:58 precisam. Outro exemplo mostra a atualização de uma extensão enquanto uma chamada de ferramenta existente termina usando sua implementação original. As chamadas posteriores usam a substituta. Acho que essa é uma direção útil para agents que precisam permanecer disponíveis enquanto a aplicação evolui. Mas esses são blocos de construção e implementações de exemplo. Portanto, eu esperaria que fosse necessário trabalho de engenharia antes de transformá-los em um serviço confiável. Então, se quiser experimentar o agent de programação PI normal, comece em pi.dev e use o instalador para seu sistema operacional. Também há uma opção de instalação via npm que requer

14:30 Node 22.19 ou mais recente, e o pacote atual está na organização Irandil Works. Depois de instalar, execute pi-version para verificar a versão. Abra a pasta do seu projeto. Execute pi e use /lo para conectar uma conta compatível ou uma chave de API. Depois, use /model para escolher o modelo desejado. Para uma primeira tarefa, eu pediria que ele explicasse a estrutura do projeto e como executar suas verificações. Você pode revisar essa resposta antes de pedir que faça alterações. O PI durable tem seu próprio pacote npm para

15:01 desenvolvedores que estejam criando aplicações. Você não precisa instalá-lo apenas para usar o agent de programação no terminal. Agora, sobre preços: tanto o PI quanto o PI durable usam a licença MIT. Ainda é preciso considerar os modelos e serviços aos quais você se conecta. Uma conta de API, uma assinatura compatível, hardware local ou a hospedagem da sua aplicação podem fazer parte do custo. O software open source dá a você controle sobre a ferramenta, mas ainda é preciso decidir como pagar pelo trabalho que ela realiza. Eu prestaria atenção especial ao custo total da sessão ao combinar um modelo principal, um classificador, geração de imagens e um roteador personalizado. É fácil se concentrar

15:33 em um componente barato e não perceber o custo do workflow completo. Minha parte favorita desta versão é o controle sobre quanto trabalho chega ao modelo principal. Você pode descobrir ferramentas conforme necessário, processar resultados intermediários em código e definir seu próprio roteamento de modelos. Isso dá várias coisas para medir e melhorar. A resposta continua precisa? O agent conclui com menos tentativas? O custo total diminui? Esses são os testes que eu usaria para decidir se vale a pena manter um workflow personalizado. O PI ainda deixa de fora coisas como um modo de planejamento dedicado e subagents

16:04 workflows para extensões ou pacotes. Se você gosta de configurar suas ferramentas, essa flexibilidade é uma parte importante do atrativo. Se quiser um workflow específico pronto imediatamente, confira se ele está disponível antes de mudar. No geral, acho que a versão 1.0 torna o PI muito mais interessante para quem quer moldar seu agent de programação. O MCP nativo elimina uma limitação prática, e o PI Durable oferece aos desenvolvedores de aplicações uma maneira separada de explorar trabalhos de maior duração. Enfim, me diga o que pensa nos comentários. Você tem mais interesse no modo de código, no roteamento personalizado de modelos ou em criar

16:34 algo com o PI Durable? No geral, é bem legal. Enfim, me diga o que pensa nos comentários. [música] Se você gostou deste vídeo, considere fazer uma doação pela opção Super Thanks ou se tornar membro clicando no botão Join. Além disso, dê um joinha neste vídeo [música] e inscreva-se no meu canal. Vejo você no próximo. Até lá, tchau. [música] >> [música]

Transcrição original

[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]