Wie setzt Claude Fable 5.2 eine gespeicherte Agentensitzung fort?

11 Min. Lesezeit · 14. November 2026
Zuletzt geprüft 14. November 2026

Ein Agent fragt die Rechnung DEMO-17 ab. Das Buchhaltungssystem liefert 47,50 Euro. Bevor der Agent antwortet, startet ein Deployment den Worker neu. Der Chat steht in deiner Datenbank, die Abfrage gilt im Dashboard als erfolgreich. Kann der nächste Worker den Betrag nennen, ohne die Rechnung noch einmal abzurufen?

Das hängt bei der Claude Messages API davon ab, was deine Anwendung tatsächlich gespeichert hat. Zeigt das Frontend nur sichtbaren Text an, sieht der Chat unter Umständen vollständig aus, obwohl in der Datenbank der ganze Tool-Aufruf fehlt. Ein neuer Worker kann außerdem beim Laden einer alten Sitzung unbemerkt den heutigen System-Prompt einsetzen. In einer Demo, die immer mit einem leeren Chat beginnt, fallen beide Fehler kaum auf.

Stand der Recherche ist der 14. November 2026. Die sechs lokalen Speichertests haben wir mit synthetischen Daten ausgeführt. Die Aussagen zum Modellverhalten stammen aus der Dokumentation von Anthropic. Die Live-Tests für Upgrade und Rollback kannst du auf deiner eigenen Infrastruktur ausführen. Für die Kommandozeile findest du die Modelleinstellungen im Leitfaden zu Fable 5.2 in Claude Code.

Warum scheitert der erste API-Aufruf nach dem Neustart?

Beim Fortsetzen treffen der gespeicherte Sitzungsverlauf und die Konfiguration des neuen Workers aufeinander. Hat sich vor einem gespeicherten Thinking-Block etwas geändert, kann Fable 5.2 die synchrone Anfrage an die direkte Claude API mit HTTP 400 ablehnen. Eine frische Sitzung enthält noch keinen alten Block, an dem dieser Fehler auffallen könnte. Anthropics Migrationsleitfaden für Fable 5.2

Für einen solchen Fehler reicht ein kleiner Texteingriff. Gestern lautete die Tool-Beschreibung „Gespeicherten Rechnungsbetrag abrufen“. Heute steht dort zusätzlich „samt Währung“. Beide Versionen können dieselben Daten liefern. Setzt der Worker beim Laden des alten Verlaufs die neue Beschreibung ein, hat sich der Inhalt vor dem Thinking-Block trotzdem geändert. Auch der dritte Versuch mit derselben Anfrage wird daran scheitern.

Die Präfixprüfung vergleicht eingelesene JSON-Werte. Leerzeichen zwischen JSON-Elementen und die Schlüsselreihenfolge eines Objekts spielen keine Rolle. Die Reihenfolge in einem Array, frühere Nachrichten und Tool-Definitionen zählen. Ein neuer Wert für max_tokens oder effort allein erklärt diesen Fehler also nicht.

Änderst du eine alte Nachricht, sind bereits erzeugte Blöcke hinter dieser Stelle betroffen. Blöcke davor behalten ihr ursprüngliches Präfix. Bei Message Batches gilt für Abweichungen eine andere Voreinstellung. Welche Felder die API bei der Präfixprüfung berücksichtigt

Was muss der Worker von einer Sitzung speichern?

Speichere alles, was der nächste Worker für seinen API-Aufruf braucht, auch wenn sich im Chatfenster nichts tut. Dazu gehören die Systemanweisungen und die geordneten Tool-Definitionen des letzten erfolgreichen Requests, die Nachrichten in ihrer ursprünglichen Reihenfolge, das vollständige content-Array der Assistant-Nachricht sowie alle bereits vorliegenden Tool-Ergebnisse. Anthropics Anleitung zum Speichern und Fortsetzen einer Sitzung

