Du startest am Dienstagabend einen Sechs-Stunden-Agent. Er soll die Preisseite eines Konkurrenten scrapen, vierzig vergammelte Linear-Tickets triagieren und einen Postgres-Migration-Dry-Run fahren, während du schläfst. Das Dashboard sagt „autonom". Das Marketing sagt „long-horizon". Deine Kreditkarte sagt „ja gut, meinetwegen". Du klappst den Laptop zu.

Du wachst auf zu einem halbfertigen Task, drei Duplikat-Linear-Tickets unter deinem Namen und einem Slack-Channel voller Fragen von einem Teamkollegen, der dachte, du wärst um 3 Uhr morgens wach gewesen. Der Agent ist in Stunde vier abgestürzt. Niemand — weder du noch der Anbieter — kann dir sagen, ob „resume" zu klicken den Schaden verdoppelt oder behebt.

Willkommen im April 2026, dem Monat, in dem Multi-Stunden-Agents zu einer Pricing-Metrik wurden, bevor sie zu einer Reliability-Garantie wurden 😹.

Acht Tage, drei Persistenzmodelle, null Standards

Zwischen dem 8. und 15. April haben die zwei größten Agent-Anbieter drei verschiedene Wege ausgeliefert, einen AI-Agent über die Eine-Stunden-Marke hinaus am Leben zu halten — und keiner stimmt darüber überein, was „am Leben" eigentlich bedeutet.

Am 14. April launchte Anthropic Claude Code Routines — geplante oder per Webhook ausgelöste Agent-Runs, Research Preview, abgeriegelt hinter Tageslimits (5/Tag bei Pro, 15/Tag bei Max, 25/Tag bei Team und Enterprise). Minimales Schedule-Intervall: eine Stunde. The Register nannte es höflich „mäßig clevere Cron-Jobs" 😼.

Am 15. April lieferte OpenAI das Agents SDK v0.14.0 aus — mit einer neuen SandboxAgent-Surface, einem pluggable Sandbox-Backend (Docker, E2B, Modal, Vercel, Cloudflare — such dir was aus) und einem Ding namens MEMORY.md — eine buchstäbliche Markdown-Datei, die der Agent zwischen Runs an sich selbst schreibt.

Und am 8. April hatte Anthropic bereits Managed Agents gelauncht, die die Nutzung in Session-Stunden abrechnen — eine Billing-Einheit, die explizit davon ausgeht, dass dein Agent stundenlang am Stück läuft.

Drei Persistenzmodelle. Null Interop. Willkommen bei Long-Horizon-Autonomie.

Was jeder Anbieter tatsächlich persistiert

Kurzer Umweg — denn „der Agent erinnert sich" klingt einfach, ist es aber nicht.

Ein Agent ist eine Schleife: Das LLM (Large Language Model — das Hirn hinter ChatGPT oder Claude) liest einen Task, ruft ein Tool auf (Websuche, Shell-Befehl, API-Call), liest das Ergebnis, entscheidet, was als Nächstes zu tun ist. Ein Long-Horizon-Agent ist diese Schleife, die stundenlang läuft. Ein Checkpoint ist ein gespeicherter Snapshot des Loop-Zustands, damit du, falls der Prozess abstürzt, vom Snapshot aus weitermachen kannst, statt von vorne zu beginnen.

Hier ist, was jeder Anbieter tatsächlich speichert:

  • Anthropic Routines — speichert die Konversation und den Plan innerhalb einer Session. Laut den Docs: „each matching GitHub event starts a new session" — Sessions teilen nicht mal Zustand zwischen Triggern. Und: „events beyond the limit are dropped until the window resets" — heißt, ein Webhook-Spike verliert still und leise Arbeit, keine Queue, kein Retry 🙀.
  • OpenAI Sandbox Agents — speichert eine MEMORY.md-Datei im Filesystem der Sandbox. OpenAIs eigene Docs sagen, sie „distills lessons into readable files rather than preserving full workspace state." Auf Deutsch: Sie merkt sich, was sie gelernt hat, nicht, was sie getan hat. Mitten im git push gekillt? Der Plan überlebt. Der halb gepushte Commit nicht.
  • Anthropic Managed Agents — rechnet pro Session-Stunde ab. Was eine Session-Stunde überhaupt checkpointet, ist undokumentiert.

Keiner von ihnen — keiner — dokumentiert, was mit Side-Effects passiert, wenn ein Run abstürzt. Ein Side-Effect ist alles, was der Agent außerhalb seines eigenen Speichers angefasst hat: ein abgefeuerter API-Call, ein erstelltes Linear-Ticket, eine in deine Datenbank eingefügte Zeile, eine gesendete Slack-Nachricht, ein gepushter Git-Commit. Die spulen sich nicht zurück.

