Pi Durable persists agent state beyond the transcript
Pi Durable persists in-flight tools, application state, and subagents so long-running agents can suspend and resume across environments. Demonstrations show checkpointed memory, approvals, and desktop control across devices.

TL;DR
- Pi Durable is an experimental framework for long-running agent applications, as pidotdev's announcement describes.
- Every model request, tool call, and compaction can become a checkpointed task that resumes after a process dies, according to badlogicgames's explanation.
- The durable state model includes in-flight tools, application state, and subagents alongside the transcript, a boundary badlogicgames on agent state describes directly.
- Storage and execution are separate: a harness can run on one machine while tools run on a phone, laptop, VM, or remote host, as badlogicgames's remote-environment build demonstrates.
- A personal-agent prototype built on Pi Durable added scheduled work, durable approvals, durable documents, and a controllable Linux desktop, according to omarsar0's Pi build.
Pi Durable's official design note includes code for SQLite storage, safe versus unsafe tool replay, and task-owned subagents. Cloudflare's Pi integration stores Pi's transcripts, inbox, and tasks in Durable Object SQLite, then wakes evicted sessions with a lifecycle job. In a Hacker News discussion, builders compared Pi's library approach with more batteries-included durable-agent systems.
Pi Durable
Pi Durable starts with a boundary between a single-user coding agent and a general-purpose agent harness. The official Pi Durable announcement defines a harness as storage plus the machinery to run multiple LLM conversations in parallel, including their tools and execution environments.
The coding agent remains a terminal program driven by one person. Pi Durable is the substrate for applications that need different surfaces, multiple people, longer runs, and recovery from failures. badlogicgames described it as “a library to build durable agents anywhere,” including coding agents and mobile applications badlogicgames on durable agents.
The distinction is operational, not just branding. A reply from badlogicgames says the Pi coding agent does not use Pi Durable, while Pi Durable is the library for building coding agents and cloud agents badlogicgames on the distinction.
Agent state
Agent state includes more than the transcript. badlogicgames names in-flight tools, application state, and subagents as state that a durable agent must preserve badlogicgames on agent state.
The durable harness specification turns that idea into a storage model:
- Entry tree: messages, compaction records, branch summaries, and application-defined entries.
- Mutable values and lists: current task state, lane state, queued work, and application data.
- Branches and lanes: named conversation paths with model configuration, queues, and at most one active operation.
- Usage ledger: append-only cost and usage history.
Recovery reads the complete current operation state after each durable transition. It resumes from that state instead of replaying a journal or inferring progress from missing records, according to the implementation specification.
Checkpointed tasks
Pi Durable makes the task the unit of recovery. The official design treats model generation, tool invocation, compaction, timers, and extension-defined work as tasks that checkpoint before moving forward.
- A model request cut off by a crash is sent again, while its partial answer remains in the transcript as aborted.
- A tool marked safe to replay runs again with its persisted arguments.
- An unsafe tool, such as a deployment, is not repeated after an uncertain crash. The model receives an interruption result and decides what follows.
- A queued message stays queued across restart.
- A
requestIdmakes a retried submission return the original submission instead of creating a duplicate.
The system therefore separates durable recovery from exactly-once external effects. The harness specification says side-effecting hooks must be idempotent and keyed by an operation identifier, while provider streams themselves are not resumed.
The target is a deeper recovery boundary than restarting a chat UI. Zechner described Pi Durable as a modular harness for agents that avoids “respawn Claude/Codex and hope for the best” badlogicgames on durable recovery.
Versioned tasks
Task code can change while work is pending. badlogicgames's task-migration reply says the Effect workflow model is close to Temporal's memo-and-replay approach, where code changes and migration make reestablishing the call graph harder badlogicgames on task migration.
Pi Durable instead gives tasks versions and lets each task define its migration. On resume, the scheduler checks pending tasks, migrates them, and continues. The same design can swap a task implementation in process without closing and reopening the run, according to the same explanation.
Storage and execution
The package ships memory, SQLite, and JSONL storage, plus a conformance suite and benchmarks for other backends. Its SQLite and JSONL implementations avoid Node APIs, so the official design says they can run with small adapters on Bun, Cloudflare Durable Objects, key-value stores, or Postgres.
SQLite keeps only the working set in memory: active transcripts, live tasks, and pending submissions. Older data stays on disk, and compaction keeps active transcripts bounded by the model context window even when a conversation contains tens of thousands of messages, according to the Pi Durable design.
Execution environments are separate from storage and the harness. A tool can use local files, a remote VM, or an in-memory sandbox, and the environment is constructed per conversation from its working directory. That lets one host run the harness while another host executes the tools.
The phone prototype made that split visible. A build log had the Android agent reach a Hetzner machine as if it were local badlogicgames's remote-environment build, then switch execution environments inside the same session while keeping the agent's “brain” on the phone badlogicgames's environment switch.
Cloudflare's Pi integration documentation supplies the hosted version of the same pattern. PiHarness stores Pi tables in a Durable Object's SQLite database, schedules a lifecycle job while a session is active, and reopens the storage when eviction or a crash interrupts the run.
Sessions and subagents
One harness can run many conversations concurrently. A conversation can fork another at any transcript point without copying the parent's history, and each conversation stores its own model, thinking level, tools, extensions, instructions, and working directory, according to the official architecture.
badlogicgames described a session as a full trace of anything agentic happening inside it, with subagents represented as conversations that can communicate with other conversations badlogicgames on session traces. The same model supports separate sessions per project or one shared session, depending on the application.
Pi Durable does not ship a dedicated subagent primitive. Its tools can create child conversations, assign ownership to the calling task, submit work with an idempotent request ID, and wait for the child. A child conversation then gets its own transcript, cost accounting, crash recovery, and UI identity, according to the official subagent example.
A separate mobile build replaced a conventional Android assistant with a Pi Durable application that included subagents badlogicgames's Android agent build. Another demo gave agents a tool to find and message active agents, including background subagents and agents running on the same Android phone badlogicgames on agent messaging.
Durable memory and approvals
The most complete user-facing example came from omarsar0, who built an OpenAI Dots-style personal agent on Pi Durable. The project was described as proactive, scheduled, and able to continue while its owner was away.
Its durable pieces included:
- Checkpointed steps that resume after the process is killed.
- Memory stored in durable documents and shared across Spaces.
- Approvals that survive a crash.
- A Linux desktop for each Space, controlled through screenshots, mouse, and keyboard.
- OpenRouter-backed model selection, so the model can be swapped without changing the rest of the application.
The demos also show the lower-level state model being used outside the official examples. raunakdoesdev described an agent running in a durable object that could modify and redeploy itself, with memory stored in SQLite raunakdoesdev's durable-object build and raunakdoesdev on SQLite memory.
Phone-first agents
The phone experiments follow a specific local-first definition. Zechner wrote that running an agent on a phone means putting the loop, user files, service connections, and execution environment there, rather than shipping a thin client to a cloud server badlogicgames's local-first post. He later described the LLM as the remaining external component, with the rest of the stack on the phone badlogicgames on local execution.
The demonstrations then accumulated quickly:
- A native Android app removed the Termux dependency, and badlogicgames said it was built in two days on the phone badlogicgames's Android demo and badlogicgames's native Android demo.
- A Pi Durable app ran directly on the phone, supported live editing and multiplayer, allowed provider and model selection, and added artifacts badlogicgames's live mobile demo.
- A follow-up described the same app as running without a cloud VM, with live editing, multiplayer, and artifacts badlogicgames's first mobile build and badlogicgames's expanded mobile demo.
- Internal multiplayer ran on an Android phone exposed through ngrok, while server and session workers could be killed and respawned under Pi Durable's control badlogicgames's multiplayer demo.
- The stated goal was to run everything on the phone, replace Claude for Android and ChatGPT for Android, and let other people join and steer a session badlogicgames's stated goal.
The phone was also the development environment. badlogicgames described replacing Claude for Android with a Pi Durable project that had subagents badlogicgames's phone-first build, then described self-modifying software by saying he was building “pim with pim” on the phone badlogicgames on self-modifying software. The same stream shows the app being extended despite platform restrictions badlogicgames on the build, while another reply keeps remote server execution available when an application wants it badlogicgames on server execution.
The scope stayed deliberately narrow. In one reply, Zechner said the system would change only as long as needed, until it had everything he needed and no more badlogicgames on scope.
Experimental boundary
Pi Durable shipped as an experimental npm package alongside Pi 1.0, not as a replacement for the coding agent. The Pi 1.0 announcement lists the package, its MIT license, and the install command for @earendil-works/pi-durable.
The official design estimates about 15,000 lines of source without tests, with storage backends accounting for roughly 3,000 lines. A separate phone design study reached 12,000 lines, including 6,000 lines of frontend code, but still needed Codemode and MCP support and was not published badlogicgames's design study. Its explainer had reached 190 pages, about ten times the size of the code.
Cloudflare's integration remains marked beta, and its documentation says the PiHarness API will likely change as Pi Durable matures Cloudflare's PiHarness documentation.