Published: 2026-10-15
Deep dive

Pi Durable: coding agents that survive failures, share state, run resumable tasks and attach from any client

Chapters / key moments (click to jump — plays here on the page)

IndyDevDan shows Pi Durable, a release for the Pi coding agent that keeps a long-running agent alive across failures and lets you reach it from several clients. His demos cover a proactive on-call agent that investigates an incident and waits for approval, then a "network playground" with agents on several machines. The page keeps the concrete features and how he used them. We could not find official Pi Durable documentation, so every detail below is his account of an experimental release.

Source video

"Pi Durable PROACTIVE Agents: Jev Triggers My ON-CALL Pi Agent" by IndyDevDan — Watch on YouTube → He ends with a pitch for his own upcoming product; it is not part of the walkthrough.

What a "durable" agent means here

A normal coding agent lives in one terminal session on one machine. A durable agent runs detached from any client: your terminal, a browser tab or a phone connects to it, and its work and state persist if a client disconnects or something fails. His point is that /resume isn't the same thing: the agent keeps working, on its own device, while you are away. He says the release is experimental, so he would not deploy it to production without forking it. Pi's maintainers are named in the video as Mario Zechner and Armin Ronacher, and a news summary we found places the launch at October 1 with Pi 1.0.

The features he demonstrates

  • Proactive agents. A mock production app streams events; his small classifier model (Jev) flags an incident and triggers a durable agent with the payload, the location and the error. The agent follows a standard operating procedure (detect, investigate, root cause, fix, present for review) and waits. He approves the deploy; the deploy tool call is one-time and can't be replayed. He describes the pattern as "human near the loop": agents work first and wait, and you review when you arrive. Classifying hundreds of events cost him cents.
  • Detached agents and several clients. Agents run on his Mac minis, laptop and cloud sandboxes. A terminal UI attaches by agent ID from another machine, and a browser client shows the same sessions. The hierarchy is device, workspace, agent.
  • Shared application state. One JSON object shared by every agent session on a device, read and written through state tools, so one agent's findings are visible to another. He says it is durable across sessions.
  • Tasks. Repeatable jobs with phases, so that a failed phase can be retried and a run can continue after a pause. A task can run code or code plus a sub-agent, and can stop for approval. His examples: a workspace snapshot that writes to state, a "change watch" that loops over a folder, and a release check that asks a question.
  • Compaction in the background. A marker position on the context bar: once the agent crosses it, the session is forked and compacted while it keeps working, with a reserve limit at which it stops.
  • Change the tool set mid-session. Every harness step is a task, so he switched an agent to read-only mode live; the agent noticed its earlier tool list was wrong and corrected it.
  • Extensions and fork. Two extensions he turns on per session: a prompt-engineering fix to make a verbose model less chatty, and a classifier that judges each bash command and blocked an rm -rf as irreversible until he switched it off. A fork command copies the agent, optionally with state.
  • Handoff. A command starts a fresh model context with a handoff summary.

How to use it as a pattern

  1. Give agents their own machine or sandbox so they can have the tools you have, isolated from your working computer.
  2. Put a cheap classifier in front of an event stream and let it start an agent only when something needs work.
  3. Write the incident procedure as phases, with an approval step before any irreversible action.
  4. Share findings through one state object rather than copying text between sessions.
  5. Use a command guard extension on shell tools before you give an agent high autonomy.

His classifier is covered in our Jev summary.

Gotchas & Caveats

  • Experimental, and no official docs found. We could not locate Pi Durable documentation. Check the Pi project's repository and docs for commands before relying on any behaviour here.
  • His claims about competitors (that Anthropic and OpenAI build products such as Dots and Claude in Slack on durable-agent primitives) are his inference, not something we could confirm.
  • The incident demo uses a mock product and mock events.
  • An agent that can deploy needs the same care as a person with deploy rights; the one-time deploy call and approval step are the safeguard.

Key Takeaways

  • Detach the agent from the client so work continues and any client can reconnect.
  • Shared state and resumable phased tasks are what make long jobs survivable.
  • Make irreversible actions one-time, approved calls, and gate shell commands.