Session-State über Crashes hinweg retten: Wie Anthropic, OpenAI, xAI und Google es 2026 lösen

Du arbeitest seit zwei Stunden in einer Claude-Code-Session an einem Refactoring. Der Agent hat sich durch dein Codebase gegraben, hunderte Files gelesen, Architektur-Entscheidungen mit dir abgestimmt, drei abgebrochene Sackgassen erkundet. Dann: macOS will einen Restart für ein Security-Update. Oder die SSH-Verbindung bricht ab. Oder dein Editor friert ein.

Was passiert mit dem ganzen Kontext?

Die ehrliche Antwort lautet bei allen vier grossen Anbietern: standardmässig nichts Gutes. Aber jeder hat andere Mechanismen gebaut, um den Schaden zu begrenzen — und die Unterschiede sind grösser, als man auf den ersten Blick denkt. Dieser Artikel arbeitet sich durch die offizielle Dokumentation der vier Anbieter (Anthropic, OpenAI, xAI, Google) und ergänzt, wo nötig, dokumentierte Bug-Reports und Engineering-Blogposts.

Das Grundproblem: LLMs sind stateless

Bevor wir uns den Lösungen widmen, ein wichtiger Punkt: Jeder API-Call zu einem grossen Sprachmodell ist im Kern zustandslos. Das Modell selbst hat kein Gedächtnis zwischen zwei Requests. Wenn dein Agent "weiterarbeiten" soll, muss irgendwer den Kontext erneut hineinreichen — entweder du, ein SDK, oder eine vom Anbieter verwaltete Datenstruktur. Die Frage ist also nicht ob State irgendwo persistiert wird, sondern wo: client-seitig (du verwaltest Files, Logs, Datenbanken) oder server-seitig (der Anbieter speichert die Konversation hinter einer ID). ¹

Anthropic: CLAUDE.md, Sessions und das Memory Tool

Anthropic verfolgt eine bewusst dateibasierte Philosophie. Es gibt keinen "Session-State auf unseren Servern", auf den du eine ID setzt — stattdessen baut das gesamte Ökosystem auf Files auf, die du selbst kontrollierst.

Für Claude Code ist das primäre Persistenz-Mittel CLAUDE.md, eine Datei im Projekt-Root, die automatisch bei jedem Session-Start in den Kontext geladen wird. ² Sie funktioniert wie ein Briefing für einen neuen Mitarbeiter, das jeden Morgen erneut gelesen wird. Daneben hat das Claude Agent SDK echte Session-Persistenz: Das SDK schreibt jede Session — Prompts, Tool-Calls, Tool-Results, Antworten — automatisch auf Disk, sodass du sie später fortsetzen kannst. ³ Drei Modi sind relevant:

# Letzte Session in diesem Verzeichnis fortsetzen
claude --continue

# Aus einer Liste auswählen
claude --resume

Im SDK selbst sieht das so aus:

import { query } from "@anthropic-ai/claude-agent-sdk";

// Erster Call: erstellt eine neue Session
for await (const msg of query({
  prompt: "Analyze the auth module",
  options: { allowedTools: ["Read", "Glob", "Grep"] }
})) {
  if (msg.type === "result") console.log(msg.result);
}

// Zweiter Call: continue: true setzt auf der jüngsten Session auf
for await (const msg of query({
  prompt: "Now refactor it to use JWT",
  options: { continue: true, allowedTools: ["Read", "Edit", "Write"] }
})) {
  if (msg.type === "result") console.log(msg.result);
}

Continue findet die zuletzt benutzte Session im aktuellen Verzeichnis. Resume nimmt eine konkrete Session-ID — nötig, sobald du mehrere parallele Threads hast. Fork erstellt einen Branch, ohne den Original-Thread zu verlieren. ³

Wo --resume die Sessions findet — und wann sie verschwinden

--resume ist keine Magie, und das ist wichtig zu verstehen, bevor man sich darauf verlässt. Der Mechanismus ist vollständig lokal und an dein Filesystem gekoppelt.

