Pi Durable vs. OpenCode: An Architectural Comparison

For a while, it was seeming like all major coding harnesses had approximately the same architecture when you squinted. Then came Pi Durable.

Until now, coding harnesses had settled on a fairly recognizable set of patterns. A session that contains the conversation, a running agent loop that sends context to the model, tool calls that come and go from that loop, and the harness that keeps going until the work is done.

Claude Code, Codex, Pi, and OpenCode all have their own implementations of this approach.

Enter Pi Durable. It also has conversations, but model generations, tool calls, compaction, and application-defined work are designed to be durable tasks. A scheduler operates over those tasks, and storage contains both the history of the agent and work the harness has not finished yet.

If that seems like an implementation detail, it’s not. It enables fundamentally new harness capabilities.

This article compares Pi Durable to OpenCode, where OpenCode is in many ways representative of the typical session-based harness. It’s especially useful to study because it is open source and exposes enough of its internals to see how a sophisticated version actually works.

Here are some of the primary differences between the two architectural approaches to coding harnesses.

1. Pi Durable Serializes the Agent Loop Into Storage

OpenCode keeps the session as the long-lived part of the system. The running harness reads that session to construct a model request, continually adding results and tool call responses back to the session and deciding when to call the model again.

It’s important to emphasize that OpenCode persists a lot of state, and you might think that makes it equally durable compared to Pi Durable. But the difference comes down to storing session state versus execution state.

OpenCode stores session state. In addition to the conversation history, it persists prompts, tool activity, and other state around the session. But OpenCode’s current architecture only keeps the active execution in process-local memory rather than making it durable.

Pi Durable stores more of what would normally live inside that runner. Everything the harness runs is a task. A model generation is a task, each tool call is a task, and extensions can introduce new task types. Tasks store checkpoints as they progress and can remain unfinished in storage.

The task system separately records execution that is still underway, creating a durable ledger of the work being executed. Another process can open the same storage, find unfinished tasks, and continue executing them.

2. Making Work Schedulable

In OpenCode, the active agent loop is responsible for moving the work forward. After all, it’s a loop. It calls the model, handles the tool calls that come back, and keeps executing until the turn is finished. If multiple sessions are active, each has its own loop advanced by the runtime.

Pi Durable moves more of that responsibility into a scheduler. Because generations and tool calls are stored as tasks, the scheduler can look at the durable state and determine which work can run. Model responses can create tool tasks, those tasks can create more work or wait for other tasks, and completing one task can make another runnable.

This also means the work is no longer tied to the process that started it. A task can remain in storage after a laptop sleeps, a container is redeployed, or a machine runs out of memory. Another process can open the same storage, see which tasks are unfinished and runnable, and continue executing them.

Instead of the running agent loop being responsible for keeping work moving, the scheduler can determine what should run next from the stored task state. As you’ll see below, this opens up a range of possibilities.

3. Marrying Application State With the Conversation

OpenCode persists plenty of structured state around the conversation such as sessions, messages, tool activity, pending inputs, context, and events. All of that supports work across turns. But that state primarily exists to operate OpenCode itself. Application state generally lives somewhere else.

Pi Durable brings that application state into the harness. It introduces typed documents for state that does not belong in the transcript. A plan, ticket, todo list, sandbox configuration, or other application data can be stored alongside the conversation.

More importantly, documents participate in the same atomic commits as conversation entries and tasks. An agent can update application state, record the conversation that produced the change, and create new work as part of the same commit. Those pieces cannot get out of sync because the process died between separate writes.

Pi also defines what happens to documents when a conversation forks. A document can follow the value at the fork point, use the latest value, or start fresh in the new conversation.

The harness is no longer responsible only for persisting the conversation and its execution. It can also become the durable home for the application state that the agent is working on.

4. Moving Compaction Off the Critical Path

OpenCode and Pi Durable both separate the stored conversation from the context currently shown to the model. OpenCode keeps the full transcript even after older messages stop being sent back to the model. Its compaction architecture creates a checkpoint containing a rolling summary and recent context, which becomes the history boundary for subsequent model requests without deleting the older transcript.

In OpenCode, compaction is a specific part of the session lifecycle. Pi Durable instead makes compaction a task, using the same task system it uses for model generations and tool calls.

That means Pi can start compaction before the context limit is reached and run it in the background while the agent continues working. When the summary is ready, Pi can insert it at a later turn boundary. The agent does not necessarily have to reach the context limit, stop, wait for compaction, and then continue.

Compaction also gets the same durability as other Pi tasks. If the runtime disappears while a summary is being generated, the compaction remains unfinished work that the task system can recover rather than something the active agent loop has to start over from scratch.

Context maintenance can therefore move off the critical path of the agent loop. It becomes work the scheduler can start early, run in parallel, and recover independently while the underlying conversation remains intact.

5. Delegation As a Work Graph

OpenCode already supports delegation through subagents and child sessions. A parent agent can launch another agent, wait for it in the foreground, or let it continue in the background. But the coordination between that work is still primarily managed by the running harness.

Pi Durable brings those relationships into its durable task model. Tasks and conversations form an ownership tree. A task can own child tasks, a tool can create a separate conversation for a subagent, and a task can persist that it is waiting for other tasks before it can continue.

This enables new semantics around how delegation works across conversations. If a parent task is aborted, Pi can propagate that abort through the work it owns. Background work can cross that ownership boundary and continue after the foreground work that created it has finished. And, more importantly, tasks can continue running even if the conversation becomes idle.

Pi Durable’s approach gives the scheduler more information about delegated work. It knows which tasks own other tasks, which work is waiting, and which work is allowed to continue independently. That creates a stronger foundation for scheduling more complex combinations of agents and background work.

6. Tool Calls Become Durable Work

OpenCode executes tool calls as part of the active agent loop. When the model requests a tool, the runtime executes it, records the result in the session, and continues the loop. For many coding tools, this works well because the operation can simply be repeated or its result can be inspected later.

Pi Durable brings the tool invocation itself into the durable task model. Before the tool executes, the invocation is stored as a task. That means Pi can distinguish between a tool that was never requested, one that is currently running, and one that completed and returned a result.

This might seem like a minor recovery mechanism, but it becomes important as agents perform more side effects. If execution is interrupted and needs to restart, reading a file again is harmless. But a deployment, payment, or other external action may have succeeded even if the harness never received the result. Simply running the tool again could repeat the side effect.

Pi lets tools define whether they are safe to replay. Replayable tools can run again after an interruption. Otherwise, Pi can return the interrupted call to the model, including output that was already stored, and let the model decide what to do next.

Microscheduling Agent Systems

Pi Durable feels like a step toward more complex and composable agent systems where scheduling becomes a much bigger part of the harness. Once we decompose agent work into small durable tasks, the system has much more freedom to decide what should run, when it should run, and what it should wait for.

There is an operating-system analogy here. A process can exist independently of whether it is currently getting CPU time, while the scheduler decides which runnable processes get access to available resources. Pi Durable is not doing arbitrary preemption like an OS (yet), but it makes a similar model possible.

The session-based harness has taken coding agents very far. Pi Durable points toward a new chapter where the harness has to coordinate many more kinds of work across many more resources, and scheduling becomes a much bigger part of the architecture.