Was der nächste Worker über die Rechnungsabfrage wissen muss
Gespeicherte Daten	Was sich daraus ablesen lässt
Eingaben des ursprünglichen Requests	Für DEMO-17 galten eine bestimmte Systemanweisung und eine bestimmte Tool-Definition. Nach einem Deployment muss der Worker genau diese Versionen laden können.
Assistant-Nachricht	Zuerst kam ein Thinking-Block mit leerer sichtbarer Zusammenfassung, dann die Abfrage mit der ID `toolu_demo_17`. Ein reiner Textexport würde beides verlieren.
Ergebnis und Beleg	Die Anwendung hat für diesen Aufruf 47,50 Euro als Ergebnis gespeichert. Der Worker kann das gespeicherte Ergebnis übergeben und den Betrag in der Antwort mit dem Beleg abgleichen.
Stand des Auftrags	Die Abfrage ist erledigt. Offen ist nur noch die Antwort an den Nutzer.

Übernimm die Felder des Thinking-Blocks wie geliefert in die Assistant-Nachricht. Der Worker braucht die internen Überlegungen weder zu entschlüsseln noch zu protokollieren. Bei einem clientseitigen Tool gehört das tool_result mit der passenden tool_use.id an den Anfang der unmittelbar folgenden User-Nachricht. Dazwischen darf keine weitere Nachricht stehen. Bei parallelen Aufrufen brauchst du für jede ID das zugehörige Ergebnis. Regeln der Claude API für die Rückgabe von Tool-Ergebnissen

Wie prüfst du deinen Sitzungsspeicher ohne API-Zugriff?

Lade vor dem Modellwechsel das Python-Prüfskript für gespeicherte Sitzungen herunter. Python 3 mit seiner Standardbibliothek genügt. Einen API-Schlüssel brauchst du dafür nicht. Rechnung, Tool-ID und Signaturfeld sind frei erfunden. Mit der Signatur im Testdatensatz kann das Skript erkennen, ob dein Speicher ihren Wert erhalten hat.

python3 check_replay.py
python3 check_replay.py --emit-fixture > original.json
# original.json über deine Anwendung speichern und den Worker neu starten.
# Den wieder geladenen Datensatz als restored.json exportieren.
python3 check_replay.py --check-restored restored.json

Unser lokaler Lauf ergab 6/6 expected outcomes. Der intakte Datensatz bestand die Prüfung. Für jeden der fünf manipulierten Datensätze meldete das Skript den erwarteten Fehler. Die Gegenproben decken auch einen Fehler im Prüfskript selbst auf. Akzeptierte es jede Eingabe, fiele es im eigenen Test durch. Gibst du ihm original.json unverändert zurück, prüfst du bloß die Beispieldatei. Für die Freigabe muss der Datensatz denselben Weg wie im Betrieb nehmen, einschließlich Datenbank, Warteschlange, SDK-Konvertierung und erneutem Laden.

Sechs lokale Testfälle mit den beobachteten Ergebnissen
Eingriff in den Testdatensatz	Ausgabe des Prüfskripts	Mögliche Ursache in deiner Anwendung
Intakte Nachricht ohne sichtbaren Assistant-Text	`intact`	Wer leere Sprechblasen ausblendet, muss die Nachricht trotzdem speichern.
Systemanweisung geändert	`changed prefix: system`	Ein Prompt-Alias verweist inzwischen auf eine neue Version.
Tool-Beschreibung geändert	`changed prefix: tools`	Der Schemagenerator übernimmt die aktuell ausgerollte Definition in eine alte Sitzung.
Frühere Anfrage umgeschrieben	`changed prefix: messages`	Die für die Anzeige gekürzte Fassung überschreibt die Originalnachricht.
Reihenfolge der Assistant-Blöcke vertauscht	`changed assistant turn`	Die Datenbank liefert mehrere Zeilen ohne festgelegte Sortierung zurück.
Ergebnis mit falscher ID verknüpft	`unmatched tool result`	Ein gültiger Rechnungsbetrag landet beim falschen Aufruf.