Speicherort. Anthropic dokumentiert: "Claude Code stores session transcripts locally in plaintext under ~/.claude/projects/ for 30 days by default." ⁴ Auf Windows entsprechend unter %USERPROFILE%\.claude\projects\. Innerhalb von projects/ bekommt jedes Projekt einen eigenen Unterordner — und der wird aus dem absoluten Pfad des Arbeitsverzeichnisses abgeleitet, mit / ersetzt durch -:

~/.claude/
├── projects/
│   ├── -Users-dev-code-api-service/
│   │   ├── 9d6e8a4a-cee8-41ae-be27-1a848fe3c74b.jsonl
│   │   ├── b3f1d9e2-...-.jsonl
│   │   └── memory/                    ← Auto-Memory (cross-session)
│   └── -Users-dev-code-frontend-app/
│       └── 7c2a1b88-...-.jsonl
├── todos/
├── shell-snapshots/
├── backups/
└── history.jsonl

Jede .jsonl ist eine vollständige Session — eine Zeile pro Event (User-Message, Assistant-Response, Tool-Call, Tool-Result). Der Filename ist die Session-UUID, die du bei claude --resume <id> eintippst. Praktischer Nebeneffekt: Du kannst die Files mit Bash-Tools durchsuchen.

# Alle Sessions finden, in denen "auth refactor" vorkam
grep -l "auth refactor" ~/.claude/projects/*/*.jsonl

Anthropic dokumentiert ausserdem ein zweites Mittel im selben projects/-Pfad: Auto-Memory unter projects/<project>/memory/ — das sind Notizen, die Claude über Sessions hinweg behält, separat von den Session-Transkripten. ⁵

Project- vs. user-scoped. Die wichtigste Unterscheidung: Sessions sind project-directory-scoped, nicht user-scoped. Anthropic dokumentiert: "Each Claude Code conversation is a session tied to your current directory. The /resume picker shows sessions from the current worktree by default, with keyboard shortcuts to widen the list to other worktrees or projects." ⁶ In der Praxis heisst das:

• claude --continue in /Users/dev/code/api-service setzt auf der jüngsten Session dieses Verzeichnisses auf, nicht der jüngsten Session insgesamt.
• Verschiebst du api-service nach /Users/dev/work/api-service, ist der Pfad ein anderer — und damit der ~/.claude/projects/-Unterordner. --resume findet die alten Sessions nicht mehr, weil das Storage über den absoluten Pfad indiziert wird. ⁷
• Der gleiche Effekt tritt auf, wenn du das Projekt auf einem zweiten Rechner an einem anderen Pfad ausgecheckt hast. Selbst nach rsync oder Cloud-Sync findet --resume die Sessions nicht, weil zwei verschiedene absolute Pfade zwei verschiedenen Storage-Buckets entsprechen. ⁸

Anthropic dokumentiert die Trennung zwischen project-scoped und user-scoped Files explizit: "Commit project files to git to share them with your team; files in ~/.claude are personal configuration that applies across all your projects." ⁵ User-scoped (also über alle Projekte hinweg gleich) sind drei Schichten, die sich gerne mit Sessions verwechseln lassen:

• ~/.claude/CLAUDE.md — globale Memory, wird in jedem Projekt geladen.
• ~/.claude/settings.json — User-Settings.
• ~/.claude/history.jsonl — eine flache Liste aller jemals abgesetzten Slash-Commands über alle Projekte hinweg, separat von den Session-Transkripten.

Die Trennung ist bewusst: Project-State soll nicht kontaminieren, User-Präferenzen sollen es überall tun.

Aufbewahrung und automatische Löschung. Hier kommt der Punkt, der dich beissen kann. Beim Start prüft Claude Code das Alter der Files und löscht alle, die älter als der cleanupPeriodDays-Wert sind. Default ist 30 Tage, Minimum 1. ⁹ Betroffen sind seit v2.1.117 nicht nur die projects/-Transkripte, sondern auch tasks/, shell-snapshots/ und backups/. ¹⁰

Du kannst das in ~/.claude/settings.json konfigurieren:

{
  "cleanupPeriodDays": 365
}

Aber Achtung — zwei sehr unangenehme Fallstricke aus den GitHub-Issues:

1. cleanupPeriodDays: 0 löscht NICHT "behalte für immer". Dasselbe Field steuert versehentlich auch den Write-Pfad — bei 0 werden gar keine Transcripts mehr geschrieben. Wenn du unbegrenzt aufheben willst, setz einen sehr hohen Wert (z.B. 36500 für ~100 Jahre), nicht 0. ¹¹
2. claude -p --setting-sources local ignoriert deine User-Settings. In nicht-interaktiven Runs (CI, Scripts) wird ~/.claude/settings.json übersprungen, der Cleanup fällt auf den 30-Tage-Default zurück und löscht global über alle Projekte Sessions, die älter sind. Wenn du Batch-Jobs fährst und langlebige Sessions brauchst, setz cleanupPeriodDays zusätzlich in .claude/settings.json im Repo oder per --settings-Flag. ¹²

Praktische Konsequenzen. Drei Dinge, die ich mir nach dieser Recherche zur Gewohnheit gemacht habe:

• Sessions, die du wirklich behalten willst, kriegen einen Namen (/rename oauth-migration). Auto-generierte Summaries sind nach drei Wochen unbrauchbar; benannte Sessions findest du im Picker auch ein halbes Jahr später noch.
• Wichtige Erkenntnisse wandern raus aus der Session. Bevor eine Session relevante Dinge enthält, die ich dauerhaft brauche, lasse ich Claude die Essenz nach CLAUDE.md oder ein docs/decisions/-File schreiben. Die .jsonl ist Replay-Material, nicht Wahrheitsquelle.
• Wenn du Cross-Machine-Continuity brauchst, vergiss --resume. Die Pfad-Kopplung ist hart. Es gibt einen offenen Feature-Request bei Anthropic für serverseitige CLI-Sessions, aber Stand heute ist das nicht implementiert. ¹³

Für die API direkt gibt es seit dem Sonnet 4.5-Release das Memory Tool (memory_20250818). Anders als bei OpenAI hostet Anthropic keine zentrale Memory-Datenbank — du implementierst den Storage-Handler selbst (Filesystem, S3, Postgres, was immer passt) und Claude ruft dein Tool über ein standardisiertes Interface auf, um Files unter /memories zu lesen und zu schreiben. ¹⁴

Anthropic ergänzte 2025 zwei Mechanismen, die in der Praxis viel ausmachen: Context Editing und Compaction. Der Engineering-Blog beschreibt: "Compaction is the practice of taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary. […] In Claude Code, for example, we implement this by passing the message history to the model to summarize and compress the most critical details. The model preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages." ¹⁵

Context Editing ist die feinere Variante davon: Du kannst dem Modell sagen, dass es bei einer bestimmten Token-Schwelle alte Tool-Outputs automatisch löschen soll, während die wichtigen State-Notizen im Memory Tool erhalten bleiben:

CONTEXT_MANAGEMENT = {
    "edits": [
        {
            "type": "clear_tool_uses_20250919",
            "trigger": {"type": "input_tokens", "value": 30000},
            "keep": {"type": "tool_uses", "value": 2},
            "clear_at_least": {"type": "input_tokens", "value": 5000}
        }
    ]
}

Die wichtigste Lehre aus dem Anthropic-Lager: Memory ist Architektur, kein Chat-History-Wachstum. Das Engineering-Team formuliert es so: "Treating context as a precious, finite resource will remain central to building reliable, effective agents." ¹⁵

OpenAI: Vom Threads-Chaos zur Responses API

OpenAI hat seinen State-Management-Ansatz 2025 grundlegend umgebaut. Die alte Assistants API mit Threads, Runs und Polling wird in der ersten Hälfte 2026 abgeschaltet, ersetzt durch die Responses API. ¹⁶ Das ist relevant, weil viele Tutorials draussen noch die alten Patterns zeigen.

Die Responses API ist explizit für agentische Workloads gebaut. Der Kern: Du setzt store: true, und der Server merkt sich die Konversation. Beim nächsten Turn übergibst du nicht die ganze History, sondern nur eine previous_response_id:

from openai import OpenAI
client = OpenAI()

resp1 = client.responses.create(
    model="gpt-5",
    input="Plan the refactor for the auth module.",
    store=True
)

# Später, eventuell nach einem Crash und Restart:
resp2 = client.responses.create(
    model="gpt-5",
    input="Now implement step 2 of the plan.",
    previous_response_id=resp1.id
)

Das Subtile daran: Es geht nicht nur um Convenience. Reasoning-Tokens (das interne Chain-of-Thought von Modellen wie o3 oder GPT-5) gehen bei einem stateless Setup nach jedem Turn verloren. Mit der Responses API persistieren sie zwischen Turns. OpenAI dokumentiert in seinem Cookbook: "If you use previous_response_id for multi-turn conversations, the model will automatically have access to all previously produced reasoning items." ¹⁷ Für Reasoning-Modelle wie o3 macht das laut OpenAI einen messbaren Qualitäts-Unterschied.

Für längere und übergreifende Threads gibt es die Conversations API: Eine Conversation ist ein langlebiges Objekt mit eigener ID, das nicht der 30-Tage-TTL für einzelne Responses unterliegt. OpenAI dokumentiert: "Response objects are saved for 30 days by default. […] Conversation objects and items in them are not subject to the 30 day TTL. Any response attached to a conversation will have its items persisted with no 30 day TTL." ¹⁸

conv = client.conversations.create()

resp = client.responses.create(
    model="gpt-5",
    input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
    conversation=conv.id
)

Falls du in einer Zero-Data-Retention-Umgebung arbeitest, gibt es einen Mittelweg: Du setzt store: false und holst dir die Reasoning-Tokens als encrypted_content zurück, das du selbst persistierst. OpenAI dokumentiert: "When a request includes encrypted_content, it is decrypted in-memory (never written to disk), used for generating the next response, and then securely discarded." ¹⁹ Server-side State ohne Server-side Storage.

Für Crashes besonders relevant: Die Response-ID ist kurz und persistent. Schreib sie nach jedem Turn in eine lokale Datei oder Datenbank, und ein Restart bedeutet einen einzigen Lookup statt einer Replay-Schlacht.

xAI: Stateful Responses mit 30-Tage-Verfallsdatum

xAI hat seinen eigenen Responses-Endpoint (https://api.x.ai/v1/responses), der konzeptionell stark an OpenAI angelehnt ist. Die xAI-Doku formuliert: "The Responses API is the preferred way of interacting with our models via API. It allows optional stateful interactions with our models, where previous input prompts, reasoning content and model responses are saved and stored on xAI's servers. […] This behavior is on by default." ²⁰ Die Aufbewahrung: "New responses will be stored for 30 days and then permanently deleted." ²¹

from openai import OpenAI

client = OpenAI(
    api_key="<XAI_API_KEY>",
    base_url="https://api.x.ai/v1",
)

# Erster Call - wird auf xAIs Servern gespeichert (Default)
response = client.responses.create(
    model="grok-4",
    input=[{"role": "user", "content": "What is 2+2?"}],
)

# Konversation fortsetzen - keine History nötig
second_response = client.responses.create(
    model="grok-4",
    previous_response_id=response.id,
    input=[{"role": "user", "content": "Now multiply that by 10"}],
)

Wichtig zur Abrechnung — auch wenn du die History nicht selbst sendest, wird sie vollständig berechnet: "Although you don't need to enter the conversation history in the request body, you will still be billed for the entire conversation history when using Responses API." ²⁰ Ein 50-Turn-Thread kostet beim 50. Turn entsprechend mehr als ein einzelner kurzer Prompt.

Für Zero-Data-Retention-Kunden weist xAI explizit auf die Konsequenz hin: "No server-side conversation history: Because requests are not stored, features that rely on server-side state — such as the Responses API's automatic conversation threading via previous_response_id — are unavailable. You must manage conversation context client-side, e.g., by using use_encrypted_content for agentic tool-calling state." ²²

Der grosse Caveat bleibt: Die 30-Tage-TTL macht xAIs nativen Mechanismus für alles, was länger laufen muss, ungeeignet. Praktische Konsequenz ist ein Hybrid-Setup: xAI für die laufende Session, dein eigener Storage für die Persistenz. Nach jedem signifikanten Turn exportierst du das Messages-Array und persistierst es in einer Datenbank deiner Wahl.

Beachte auch: Die Memory-Funktion in der Grok-Web-App (das, was bei der Frage "Erinnerst du dich an mein Projekt?" aktiv wird) ist eine andere Schicht — sie funktioniert nur innerhalb der Grok-Apps und ist beim Launch im April 2025 explizit nicht in der EU und UK verfügbar gewesen. ²³ Für Agent-Entwicklung relevant ist die API-Schicht, nicht die App-Memory.

Google: Context Caching, Sessions und Memory Bank

Google trennt das Problem sauber in drei Schichten — und das ist tatsächlich nützlich, wenn man die Trennung versteht.

Schicht 1: Context Caching. Auf der reinen Gemini-API gibt es Explicit Caching: Du legst einen statischen Block (System-Instruction, grosses Dokument, lange Few-Shot-Beispiele) in einen Cache mit einer TTL — Default ist eine Stunde, du kannst sie hochsetzen. ²⁴ Der Discount auf Cache-Hits beträgt laut Google-Doku 90 Prozent auf Gemini 2.5+ und 75 Prozent auf Gemini 2.0. ²⁵ Das ist Kosten-Optimierung, kein State-Management — der Cache speichert Input, nicht Konversationsverlauf.

from google import genai

client = genai.Client()
cache = client.caches.create(
    model="gemini-2.5-flash",
    config={
        "system_instruction": "You are an expert analyzing transcripts.",
        "ttl": "3600s",
    }
)

resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Summarize the key risks.",
    config={"cached_content": cache.name}
)

Schicht 2: Sessions im Agent Development Kit (ADK). Hier wird's für Agents interessant. Eine Session enthält Session-ID, User-ID, Event-History und State (ein Key-Value-Scratchpad). Der InMemorySessionService ist nur für lokale Entwicklung — beim Restart ist alles weg. Persistente Optionen sind DatabaseSessionService oder die managed Vertex AI Sessions. ²⁶

Schicht 3: Vertex AI Memory Bank. Das ist Googles Antwort auf "Was soll der Agent über User hinweg merken?" Die offizielle Doku formuliert: "Memory Bank scopes memories to a specific identity, allowing an agent to remember a user's preferences, history, and key details across multiple sessions." ²⁷ Der Mechanismus ist intelligenter als reine History-Speicherung — Memory Bank extrahiert mit Hilfe von Gemini Schlüsselinformationen aus den Session-Daten und speichert nur die "Memories", nicht die Roh-Events.

Im ADK kannst du Memory-Generierung als Callback nach jeder Session hängen:

from google.adk.agents import Agent
from google.adk.tools.preload_memory_tool import PreloadMemoryTool

agent = Agent(
    model="gemini-2.5-flash",
    name="stateful_agent",
    instruction="You are a helpful assistant. Use past memories when relevant.",
    tools=[PreloadMemoryTool()]
)

PreloadMemoryTool injiziert Memories at jedem Turn-Start in den System-Prompt. Memory Bank merkt sich Präferenzen, der Sessions-Service hält die laufende Konversation, der Cache spart Kosten — drei Schichten für drei Probleme.

Google weist explizit auf einen Sicherheitsaspekt hin, der oft übersehen wird: "Memory poisoning occurs when false information is stored in Memory Bank. The agent may then operate on this false or malicious information in future sessions." ²⁷ Das ist ein generelles Problem aller persistenten Memory-Systeme, nicht nur bei Google — wer User-Input direkt in Memories schreibt, baut sich einen Persistent-Prompt-Injection-Vektor.

Wenn die Native-Lösung nicht reicht: Das Hybrid-Muster

Hier ist der ehrliche Punkt, den keiner der Anbieter im Marketing nennt: Für lange, komplexe Sessions reicht keine der nativen Lösungen alleine. Server-side State läuft ab (xAI 30 Tage ²¹, OpenAI 30 Tage Default ¹⁸), Context-Windows füllen sich, Reasoning-Tokens werden komprimiert oder verworfen. Und wie wir gerade bei Claude Code gesehen haben: Auch lokales Storage hat einen Default-Cleanup, der dir wichtige Sessions still und leise wegräumt. Die robusteste Architektur ist ein Hybrid.

Das Muster funktioniert in jedem Ökosystem ähnlich:

1. Periodisches Checkpointing. Lass deinen Agent regelmässig (alle 10–15 Turns oder bei wichtigen Entscheidungen) ein knappes Checkpoint schreiben — keine Volltranskripte, sondern getroffene Entscheidungen, offene Aufgaben, Architektur-Constraints. Das geht in CLAUDE.md (Anthropic), in eine Conversation (OpenAI), in eine Memory in Memory Bank (Google) oder schlicht in eine STATE.md neben deinem Code.

2. Handoff-Files. Wenn eine Session abgeschlossen oder unterbrochen wird, schreibt der Agent eine Handoff-Notiz: "Wo stehe ich? Was kommt als Nächstes? Welche Files sind betroffen?" In Claude Code kannst du das direkt prompten: "Bevor wir aufhören: Schreib HANDOFF.md mit dem aktuellen Stand." Bei einem Restart liest du HANDOFF.md zuerst.

3. Long-term Memory für stabile Fakten. Project-Conventions, Coding-Style, wiederkehrende Tools — das gehört in eine persistente Memory-Schicht (Memory Bank, Memory Tool, oder eine selbst gehostete SQLite/Postgres-Lösung). Diese Schicht überlebt jeden Crash, weil sie nicht zur Session gehört.

4. Ein einfaches Resume-Protokoll. Auf einer neuen Session ist der erste Schritt immer derselbe: Lade Handoff-File → lade Long-term Memory → frag den User, ob etwas Neues hinzugekommen ist. Drei Schritte, fünf Sekunden, und du hast den Kontext zurück.

In der Praxis ist Schritt 2 derjenige, der am meisten unterschätzt wird. Ein guter Handoff ist nicht "alles, was wir besprochen haben", sondern die Antwort auf eine Frage: Welche Information bräuchte ich morgen früh, wenn ich frisch hier reinkomme, um in zwei Minuten wieder produktiv zu sein?

Konkrete Empfehlungen

Wenn du heute eine Wahl treffen müsstest, ohne grosse Architektur-Diskussion:

• Du arbeitest interaktiv mit Claude Code: Verlass dich auf --continue und --resume, kombiniere mit einer schlanken CLAUDE.md und einem expliziten HANDOFF.md, das du am Ende jeder grossen Arbeitseinheit bewusst schreiben lässt. Setz cleanupPeriodDays auf einen sinnvoll hohen Wert (nicht 0!), benenn wichtige Sessions, und erwarte nicht, dass --resume über Pfade oder Maschinen hinweg funktioniert.
• Du baust einen API-basierten Agent auf Anthropic: Memory Tool plus Context Editing. Implementiere den Storage-Handler einmal sauber (mit Path-Validation gegen Memory Poisoning), und du hast eine Lösung, die Crashes überlebt.
• Du baust auf OpenAI: Responses API mit store: true, Conversation-Objekt für längere Threads, Response-ID nach jedem Turn lokal persistieren. Nicht zu Threads/Assistants greifen — die werden 2026 abgeschaltet.
• Du baust auf xAI/Grok: Responses API mit Default-store_messages für die Convenience innerhalb von 30 Tagen, aber plan von Anfang an einen Export-Job in deinen eigenen Storage. Nimm den 30-Tage-Cutoff ernst.
• Du baust auf Google: ADK mit DatabaseSessionService oder Vertex AI Sessions für die laufende Konversation, Memory Bank für User-Präferenzen, Context Cache nur für statische grosse Inputs.

Und für alle Lager: Schreib ein Handoff-File. Es ist die billigste, portabelste und zuverlässigste Recovery-Strategie, die existiert. Sie funktioniert, wenn dein Anbieter ausfällt, wenn du das Modell wechselst, wenn deine SDK-Version inkompatibel wird, wenn dein Laptop stirbt. Eine simple Markdown-Datei schlägt jedes proprietäre State-Management, das du nicht selbst kontrollierst.

Der eine Satz, den ich aus der Recherche und Praxis mitnehme: State-Management ist eine Architektur-Entscheidung, kein Feature, das man einschaltet. Die nativen Mechanismen sind nützliche Bausteine — aber die Verantwortung dafür, dass dein Agent morgen früh weiterarbeiten kann, liegt bei dir, nicht bei deinem Anbieter.

Quellen

Alle URLs zuletzt geprüft am 4. Mai 2026.

Allgemein

Anthropic / Claude Code

OpenAI

xAI

Google