Das „Aha", das niemand auf die Landingpage gepackt hat

Hier ist der leise Teil laut ausgesprochen: Wenn ein Multi-Stunden-Agent abstürzt und resumed, stellt der Checkpoint die Intention des Agents wieder her, nicht den Zustand der Welt, auf die der Agent eingewirkt hat.

Dein Agent hat in Stunde drei ein Linear-Ticket erstellt. Stunde vier: Crash. Der Checkpoint von Stunde 3.5 weiß nicht, dass das Ticket existiert. Resume: Er erstellt das Ticket noch mal. Glückwunsch, du hast Duplikate — und laut Anthropics Docs „Linear tickets… use your linked accounts", also laufen die Duplikate unter deinem Namen. Deine Teamkollegen denken, du spammst sie zu 😾.

Das ist kein Bug. Das ist die Architektur. The New Stacks Analyse der OpenAI-Release-Notes merkt an, dass die Harness „can keep auth, billing, audit logs, human review, and recovery state outside any one container" — was stimmt, und gleichzeitig eine höfliche Art ist zu sagen, dass das SDK Meinungen zu seinem eigenen Zustand hat und keine zu deinem.

Googles Vertex Agent Engine hatte, fürs Protokoll, Sessions und Memory Bank schon im Dezember 2025 als GA; April 2026 hat nur noch eine Agent-Designer-Preview obendrauf gepackt. Also löst niemand — weder Anthropic, noch OpenAI, noch Google — Side-Effect-Idempotenz für dich.

Der Preis, den niemand auf die Pricing-Page gepackt hat

Idempotenz — die Eigenschaft, dass etwas zweimal zu tun denselben Effekt hat wie es einmal zu tun — ist jetzt komplett dein Problem. Jeder Tool-Call, den dein Agent in die Außenwelt macht, braucht einen Idempotency-Key (eine eindeutige ID pro Operation, damit der empfangende Service Retries deduplizieren kann). Jede externe Aktion braucht eine journaled Outbox (ein Log, das du vor der Aktion schreibst, damit du weißt, was du versucht hast, selbst wenn du abstürzt, bevor du den Erfolg bestätigt bekommst).

Re-Runs kosten doppelt: doppelte Tokens (die Wort-Chunks, die das LLM verarbeitet, abgerechnet pro Million), doppelte Session-Stunden, doppelte Wall-Clock-Zeit, die du gewartet hast. Und weil kein Anbieter ein portables Checkpoint-Format anbietet, kannst du nicht mitten im Task von Anthropic auf OpenAI failovern. Du bist eingelockt durch die Form deiner Bug-Reports.

Der Hacker-News-Thread zu Routines hat es klar gesagt: „I'm not going to build my business on things I can't replicate myself." Ein anderer Kommentator merkte an, eine Multi-Stunden-Routine zu debuggen wäre „maddening." In beiden Punkten: korrekt 🐈‍⬛.

Wenn du das in Production schickst

Wenn du im April 2026 Agents über die Eine-Stunden-Marke hinaus laufen lässt, ist der Checkpoint der Plattform nicht deine Recovery-Story. Er ist eine Quittung. Du brauchst drei Dinge, die die Anbieter nicht für dich gebaut haben:

  1. Eine journaled Outbox — jeder externe Side-Effect schreibt vor der Ausführung in ein Log, damit Replay weiß, was der Agent versucht hat.
  2. Idempotency-Keys auf jedem Tool-Call — GitHub, Linear, Slack, deine eigenen APIs. Keine Ausnahmen.
  3. Ein manuelles Resume-UI — damit ein Mensch nach einem Crash entscheidet, ob retried, geskippt oder abgebrochen wird. Nicht der Agent. Nicht der Anbieter.

Was sich diesen Monat tatsächlich geändert hat

„Agents laufen stundenlang" wurde im April 2026 zu einer Pricing-Unit. Die Plumbing darunter ist immer noch im Fünfzehn-Minuten-Maßstab. Irgendwann im nächsten Quartal wird ein Enterprise das erste öffentliche Post-Mortem zu einem Managed Agent schreiben, den niemand zurückspulen konnte — und die interessante Frage wird nicht sein, welcher Anbieter versagt hat, sondern warum überhaupt jemand dachte, der Checkpoint sei die Garantie 😸.

Der Rat des Katers: Betreib deine eigene Outbox. Trau keinem Anbieter-„Resume"-Button. Und wenn ein Sales-Deck „autonom" sagt, lass sie das Wort schriftlich definieren.