By 01:30 UTC on October 2, Pi 1.0 had reached 736 points on Hacker News. The more useful detail sat outside the version number: Earendil kept crash recovery, shared conversations and long-running agent work in a separate experimental package instead of swelling its terminal coding agent.
Earendil released Pi 1.0 and Pi Durable together on October 1. The company calls 1.0 a stable release shaped by feedback from hundreds of thousands of weekly users, a usage figure that comes from Earendil. Pi Durable, meanwhile, is explicitly experimental and may still change its API. That separation defines the release. One package is meant to be dependable at a keyboard. The other is where the maintainers can work out what happens when an agent lives on a server, outlasts a process and accepts instructions from several people.
The Hacker News discussion is a measure of developer attention, not proof that the software works as advertised. Still, the comments expose the problem the split addresses. Some developers described using Pi as a small local harness. Others wanted sessions that survive pod restarts, run from a home server or remain reachable from a phone. Those jobs share an agent loop, but their failure modes are different.
One release, two operating models
The existing Pi coding agent assumes a fairly ordinary relationship: one person drives one process in a terminal. If the process stops, that person inspects the result and asks it to continue. The Pi Durable announcement states that this model remains the focus of Pi 1.0.
A persistent service needs more machinery. It must know which work finished before a crash, which tool calls can be repeated, where pending messages belong and what a newly connected client should see. Adding all of that to the CLI would change the shape of the product even for people who only want an agent beside their shell prompt. Pi Durable is a TypeScript framework that shares Pi's model layer while introducing storage, tasks and concurrent conversations.
The installation paths make the divide concrete. Pi 1.0 is a program you can install and run. Developers add the durable runtime to an application as three npm packages:
npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord
Both releases use the MIT license. The public repository places the coding agent, the model-provider layer and the durable runtime in the same project. The packages have separate APIs and responsibilities, even though their code lives together.
What Pi 1.0 puts in the terminal
The stable release adds Codemode with native MCP support, virtual models, deferred tool loading and cache warming for Anthropic models. Mid-conversation system messages allow prompts and tool availability to change without pretending a fresh session began. Full-screen mode is now the default, accompanied by a new terminal theme.
Several of those changes keep model context under control. Deferred tools do not need every declaration loaded at the beginning of a turn. Cache warming tries to preserve expensive prompt state. Virtual models can route a job across models under one selectable identity. Earendil's launch demonstration has a virtual model plan with Claude Opus, switch to GPT for implementation and use Jev to decide when the handoff should occur. They extend the interactive agent. Persistent work remains in Durable.
Keeping Durable experimental also prevents the 1.0 label from overstating its maturity. A developer can evaluate the stable CLI without accepting an early task engine. Earendil can revise the durable API without quietly changing how every local Pi session stores and resumes work. The shared codebase leaves room for proven pieces to move across later.
Durability starts with an interrupted tool call
Pi Durable models every model request, tool invocation and compaction run as a task. It writes a checkpoint before advancing a task. When a process opens the same storage after a crash, the harness finds unfinished work and resumes it from the last checkpoint, according to Earendil's technical walkthrough.
The difficult case is a tool that was running when the process died. Repeating a search is usually harmless. Repeating a deployment or payment may create a second external effect. Pi Durable makes a tool declare whether replay is safe. A safe call can run again. Otherwise the harness records the interruption for the model and leaves the decision there. Submissions can carry a requestId, allowing a client that retries after losing its connection to receive the original submission instead of creating another one.
That contract does not grant exactly-once behavior to every outside system. The application author still has to classify tools correctly and give sensitive operations their own idempotency controls. Earendil's payment example supplies a stable identifier to the bank for that reason. Durable storage can remember intent and outcome. It cannot make an arbitrary third-party API transactional.
The bundled storage choices are memory, SQLite and JSONL. Developers can implement another backend against a small interface and run its conformance tests and benchmarks. One process owns a storage instance at a time, while clients attach to that process. This is enough for a single harness with many conversations, though it differs from a horizontally shared database design where several workers race to claim jobs. Anyone planning a clustered deployment should treat that ownership rule as an architectural constraint.
A conversation becomes shared state
Pi Durable lets conversations fork at any point in their transcript and continue concurrently. A Slack channel could be one conversation, with a reply thread branching from the message that opened it. Each branch keeps its own model, instructions, tools and working directory. A review branch can therefore use a cheaper model and read-only tools without changing the main agent.
Tasks and conversations form an ownership tree. Cancelling a parent aborts what it owns from the bottom up, giving child tasks a chance to clean up first. Background tasks follow a different rule: they can outlive the turn that created them, which fits reminders or subagents that should keep working after the main conversation becomes idle. This bookkeeping matters when a user presses Escape and needs to know whether a deployment, child agent or timer is still alive.
Several clients can watch the same conversation. A late connection receives the current transcript, streamed answer, active tools, queued messages and usage before subscribing to changes. It can then steer the running agent or queue a follow-up. Earendil also stores application documents, such as a plan or ticket, beside the transcript in the same atomic commits. That keeps a user interface from displaying state that disagrees with the conversation that produced it.
Long histories are compacted in the background as a model approaches its context limit. Older messages remain in storage even after a summary replaces them in later model requests. Developers can reset a conversation from a handoff note and give the agent a search tool for the earlier record. This preserves stored state, though a summary can still omit a detail unless the application retrieves or preserves it.
The security boundary remains outside Pi
Pi's security guide makes persistence a more serious permission question. A terminal agent normally stops when its process exits. A durable agent may keep credentials, network access and executable tools available for much longer, including while no operator is watching. Crash recovery also creates another decision point for every side-effecting tool.
The coding agent has the permissions of the operating-system account that launched it, according to Pi's documentation. Extensions and child processes inherit those permissions unless an operating-system or virtualization boundary limits them. Project trust decides which local resources Pi loads, but it does not sandbox tool calls. The documentation recommends containers, virtual machines or sandboxes when stronger isolation is required.
Pi Durable's hooks can implement approval steps, and its example stores a deployment approval so a restart does not ask again. Application code supplies that behavior. Teams testing the framework should decide which tools can replay, which tasks may run in the background and which credentials the execution environment can reach before they leave an agent unattended.
The next test for Pi is whether the package boundary holds under real use. Watch for changes to Pi Durable's experimental API, results from its storage conformance suite and reports of interrupted tools against actual services. Also watch whether features proven in Durable move into the terminal agent without bringing the whole server runtime with them. The 736-point launch will soon drop off the front page. A clean line between an interactive agent and a persistent one will matter each time a process dies at the worst possible moment.