At Earendil, we want to bring this technology to everyone, in whatever form fits their needs best. For that, we need a harness that runs anywhere, can be reached from different surfaces, supports infinitely long conversations, survives catastrophic internal and external failures, and lets multiple humans steer the same agents.

Pi Durable is that harness. It does not replace the Pi coding agent. It is a framework for building any agentic application, coding agents included. It shares not only code with the Pi coding agent, like pi-ai, but also its principles: minimalism and malleability.

What is a harness?

A harness is storage plus the machinery needed to run one or more conversations with large language models in parallel. It provides the tools those models call, and the execution environments the tools run in.

A conversation is an interaction between you and an agent, recorded as a transcript. The agent is the large language model together with its settings, like the thinking level, and the tools it can call. Tools do their work through an execution environment, which can be your laptop, a remote VM, or an in-memory sandbox. Everything the harness runs, from calling the model to executing a tool, is a task.

Like everything in Pi, Pi Durable is built so your agent can understand it. The entire source code, without tests, is about 15,000 lines.

Long runs anywhere

We want agents to run for a long time and to be able to run anywhere, where anywhere currently means anywhere there is a JavaScript runtime.

In Pi Durable, a harness opens over a storage backend. Pi Durable ships memory, SQLite, and JSONL storage, plus a conformance suite and benchmarks for your own backend. The SQLite and JSONL storage code uses no Node APIs, so with a small adapter it runs on Bun or inside a Cloudflare Durable Object. One process owns a storage at a time, and other clients attach to that process.

On SQLite, the harness only keeps the working set in memory: the active transcripts, live tasks, and pending submissions. Everything else stays on disk until it is needed. Active transcripts are naturally bounded by the model's context window, because compaction summarizes older messages before they overflow it.

Survives crashes

In Pi Durable, every step of a run is a task that stores a checkpoint before it moves on. If the process dies, a new process opens the same storage, finds the unfinished tasks, and continues each one from its last checkpoint. A model request that was cut off is sent again; the partial answer stays in the transcript, marked as aborted. A tool call that was cut off reruns if it is safe to; otherwise the model is told it was interrupted. A requestId makes a submission exactly-once.

Many conversations at once

One harness runs as many conversations as you need, concurrently, all with the same guarantees. A conversation starts fresh or forks another one at any point in its transcript, and sees the parent's history up to that point without copying it. Each conversation also stores its own agent: the model, the thinking level, the selected extensions and which of their tools are active, extra instructions, and the working directory in its execution environment.

Extensions

An extension is a named bundle of system prompt sections, tools, hooks, and tasks. The application installs extensions in a registry. Each conversation selects which extensions and tools it uses, and stores only their names.

• System prompt sections are rebuilt from the conversation's extensions before every request, so a changed section is picked up by the next request. Pi Durable records what changed in the transcript.
• Tools run as durable tasks; after a crash a tool reruns only if it says that is safe. Tools can create subagent conversations that survive crashes and count their own cost.
• Hooks let extensions step into tasks (model response, tool invoke, compaction), rewrite requests, block tool calls, or keep a run going. Decisions can be stored in a memo so a restart does not re-ask.
• Tasks get checkpoints, timers that survive restarts, and ownership trees so aborting a task aborts what it owns bottom-up. Background tasks can outlive the current turn.

Compaction

Compaction is a task like any other, and it runs while the conversation keeps going. When the context gets close to the model's limit, a background compaction summarizes the older messages, and the summary is placed at the next turn boundary. The older messages always stay in storage. reset() can start a new context from a handoff note while keeping history searchable.

Durable application state

Application state lives in documents: typed JSON stored next to the transcript and changed in the same atomic commits, so the state never disagrees with the transcript that produced it. Each document says what a fork starts with: the parent's value at the fork point, its current value, or a fresh one.

Malleable and multiplayer

The registry can change while conversations run. Installing an extension under a name that is already installed replaces it in one step. Conversations store extension and tool names, never code, so after a restart they pick up whatever the new process installs.

Everything a UI needs is committed state, so any number of clients can attach to any conversation, join late, reconnect, and steer a running conversation or queue a follow-up.

Try it

Pi Durable is experimental, and the API might still change. Point your agent at packages/durable in a Pi checkout, or install:

npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord

Full detail, code samples, and demos are in the original post.