Pi Durable Explained: Building a Persistent Runtime Framework for Always-On Agents

When building always-on AI agents, the trickiest problem is often not model capability but the reliability of the execution process. A crash in the middle of a tool call can wipe out an entire task. In a recent video, a Bilibili creator breaks down Pi Durable from the Pi ecosystem—an agent runtime framework designed specifically to handle crashes and unexpected interruptions—and demonstrates live how to build a recoverable, persistent agent using a local model.

What Is Pi Durable: Adding an "Undying" Runtime Layer to Agents

Pi Durable is an agent runtime framework whose core design goal is to reliably handle crashes and various unexpected interruptions. It lets agents run continuously in the background—for example, as a server or a local daemon—and even if the process stops mid-execution, it can accurately resume from where it left off.

This stands in sharp contrast to the standard Pi Coding Agent. The creator uses an email-sending example to illustrate the difference: suppose you ask the agent to send emails to five customers, the first four succeed, and the process crashes while sending the fifth. The standard Pi Coding Agent saves the entire session as a JSONL file; after restart, you see a truncated tool call with no result—because the model API requires a tool response to follow every tool call, so the only option is to append a fake error response. The user then has to investigate what happened and manually issue a "continue" command.

Pi Durable's approach: the task is first saved as a Task within the Harness, and the Task contains multiple checkpoints. Tool calls are also persistently written to the storage system. On recovery, the system uses checkpoints to determine which operations have completed and which still need to continue—no manual intervention required, and no repeated execution of already-completed external operations.

The Checkpoint mechanism is the core of durable execution. In Pi Durable, a checkpoint is a state snapshot periodically written to the storage system during task execution, recording which tool calls have started, which have completed, and how far execution has progressed. Similar to commit points in database transactions, checkpoints allow the system to roll back to the most recent consistent state after a crash rather than starting from scratch. The difference is that Pi Durable's checkpoints not only record internal state but also associate external side effects (such as emails already sent), thereby avoiding re-execution of completed external operations during recovery. Checkpoint granularity directly affects recovery precision and write overhead, and typically requires a trade-off between the two.

Its Position in the Pi Ecosystem: An Alternative Harness Implementation

The key to understanding Pi Durable is to see clearly where it sits in the Pi ecosystem architecture. The standard Pi Coding Agent runs on top of the Pi Harness, and the Pi Harness itself is the agent's runtime loop, responsible for managing sessions, organizing tools, and executing tools. Below the Harness is Pi AI, which connects to various large language models and handles model calls and prompt caching. The Pi Coding Agent is an application running on top of these two layers, including the terminal interface, system prompts, and extension layer.

Pi Durable replaces exactly the Pi Harness layer. It is likewise built on top of Pi AI, follows the same model integration approach, but provides another interchangeable Harness implementation. The core deliverable is a Harness class that developers import into their own programs. From an application developer's perspective, the way models are called remains unchanged—only the Harness responsible for long-term execution is replaced.

The creator specifically notes: Pi Durable is not a ready-to-use application like the Pi Coding Agent that you can just open from the command line. It does not provide a ready-made CLI interface; the actual user-facing interface still needs to be implemented by the application itself. It is more like infrastructure for developers building products, suited for background agent scenarios that need to receive input from multiple sources (such as Telegram, Slack, email).

Harness (runtime loop) plays the role of "execution engine" in the agent architecture: it receives queries submitted by users or systems, calls the large language model to generate responses, parses tool call requests returned by the model, executes the corresponding tools, then passes the results back to the model—looping until the task is complete. The Harness is not responsible for the model's own capabilities but manages session state, tool registration and scheduling, and orchestration of multi-turn interactions. Differences between Harness implementations mainly lie in persistence strategy, concurrency model, and error recovery approach. Pi Durable can replace the Pi Harness because it follows the same runtime loop abstraction but adds state persistence at every step of the loop, thereby gaining crash recovery capability.

Building an Application: From Storage Selection to Six-Step Initialization

Building an application on Pi Durable involves a three-layer structure: input channels (Slack, email, etc.), the application layer (receiving requests, selecting conversations, routing messages), and the underlying Harness. The application layer must be developed by the developer; conversation management is best handled at the application layer—although Pi Durable provides APIs for managing conversations, they are not a complete CRUD interface and will not handle all user and conversation management logic for the developer.

