Pi Durable Explained: Build Always-On Agents with Local Models

0:00A Hugging Face explainer that untangles the release everyone found confusing: Pi Durable — what it is, how it differs from the Pi coding agent, where it sits in Pi's architecture, and how to build your own always-on agents on top of it, with any model (including local ones). The promise: not tied to OpenAI's Dots or xAI's GrokBot — build your own with open models.

What Pi Durable is

1:50The simplest definition: an agent harness designed to survive crashes and interruptions reliably. You run it as a daemon in the background, and if the process crashes or breaks mid-operation — even in the middle of a sensitive tool call — the system brings it back and continues exactly at the point where it left off.

The crash-recovery difference

2:48The contrast case: a regular Pi coding agent asked to send five emails. It sends four, then crashes on the fifth. 4:04In the coding agent's JSONL session, that looks like a truncated tool call — the transcript expects a tool response after a tool call (the LLM API requires it), but none exists because the call never finished. On restart, Pi sends a fake error tool response, and you have to send "continue" and figure out what happened. 6:05Pi Durable handles this automatically: "send emails" is stored as a task, and the task holds checkpoints of each operation — including a checkpoint that a tool call started but didn't finish. The daemon restarts, reads the state from storage, and continues from that checkpoint without you.

A building block, not an app

8:14If your whole mental model of Pi is the CLI coding agent, this is the key reframe: Pi Durable is not an application you run — you don't type pi-durable in a terminal. It's a building block: it ships a "harness class" with a clean API for creating conversations, submitting tasks, and querying them. It's meant to power this new generation of always-on agents — OpenAI Dots, Meta's Muse, GrokBot — that live on a server and keep working while you're elsewhere, especially when you're reached via Telegram, Slack, or email and can't babysit the process.

Where it fits in Pi

10:20Pi's stack: the Pi coding agent sits on the Pi harness (the agent loop — sessions, tools, orchestration), which sits on Pi AI (the model integration layer, with prompt caching and reliable calls). Pi Durable is a replacement for the Pi harness — another harness, also on top of Pi AI, but built for durability. It's a parallel to using the normal Pi harness via RPC or the Pi SDK: if you're building an interactive coding agent, use the normal harness/SDK; if you're building a background, long-running, unattended agent, use the durable harness.

Storage

18:00Three backends, chosen at init in code: SQLite (recommended for production — created and handled for you), JSONL (multiple files, and explicitly not the same as the Pi coding agent's session JSONL), and in-memory (experimentation only — erased on close). The durable guarantee comes from those checkpoints landing in persistent storage.

Your app's architecture

14:18Your always-on assistant looks like: a gateway handling Slack/email/etc. inputs → your application (most likely Node.js, since this is a TypeScript library) → which imports Pi Durable. 16:05Inside, you create conversations — each is like a session in the coding agent: its own system prompt, working directory, tools, and skills. Two caveats: Pi Durable's own conversation API is not a complete CRUD API and is likely to change (it's early), and it does not load .pi/ or AGENTS.md automatically — you pass everything explicitly in code.

The 6-step setup

19:31The setup sequence for a harness instance:

• 1. Configure models — e.g. a lama provider via the Pi AI models API (or an OpenAI key).
• 2. Open the registry — the set of tools + extensions; you can load the pre-built coding tools (read, write, edit, find) via the coding-agent-tools extension.
• 3. Set up storage — SQLite / JSONL / memory.
• 4. Open the harness — pass storage, models, registry, and the working directory.
• 5. Create (or retrieve) a conversation — model, cwd, and instructions (= system prompt).
• 6. Submit queries — conversation.submit(...) returns a submission ID; you can await the response (for hours/days-long jobs) or stream the events (for interactive chat).

The key mental model: submissions are persisted, so the harness can resume interrupted work from storage. "Use it with an agent — don't code this by hand," he notes.

The local-model demo

23:12The live demo runs a llama.cpp server with Qwen3.5-0.8B — a tiny local model — and a minimal agent script. He asks it to read the README and report a hidden "secret phrase"; the agent uses the read tool and returns it. 27:40A second example, ChatResume, demonstrates the durable part directly: he interrupts it mid-tool-call (Ctrl-C right after a read tool call), reruns it, and it reads the SQLite state and continues from exactly that tool call — finishing with the short answer. Both scripts are linked in the description.

Claims checked

Sources & further reading