Das Skript vereinheitlicht die Reihenfolge von JSON-Objektschlüsseln, behält die Array-Reihenfolge bei und prüft die Zuordnung zwischen Aufruf und Ergebnis. Für gespeicherte Anwendungsdaten verlangt es bewusst eine strenge Übereinstimmung. Ob Anthropic eine Signatur akzeptiert oder ein Modell einen Block lesen kann, lässt sich erst mit einem echten API-Aufruf klären. Ergänze Fälle aus deinem Betrieb, etwa parallele Aufrufe, deren Ergebnisse in umgekehrter Reihenfolge eintreffen, oder einen Neustart, nachdem das Tool geantwortet hat und bevor dein Worker den Beleg speichern konnte.

Was passiert beim Wechsel von Fable 5.1 auf 5.2 und zurück?

Auf der direkten Claude API kann Fable 5.2 bei gültigem Präfix die Thinking-Blöcke von Fable 5.1 lesen. Umgekehrt kann Fable 5.1 die von 5.2 erzeugten Blöcke nicht lesen. Ein Rollback kann deshalb HTTP 200 liefern, obwohl dem älteren Modell ein Teil der bisherigen Überlegungen fehlt. Deine Anwendung kann den vollständigen Verlauf weiterhin speichern. Wenn die API einen Block für einen einzelnen Aufruf auslässt, ändert das den Datensatz in deiner Datenbank nicht. Thinking-Blöcke beim Modellwechsel

Für neue Rechnungsanfragen kannst du das Modell beim Anlegen der Sitzung wählen. Bei laufenden Vorgängen lohnt es sich, das bisherige Modell an der Sitzung zu hinterlegen und die Arbeit dort abschließen zu lassen, solange der Zugang besteht. Wechselst du mitten im Vorgang, halte Zeitpunkt und Zielmodell fest. Wo sich diese Entscheidung technisch treffen lässt, zeigt der Leitfaden zum Modellrouting.

Scheitert eine alte Sitzung schon an der Präfixprüfung, vergleiche Systemanweisung, Tools und Nachrichten mit dem letzten erfolgreichen Request. Stelle dessen intakten Zustand wieder her, wenn er noch vorliegt. Fehlt das Original, beginne eine neue Sitzung mit belegten Fakten. Für DEMO-17 reichen die Rechnungsnummer, die bestätigten 47,50 Euro und ihr Beleg sowie der Hinweis, dass die Antwort noch aussteht. Kennzeichne die Übergabe als neue Sitzung. Anthropics Fehlerdiagnose für Thinking-Blöcke mit abweichendem Präfix

Welche Live-Tests brauchst du vor dem Rollout?

Nimm ein Testkonto mit demselben API-Zugangsweg, SDK und Speicheradapter wie im geplanten Release. Lass das Modell in diesem Konto für jeden Test echte Blöcke erzeugen. Das Lesetool bekommt eine Rechnung mit bekanntem Betrag. Protokolliere jeden Aufruf und prüfe Betrag und Währung in der Antwort gegen den unabhängig gespeicherten Beleg.

