Want a Personal Agent Running All Day? Make It Resume After a Crash First

If you want a personal Agent to run around the clock, the first problem that shows up is often very mundane: when the process dies, the work in hand is cut off. The chat log is still there, but where the tool got to, what was queued, and what the application state was all have to be reconstructed by hand. The four Pi Durable projects that Xiaomo compiled on X break this pitfall into four steps.

Pi Durable is an experimental package Earendil released around the same time as Pi 1.0. It shares the same underlying layer as the Pi coding agent but has a different goal. Xiaomo compares it to a motherboard with power-loss protection: the Pi coding agent is a fully assembled computer, while Pi Durable is the base for building your own machine. It treats model calls, tool execution, and compaction as tasks, saving progress at every step; if the process disappears, a new process opens the same storage and continues from the last checkpoint. The README of pi-durable-hello puts it more directly: an ordinary agent loop keeps work in process memory, so when the process dies, the work dies too; /resume only restores chat text, not the running tool, the disk that has already changed, queued input, or the state the application believed at the time.

Image source: Xiaomo's tweet

1. pi-durable-hello: Get crash recovery working first

This repository uses 5 small examples to explain task persistence, crash recovery, request deduplication, and real-time monitoring. By default it uses the free fake model faux, so no API key is needed; it is suitable for first understanding how a Durable Agent works. Lesson 2 makes the process exit directly while a tool is halfway through; Lesson 3 opens the same SQLite file and calls resume to see how it picks up. There is a key boundary here: tools must declare a replay policy. Those marked safe can be rerun after a crash; those not marked, like bash, receive an “interrupted” result so the model can decide for itself. Durable means checkpointed, not exactly once; side effects such as payments and deployments still require you to implement idempotency yourself.

Link: https://github.com/avparkhi/pi-durable-hello

2. Batty: See how long-term memory avoids blowing up the context

Batty is a personal assistant and coding Agent whose core is “one permanent main thread.” Research, coding, background tasks, and scheduled work all branch off from this main conversation and bring results back when done. The most worth studying part is the long-term memory system: it uses OptChat to give the permanent conversation a navigable memory tree; the main conversation combines summaries of old history with the tail of the latest native session; background summarization moves old runs into the tree in batches while keeping the raw history. Automatic recall uses lexical search to find relevant historical fragments; memory_zoom expands summaries, and memory_search searches the original text. The mobile client is a PWA that supports passkey login, push notifications, offline reading of history, and incremental reconnection.

Link: https://github.com/jeffton/batty

3. Pots: Let the Agent decide for itself whether it should act

Pots is like an open-source AI colleague. It supports Slack, Discord, and Telegram, reads messages, decides what is worth handling, and then does the work on its own computer. It can be woken up in three ways: someone @-mentions it or DMs it; a judge determines whether a message is about it; and its own scheduled checks. There is a token-saving detail here: routine tasks can first be checked with ordinary scripts, and only when it is determined that handling is needed does it call pots wake to invoke the model. A commenter mentioned in a reply that for a personal assistant to run all day, the key is usually not to pile on memory and skills first, but to use a cheap script after waking up to decide whether to call the model. Without this gate, proactive execution is just burning tokens. Pots's inbox and outbox are made crash-safe, so it continues after a restart and checks whether a message has already been sent before sending; Telegram is the exception.

Link: https://github.com/Crokily/pi-durable-bot

Video source: Xiaomo's tweet

4. Hearth Pi: Connect the Agent to real devices

This project connects Pi Durable into Home Assistant, letting the Agent read device states and then, through human approval, control lights, switches, and other devices. It is still experimental; its value lies in learning how an Agent connects to real devices and how permission and approval mechanisms should be designed. Being able to read state and being able to flip a switch are two different things; the latter needs a human watching over it.

Link: https://github.com/cosmyo/ha-pi-durable

When the four projects are strung together, the learning order is also clear: first use pi-durable-hello to get checkpoint recovery working, then look at Batty for long-term memory, then at how Pots executes proactively, and finally at how Hearth Pi manages permissions. Xiaomo also mentions that if you want to save on servers, you can hand it to Cloudflare; the Agents SDK can already run Pi Durable, state is stored in the SQLite that comes with Durable Objects, and the model can use Workers AI. The current limitations are also spelled out: tool calls still have no approval, streaming model calls longer than 15 minutes may be interrupted, sessions cannot be deleted for now, and background tasks are checked only every 30 seconds.

Xiaomo wrote at the end of the tweet that everything is based on Pi. Set the meme aside; the path itself is concrete enough: first get checkpoint recovery working, then talk about memory and proactivity.