Pi Durable ist eine experimentelle TypeScript-Bibliothek von Earendil für KI-Agenten, die Abstürze überstehen. Sie erschien am 1. Oktober 2026 zusammen mit Pi 1.0. Jede Modellanfrage und jeder Werkzeugaufruf wird zu einer kleinen Aufgabe, die einen Checkpoint speichert, bevor der Agent weitermacht. Stirbt der Prozess, öffnet ein neuer Prozess denselben Speicher und setzt beim letzten Checkpoint an. Dieser Beitrag erklärt, wie Pi Durable funktioniert, welche Speicher-Backends es gibt, wie die Replay-Regeln für Werkzeuge aussehen, welche Plattformen es schon einbinden und wo die Grenzen liegen.
Kurz gesagt
Was Pi ist und wo Pi Durable hineinpasst
Pi begann als kleiner Open-Source-Coding-Agent für das Terminal von Mario Zechner. Heute pflegt Earendil das Projekt, das KI-Unternehmen des österreichischen Entwicklers Armin Ronacher, bekannt als Autor des Python-Frameworks Flask. Der Code liegt unter MIT-Lizenz im Repository earendil-works/pi. Zum Release von Pi 1.0 hat auch heise berichtet.
Der Coding-Agent läuft auf einem Rechner und wird von einer Person gesteuert. Pi Durable zielt auf etwas anderes. Laut Earendils Ankündigung ist es ein Framework für beliebige Agenten-Anwendungen, Coding-Agenten eingeschlossen: Agenten, die überall laufen, von mehreren Oberflächen erreichbar sind, sehr lange Gespräche führen und Fehler überstehen. Mehrere Personen können dasselbe Gespräch verfolgen und steuern.
So funktioniert Pi Durable
Jeder Schritt ist eine Aufgabe mit Checkpoint
Earendil formuliert es so: Jeder Schritt eines Laufs ist eine Aufgabe, die einen Checkpoint speichert, bevor es weitergeht. Ein Modellaufruf ist eine Aufgabe, ein Werkzeugaufruf auch. Selbst die Kompaktierung, also das Zusammenfassen langer Gespräche, läuft als Aufgabe im Hintergrund. Jede Änderung ist ein atomarer Commit: alles oder nichts.
Laut README des Pakets wird nichts angezeigt, bevor sein Commit gespeichert ist. Nach einem Neustart rufen Sie resume() auf, und der Scheduler setzt offene Arbeit fort.
Unterbrochene Modellanfragen werden wiederholt
Stirbt der Prozess, während das Modell eine Antwort streamt, behält Pi die Teilantwort als abgebrochen und zählt den Vorfall als fehlgeschlagenen Versuch. Nach einer Wartezeit folgt ein neuer Versuch. Sind keine Versuche mehr übrig, endet der Lauf ohne Antwort mit dem Grund "interrupted".
Keine doppelten Eingaben
Jede Eingabe kann eine requestId tragen. Schickt ein Client dieselbe Anfrage zweimal, etwa nach einem Netzwerkfehler, gibt Pi die bestehende Eingabe zurück, statt eine zweite zu starten.
Absturzschleifen werden gestoppt
Eine Aufgabe, die den Prozess jedes Mal zum Absturz bringt, würde sonst endlos neu starten. Pi zählt die Neustarts und beendet die Aufgabe nach einem Limit, standardmäßig fünf.
Replay-Angaben für Werkzeuge
Das ist die wichtigste Idee in Pi Durable. Bevor ein Werkzeug läuft, speichert Pi die Absicht. Bricht der Prozess mitten im Aufruf ab, muss Pi entscheiden, ob es ihn wiederholt. Pi rät nicht. Jedes Werkzeug legt das vorher fest.
- Ein Werkzeug mit replay: "safe" wird nach einem Absturz erneut ausgeführt. Das passt für Lesezugriffe und für Aktionen, die schon idempotent sind.
- Ein Werkzeug ohne diese Angabe wird nie automatisch wiederholt. Das Modell bekommt ein "interrupted"-Ergebnis mit der bis dahin gespeicherten Ausgabe und entscheidet selbst.
Earendils Beispiel ist ein Deployment: Ein durch einen Absturz unterbrochenes Deployment wird dem Modell gemeldet, aber nie wiederholt. Eine vereinfachte Skizze auf Basis des README:
const bestellungLesen = defineTool({
name: "bestellung_lesen",
description: "Liest eine Bestellung aus der Shop-Datenbank",
parameters: obj({ orderId: str() }),
replay: "safe", // zweimal lesen schadet nicht, also nach Absturz wiederholen
execute: async (args) => {
/* ... */
},
});
const erstatten = defineTool({
name: "erstatten",
description: "Erstattet eine Bestellung",
parameters: obj({ orderId: str() }),
// keine Replay-Angabe: Nach einem Absturz erfährt das Modell,
// dass der Aufruf unterbrochen wurde. Er läuft nicht erneut.
execute: async (args) => {
/* ... */
},
});Replay-sicher ist Ihr Versprechen
Speicher-Backends für Checkpoints
Pi Durable trennt den Agenten vom Ort, an dem sein Zustand liegt. Das README nennt diese Backends:
| Speicher | Wo | Hinweise aus dem README |
|---|---|---|
| Memory | Im Prozess | Nichts wird dauerhaft gespeichert. Gut für Tests. |
| SQLite | Eine Datenbankdatei (Node) | WAL-Modus; Commits überstehen Prozessabstürze, die neuesten können bei Strom- oder Hostausfall verloren gehen. |
| JSONL | Append-only-Dateien in einem Ordner | Optional fsync vor jedem Commit. Hält die ganze Historie im Speicher, für lange Agenten empfiehlt das README SQLite. |
| IndexedDB | Browser | Nur ein Besitzer zur Zeit, per Web Lock absichern. |
| Cloudflare Durable Object | SQLite-Speicher eines Durable Objects | Commits sind Transaktionen des Objekts. |
Eigene Backends, etwa auf Postgres, sind möglich. Earendil liefert dafür eine Konformitäts-Testsuite. Für Unternehmen in Deutschland ist das ein Pluspunkt: Mit SQLite, JSONL oder einem eigenen Postgres bleiben Gesprächsverläufe und Werkzeugergebnisse auf Ihrer eigenen Infrastruktur. Das erleichtert die DSGVO-Dokumentation, denn Checkpoints enthalten schnell personenbezogene Daten.
Integrationen: Cloudflare, Temporal und Rivet
Cloudflare Agents SDK
Cloudflare beschreibt, wie Pi in einem Durable Object läuft, über PiHarness im Agents SDK. Pi legt Transkripte und Aufgaben in der SQLite-Datenbank des Objekts ab, in Tabellen mit dem Präfix "pi_". Solange Arbeit ansteht, feuert alle 30 Sekunden ein Alarm. Wird das Objekt verdrängt oder stürzt es ab, startet der nächste Alarm es neu.
Temporal (pi-temporal)
Temporal geht einen anderen Weg. Im Beitrag "The immortal life of Pi" vom 8. Oktober 2026 stellt Temporal pi-temporal vor, das den Pi-Coding-Agenten auf mehreren Temporal-Workern betreibt. Die Autoren wollten Failover zwischen Maschinen. Sie weisen darauf hin, dass der lokale SQLite-Speicher von Pi Durable zwar Prozessabstürze, aber keinen Hostausfall übersteht. Deshalb nutzt pi-temporal Temporal als Ausführungs-Engine. Das Projekt gilt als Experiment auf Basis eines kleinen Pi-Forks.
Rivet
Rivet kündigte am 7. Oktober 2026 an, dass seine Funktion pi() ein Pi Durable Harness in einem Rivet Actor ausführt. Jeder Actor speichert sein Harness in einer eigenen SQLite-Datenbank. Läufe überstehen so Abstürze und Upgrades, und inaktive Agenten können schlafen.
| Integration | Läuft auf | Zustand liegt in | Status |
|---|---|---|---|
| Cloudflare PiHarness | Durable Object über Agents SDK | SQLite des Objekts (pi_-Tabellen) | Pi Durable experimentell; API kann sich in Minor-Releases ändern |
| Temporal pi-temporal | Temporal-Worker | Geteilte Session-Dateien plus Temporal | Experiment auf einem Pi-Fork |
| Rivet pi() | Rivet Actor | SQLite des Actors | Rivet rechnet mit API-Änderungen |
Grenzen von Pi Durable
- Experimentell. Earendil schreibt, dass sich die API noch ändern kann. Das README warnt vor Änderungen ohne Vorankündigung.
- Kein eingebauter Freigabeschritt. Laut Cloudflare hat Pi Durable noch keinen Freigabe- oder Berechtigungsschritt für Werkzeugaufrufe. Per Hook lassen sich Werkzeuge blockieren, einen echten Freigabe-Ablauf mit Mensch müssen Sie selbst bauen.
- Lokaler Speicher. SQLite auf einer Maschine übersteht Prozessabstürze, aber keinen Hostverlust.
- Grenzen bei Cloudflare. Eine einzelne Modellanfrage, die länger als 15 Minuten streamt, kann abgeschnitten werden. Sessions lassen sich noch nicht löschen, was für Löschanfragen nach DSGVO relevant ist. Rollbacks auf ältere Pi-Versionen können neuere Gespräche unlesbar machen, Cloudflare rät zum Vorwärts-Deployment.
- Nur TypeScript, vorerst.
Erste Schritte
- 1Paket installieren und das Quick-Start-Beispiel aus dem README mit In-Memory-Speicher ausführen.
- 2Auf SQLite wechseln, eine lange Aufgabe starten, den Prozess beenden und resume() aufrufen.
- 3Jedes Werkzeug prüfen: replay-sicher oder nicht? Externe Aufrufe mit Idempotenzschlüssel versehen.
- 4Einen Hook einbauen, der riskante Werkzeuge blockiert, bis ein Freigabe-Ablauf steht.
- 5Hosting wählen: eigener Server, Cloudflare, Rivet oder Temporal, wenn Sie Failover zwischen Maschinen brauchen.
Den größeren Rahmen mit Temporal, Restate, Inngest, DBOS und LangGraph zeigt unser Beitrag zu ausfallsicheren KI-Agenten. Für die Cloudflare-Seite lohnt sich unser Beitrag zu Cloudflare Project Think.
Wie Halmob unterstützt
Halmob baut ausfallsichere Agenten: lang laufende Agenten, die ihren Zustand behalten, nach Fehlern neu versuchen und dort weitermachen, wo sie aufgehört haben, für Arbeit über Stunden oder Tage. Mit unserer Beratung zu Agenten-Plattformen helfen wir bei Auswahl, Einrichtung und Einführung von Pi Durable, OpenClaw, Hermes Agent, Meta Muse, OpenAI Dots oder Claude Duet, einschließlich der Replay-Prüfung der Werkzeuge und des Freigabe-Ablaufs, den Pi Durable Ihnen überlässt. Sprechen Sie uns an.