Fünf vorgeschlagene Abnahmetests für die Rechnungsabfrage
Testfall	Durchführung	Abnahme und Nachweis
Neue Sitzung mit 5.2	Führe mit `claude-fable-5-2` eine vollständige Abfrage ohne Neustart aus.	Modell-ID, Request-IDs, Anzahl der Aufrufe, 47,50 Euro in der Antwort, Token-Verbrauch und Laufzeit festhalten.
Neustart mit demselben Modell	Stoppe den Worker nach dem Speichern des Ergebnisses. Lass einen neuen Worker die Sitzung laden und mit 5.2 fortsetzen.	Der Betrag entspricht dem Beleg, das Tool wurde genau einmal aufgerufen. Zusätzliche Lesezugriffe gesondert erfassen.
Von 5.1 auf 5.2	Speichere eine echte 5.1-Nachricht mit Tool-Aufruf und setze sie mit unverändertem Präfix auf 5.2 fort.	Status, zurückgemeldetes Modell und fachliches Ergebnis dokumentieren. Bei einem Fehler die gespeicherten Felder mit dem ausgehenden Request vergleichen.
Von 5.2 auf 5.1	Wiederhole den Wechsel in Gegenrichtung mit einem echten 5.2-Verlauf.	Ergebnis, zusätzliche Aufrufe, Token und Latenz erfassen. Eine korrekte Antwort belegt für sich genommen noch nicht, dass 5.1 die früheren Thinking-Blöcke lesen konnte.
Absichtlich geändertes Präfix	Kopiere eine echte 5.2-Nachricht für diesen Test. Ändere nur die frühere Systemanweisung, behalte den betroffenen Block und sende die Anfrage synchron an die direkte API.	Bei Standardeinstellungen den Präfixfehler und die Reaktion des Workers festhalten. Dafür genügen Feldname und Request-ID, der Gesprächsinhalt gehört nicht ins Fehlerprotokoll.

Beim Beispiel mit der Rechnung ist ein Testfall bestanden, wenn der Betrag samt Währung stimmt, das Tool genau einmal liest und nichts schreibt. Taucht eine falsche Rechnung oder eine doppelt ausgeführte Aktion auf, kläre die Ursache vor dem weiteren Rollout. Richte die Grenzwerte für Kosten und Latenz am bestehenden Serviceziel aus. Werte neue und fortgesetzte Sitzungen getrennt aus. Tausende erfolgreiche neue Anfragen können sonst verdecken, dass jeder Neustart scheitert. Weitere Freigabekriterien stehen in der QA-Checkliste für Releases.

Kann dein Agent auch Rückerstattungen anstoßen, musst du nach einem Timeout den tatsächlichen Buchungsstand klären. Frage das Zielsystem mit einer stabilen Vorgangs-ID für genau diese Rückerstattung ab. Wiederhole den Auftrag erst, wenn feststeht, dass der erste Versuch nicht mehr buchen kann, oder wenn das Zielsystem für dieselbe Vorgangs-ID eine idempotente Wiederholung zusichert. Die Claude-Tool-ID ordnet Nachrichten einander zu. Ob eine Rückerstattung zweimal ausgeführt wird, entscheidet das buchende System. AWS zu idempotenten API-Aufrufen · Praxisbeispiel für einen unklaren Versandstatus

Wann heben Wiederholungen den Preisvorteil von Fable 5.2 auf?

25.000 ungecachte Eingabe-Token und 2.000 Ausgabe-Token kosten zum Standardtarif der direkten API mit Fable 5.1 genau 0,35 US-Dollar. Bei Fable 5.2 sind es 0,28 US-Dollar. Kommt bei gleichem Token-Verbrauch auf vier erfolgreiche Versuche ein zusätzlicher Versuch, ist der Preisvorteil aufgebraucht.

Pro Million Token berechnet Anthropic für Eingabe und Ausgabe 10 bzw. 50 US-Dollar bei 5.1 und 8 bzw. 40 US-Dollar bei 5.2. Das Beispiel setzt gleiche Token-Mengen für jeden Versuch voraus. Cache-, Batch-, Tool- und Infrastrukturkosten sowie menschliche Prüfung sind ausgeklammert. Spezifikation und Preise für Fable 5.2 · Spezifikation und Preise für Fable 5.1

