Was passiert mit der Arbeit, wenn die Sandbox verloren geht?

Ein Agent wacht auf und klont ein Repository. Er schreibt sich ein Hilfsskript, legt eine Analyse in einer selbst ausgedachten Datei ab und kommt bis zur Hälfte des Fixes. Dann ist der Container weg. Ein OOM-Kill, ein Host, der neu startet, ein Prune.

Was davon ist morgen noch da?

Die Frage wird genau so gestellt. Auf Hacker News fragt jemand im Oktober 2025, wie man die Compute-Schicht zustandslos hält, ohne ganze Systemzustände irgendwo abzulegen. Die Antwort dort lautet: gemountete Volumes, die beim Neustart wieder eingehängt werden.

Das ist die halbe Antwort, denn die andere Hälfte beginnt beim Ausfall der Maschine selbst.

Die Rechenzeit ist kurzlebig, das Home bleibt

Rechenzeit und Home sind absichtlich voneinander getrennt. Die Data Plane ist dumm und ersetzbar: Eine Sandbox ist ein isolierter Arbeitsplatz mit persistentem Home und laufendem Daemon. Sie hält keinen Zustand, der für die Plattform kritisch wäre, außer den Arbeitsdaten des jeweiligen Agenten. Geht sie verloren, wird sie aus Konfiguration und Home neu gebaut.

Das Isolationsmodell dahinter ist einen Satz lang: persistentes Volume, kurzlebige Rechenzeit. Der Agent wacht auf, hängt sein Home ein, arbeitet und schläft wieder ein. Nur das Home überlebt.

Damit ist die Frage nur verschoben, denn ein Volume liegt auf einer Maschine, und Maschinen fallen aus.

Fast nichts in einem Home ist einzigartig, und genau das Wenige liegt verstreut

Ein vermessenes Entwickler-Home hat 7,1 GB und besteht zu über 99 Prozent aus Ableitbarem. Davon sind 3,0 GB Checkouts unter repos/, deren Wahrheit im Git-Remote des Projekts liegt, und 4,0 GB Toolchain-Caches, darunter flutter, .pub-cache, .gradle, .npm sowie jdk. Ein paar MB sind Wiki und Skills, die ohnehin zentral liegen. Bleiben 48 MB, deren Quelle nirgendwo sonst liegt.

Diese 48 MB sind der ganze Punkt und liegen überall. Neben den Session-Transkripten findet man useSevenAssistant.ts mit 95 KB extrahiertem Code, dazu panel.json, subagent-223.json und die Verzeichnisse fix223/ und verify-729/. Alle liegen direkt im Wurzelverzeichnis, dort wo der Agent sie während des Laufs abgelegt hat.

Weil ein Agent seine Zwischenergebnisse dorthin legt, wo es ihm sinnvoll erscheint, funktioniert keine Liste. Eine positive Liste überlebt den Agenten nicht, der sich morgen ein analysis/ anlegt, und einer negativen Liste gegen die Caches des Image-Profils ergeht es genauso. Jede Liste über den Wert einer Datei ist eine Regel, die falsch sein kann, und ihr Fehler kostet bereits bezahlte Arbeit.

Deshalb wird das ganze Home gesichert

Nach jedem Job wandert das Home als Ganzes in einen zentralen Store und wird beim Aufwachen von dort materialisiert, ohne Whitelisting und ohne Prüfung, ob ein Checkout sauber ist. Die Frage, was davon wertvoll ist, wird nie gestellt.

Praktikabel wird das durch die Bauart des Stores. Er ist inhaltsadressiert: Derselbe Inhalt ist ein Block über alle Agenten einer Organisation hinweg, adressiert über den Schlüssel (org_id, hash). Nach oben wandern nur die neuen Blöcke, nach unten nur die fehlenden. Dateien bis 8 MB werden als Ganzes adressiert, größere in feste 4-MB-Blöcke zerlegt.

Die 4 GB Toolchain-Caches liegen damit einmal zentral statt einmal pro Agent, und die 48 MB sind mitgesichert, ohne dass jemand notieren musste, dass es sie gibt.

Der Vorgang hat einen eigenen Zustand im Lebenszyklus: securing steht seit der Migration 0079_status_securing zwischen der letzten fertigen Aufgabe und der verschwundenen Sandbox. Der Container wird gestoppt und das Home in den Store geschrieben. Bei einem kleinen Home ist das eine Sekunde, bei einem gewachsenen eine halbe Minute Scannen.

Was im Store liegt, ist der Stand des letzten Syncs. Der Sync läuft beim echten Einschlafen, wenn die Rechenzeit unten ist und niemand mehr in das Home schreibt. Eine warme Sandbox erreicht diesen Punkt nie und wird deshalb gesichert, solange sie geparkt ist: im Hintergrund, höchstens alle fünf Minuten. Verliert ein Agent seinen Container mitten im Lauf, liegt im Store der Stand des letzten dieser Syncs, und was er seither geschrieben hat, geht mit dem Container.

Ausgelassen wird trotzdem etwas, und der Unterschied liegt in der Begründung. COVEY_HOME_EXCLUDES nimmt Pfade heraus, voreingestellt die Schrott-Klasse, darunter __pycache__, .dartServer, *.pyc, *.tmp sowie die Caches von pip und Playwright. Diese Pfade stellt allein das Werkzeug wieder her, das sie ohnehin liest, sodass ihr Fehlen nichts kostet. Die Paket-Caches, etwa .npm und .gradle, stehen bewusst nicht darin, da ihr Auslassen zwar Speicher und Scan-Zeit spart, auf dem nächsten Host aber einen erneuten Download kostet.

Was ein Verlust kostet, ist Zeit

Die Bindung eines Agenten an eine Maschine wird damit zur Vorliebe. Der Scheduler bevorzugt den Runner, auf dem der Agent zuletzt lief, weil dessen Blöcke schon lokal liegen; auf einem anderen kommen nur die fehlenden nach.

Der schlechteste Fall ist ein frischer Host ohne einen einzigen Block: eine Vollübertragung, bei der ein Flutter-Agent minutenlang keine Zeile liest. Das kostet Zeit, und der Stand, den der Store hält, kommt dabei vollständig an.

Bezahlt wird diese Bauart an mehreren Stellen. Der längere Einschlafpfad ist eine davon, der erste Sync eines gewachsenen Homes ein voller Durchlauf über 7 GB. Der Store hält außerdem, was der Runner ohnehin auf der Platte hat: bei einem einzelnen Agenten fast eine Verdopplung, ab dem zweiten Entwickler-Agenten rechnet die Deduplizierung sie wieder herein.

Und er braucht Backup wie die Datenbank. In seiner Funktion ist er ein Cache, in seiner Schutzbedürftigkeit ein Datenbestand.

Pro Agent existiert ein Snapshot, den jeder Sync ersetzt, und der Store hält keine Historie früherer Zustände.

Für die kleinsten Installationen lässt sich der Store mit COVEY_HOME_STORE=false abschalten. Dann bleiben Homes Verzeichnisse ohne Snapshot, und ein verlorenes Home ist verloren.

Eine Sandbox darf dumm und ersetzbar sein, solange nichts in ihr liegt, was nur in ihr liegt. Genau deshalb geht das ganze Home in den Store, mitsamt allem, was der Agent sich selbst angelegt hat.