In Pi Durable, a Conversation roughly corresponds to a Session in the Pi Coding Agent. Each conversation has its own system prompt, working directory, tools, and skills, and can be isolated from one another. The creator highlights an easy pitfall: Pi Durable does not automatically read the PI folder or configuration files like agents.md from the working directory—all configuration must be explicitly loaded when initializing a conversation.

Storage is the foundation of persistence. Pi Durable currently supports three backends: SQLite, JSONL file storage, and in-memory storage. In-memory storage is only suitable for quick experiments—data is lost when the process closes. The creator says SQLite is their favorite option in experiments; after initialization, database tables are automatically created and managed by the framework.

Initializing the Harness in practice involves six steps: configure the model Provider, open the tool registry, set up storage, open the Harness, create or retrieve a conversation, and submit a query. After submission, a Submission ID is returned; developers can choose to wait for the final result (suitable for long-running background tasks) or subscribe to an event stream to read model-generated content and tool calls in real time (suitable for chat interfaces).

SQLite as an embedded database deserves a note on its advantages in this scenario. SQLite requires no separate server process, stores data as a single file, supports ACID transactions, and is well-suited for single-machine or edge-deployed agent applications. For Pi Durable, SQLite's transactional properties guarantee atomicity of checkpoint writes—even if a crash occurs during writing, no half-written state is left behind. Compared with JSONL file storage, SQLite supports more fine-grained queries and updates, making it easier to retrieve checkpoints by task or conversation; JSONL is better suited for append-only writes and simple debugging. In-memory storage offers no durability at all and is only for validating logic during development. When selecting a storage backend, consider concurrent write frequency, data volume, and deployment environment.

Live Demo: Running a Persistent Agent with a Small Local Model

In the video, the creator runs Ollama locally (the original mentions a llama.cpp server) to load a very small model, Qwen 3.5 0.8B, and demonstrates the full workflow. After the script connects to the local model, the agent calls the Read tool to read a README file and finds a secret phrase hidden inside. The model is tiny and responds extremely fast; the point of this demo is to confirm that the Harness can connect to the model and complete a real request through tools, not to test the model's upper capability limits.

The second example, Chatrism, goes further: at startup, the program first checks the persisted state and finds an unfinished task. The creator has the agent read the project documentation, interrupts the program right after the Read tool is called, then runs it again. The framework reads the saved checkpoint from SQLite, completes that Read tool call, and finally returns the project description. The whole process requires no manual intervention, intuitively demonstrating Pi Durable's recovery capability.

Local Model Autonomy and Trade-offs of the Early Stage

Pi Durable's most direct value is decoupling from any specific model. In the demo, the creator uses the llama.cpp Provider while keeping an OpenAI API Key for easy switching, showing that developers can combine the underlying model runtime and application interaction style according to actual needs, rather than being locked into a particular packaged product—no need to be tied to OpenAI's models, or to Grok's models or GrokBot.

Objectively speaking, Pi Durable is currently in an early development stage, and its interfaces are likely to change in the future. It is a set of low-level building blocks rather than an out-of-the-box product; UI interaction and deployment methods are left to application developers. For scenarios where agents need to run unattended for long periods and require cross-process crash recovery, this persistent Harness is worth watching; if you are just building a standard Coding Agent, the regular Pi Harness SDK may be sufficient.

One-line Summary

Pi Durable is a persistent runtime framework that replaces Pi Harness, letting agents recover from checkpoints after a crash.

Paragraph Summary

Pi Durable is an agent runtime framework designed to handle crashes and unexpected interruptions, positioned as an alternative implementation of the Pi Harness layer. By saving tasks as Tasks containing multiple checkpoints and persisting tool call records, it enables agents to resume from the breakpoint after a process interruption and avoid re-executing completed external operations. The article contrasts this with the standard Pi Coding Agent's flaw in an email-sending scenario where a crash requires manual intervention, and explains in detail Pi Durable's layer in the Pi ecosystem, its three-layer application structure, three storage backends (SQLite/JSONL/in-memory), and the six-step initialization process: configure model, registry, storage, open Harness, create conversation, submit query. The live demo uses a small local model, Qwen 3.5 0.8B, to run a persistent agent and demonstrate crash recovery. Pi Durable is currently at an early stage and is a developer-oriented building block rather than an out-of-the-box product, suited for unattended long-running background agent scenarios.