Angenommen, du bekommst mit 5.1 in 20 Versuchen 20 geprüfte Rechnungsantworten. Das kostet 7,00 US-Dollar. Braucht 5.2 wegen Neustarts und Wiederholungen für dieselben 20 Antworten 25 Versuche, zahlst du ebenfalls 7,00 US-Dollar. Mit einem 26. Versuch steigt die Summe auf 7,28 US-Dollar oder 0,364 US-Dollar je abgenommener Antwort. Ersetze diese Beispielwerte im Pilotbetrieb durch deine wirklichen Kosten. Teile die Kosten aller Versuche, einschließlich der erfolglosen, durch die Zahl der fachlich geprüften und akzeptierten Ergebnisse.

Für die Freigabe brauchst du drei Antworten. Hat dein Speicher die Nachricht vollständig erhalten? Hat das Modell den richtigen Betrag nach genau einer Abfrage geliefert? Was hat dieses abgenommene Ergebnis gekostet? Wenn du solche Tests regelmäßig für die eigenen Abläufe durchführen willst, findest du unseren Ansatz bei KI-Evaluation und LLMOps. Abnahmetests für deinen Agenten besprechen.

Die Fallstudie zu Twinsoft AI zeigt, wie aus einem Prototyp ein Produkt für einen Pilotbetrieb im Unternehmen wurde.

Häufige Fragen zu gespeicherten Fable-5.2-Sitzungen

Reicht ein Screenshot oder Chat-Export, um eine Sitzung wiederherzustellen?

Ein Export fürs Lesen enthält meist nur den sichtbaren Text. Prüfe, ob er das vollständige Content-Array der Assistant-Nachricht, die damaligen System- und Tool-Definitionen, alle Nachrichten in der richtigen Reihenfolge und die Ergebnis-IDs enthält. Fehlt etwas, übernimm die nachprüfbaren Fakten in eine neue Sitzung und kennzeichne die Übergabe.

Bedeutet HTTP 400 immer, dass sich das Präfix geändert hat?

Lies die Fehlermeldung und sichere die Request-ID. Auch ungültige Nachrichten oder ein Ergebnis mit falscher Tool-ID können an der Validierung scheitern. Vergleiche die gespeicherte Struktur Feld für Feld mit dem ausgehenden Request. Eine Wiederholung mit denselben fehlerhaften Daten behebt die Ursache nicht.

Kann ich die Signatur aus dem Download an Claude senden?

Verwende das Beispiel lokal. Die künstliche Signatur ist ein Platzhalter, an dem das Skript Veränderungen erkennt. Für einen Live-Test brauchst du eine echte Assistant-Nachricht, die dein Anbieter über denselben Zugangsweg in deinem Testkonto geliefert hat. Speichere echte signierte Blöcke nur dort, wo dein System sie verarbeiten darf.

Was mache ich, wenn die Assistant-Nachricht keinen Text enthält?

Prüfe den Stop-Grund und alle Inhaltsblöcke. Ein Tool-Aufruf kann auf sein Ergebnis warten, obwohl nichts im Chat erscheint. Auch das Ausgabe-Limit kann erreicht sein, bevor sichtbarer Text entsteht. Speichere die zurückgegebene Nachricht und behandle den tatsächlichen Stop-Grund, bevor du den Auftrag als erledigt markierst.

Brauchen Regressionstests echte Kundengespräche?

Starte mit synthetischen Rechnungen und reproduzierbaren Tool-Ergebnissen. So kann das Team denselben Fehler ohne Kundendaten nachstellen. Wenn sich im Betrieb ein neues Speichermuster als fehleranfällig erweist, ergänze ein möglichst kleines künstliches Beispiel, das genau diesen Fehler auslöst.

Gilt der lokale Test auch für Bedrock oder Message Batches?

Lokal prüfst du die Daten in deinem Speicher. Führe für jeden Anbieter und jeden Verarbeitungsmodus, den du einsetzt, einen eigenen Abnahmetest durch. Die hier beschriebenen Live-Fälle setzen synchrone Anfragen an die direkte Claude API voraus. Bei einem Batch-Eintrag können abweichende Blöcke in der Standardeinstellung entfallen.