Claude Fable 5.1 Preserved Thinking: Der Block ist an eine andere Konversation gebunden beheben

Wenn Sie ein Agent-Harness auf Claude Fable 5.1 umgestellt haben und einen 400er-Fehler mit der Meldung erhalten, dass ein Thinking-Block „an eine andere Konversation gebunden ist“, dann bearbeitet Ihr Code den Konversationsverlauf zwischen Anfragen, und Fable 5.1 ist das erste Claude-Modell, das dies beanstandet. Dieser Leitfaden erklärt, was diese Überprüfung ist, für wen sie gilt, was sie genau auslöst, den Notausgang und die append-only Muster, die den Fehler beseitigen und gleichzeitig Ihren Prompt-Cache warm halten.

Die Überprüfung ist unter preserved thinking und in What’s new in Claude Fable 5.1 dokumentiert. Es ist die dritte von drei grundlegenden Änderungen in Fable 5.1 und die einzige, die ein Harness unbemerkt beeinträchtigen kann. Die anderen beiden finden Sie im Migrationsleitfaden.

Schaltfläche

Der Fehler

messages.5.content.0: Ungültige `signature` im `thinking` Block. Der Block ist an eine andere Konversation gebunden. Entfernen Sie den Block oder setzen Sie `thinking.block_binding.prefix_mismatch_behavior` auf "drop_block". Diese Einstellung erfordert den Wert `thinking-binding-controls-2026-08-01` im `anthropic-beta` Header.

Es handelt sich um einen 400er invalid_request_error, der vor jeglicher Ausgabe entschieden wird. Ein erneuter Versuch mit demselben Body schlägt auf die gleiche Weise fehl. Der Pfad (`messages.5.content.0`) verweist auf den ersten Thinking-Block, der nicht mehr übereinstimmt, und die Meldung kann mit einem weiteren Satz enden, der die erste geänderte Nachricht benennt, was die gewünschte Diagnose ist. Der Token-Zähl-Endpunkt führt dieselbe Überprüfung durch.

Ein anderer Fehler sieht ähnlich aus, ist aber nicht dieser: Die gleiche einleitende Klausel ohne den Satz „an eine andere Konversation gebunden“ bedeutet, dass die Signatur selbst manipuliert oder unentschlüsselbar ist, und `prefix_mismatch_behavior` nicht zutrifft.

Was die Überprüfung tut

Jeder Fable 5.1 Thinking-Block trägt eine Signatur, die zwei Dinge aufzeichnet: welches Modell ihn produziert hat und das genaue Konversationspräfix, das ihm vorausging, d.h. der Top-Level-system-Prompt, das tools-Array und jede Nachricht vor dem Block. Jeder Block verknüpft sich auch mit dem vorherigen Thinking-Block. Wenn Sie das Transkript zurücksenden, überprüft die API, ob dieses Präfix byte-identisch mit dem ist, was den Block produziert hat.

Anthropic nennt zwei Gründe. Der angegebene ist Anti-Destillation: Der Launch-Post besagt, dass neue API-Konten Claudes früheren Kontext in einer Multi-Turn-Konversation nicht mehr manuell bearbeiten können, während das Transkript des früheren Denkens erhalten bleibt, was eine dokumentierte Destillationstechnik ausschließt. Der praktische Grund ist, dass die gleichen Bearbeitungen, die die Überprüfung unterbrechen, auch den Prompt-Cache neu starten, sodass Code, der die Überprüfung besteht, auch Code ist, der bei jeder Runde 0,25 $ pro Million Cache-Reads erhält.

Für wen es gilt

Standardmäßig erzwungen: Konten, die am oder nach dem 31. August 2026 erstellt wurden. Das umfasst Claude API-Organisationen, Amazon Bedrock-Konten, Google Cloud-Projekte und Microsoft Foundry-Ressourcen.
Aufgezeichnet, aber nicht erzwungen: Konten, die früher erstellt wurden. Die API registriert die Abweichung, handelt aber nur, wenn die Anfrage thinking.block_binding.prefix_mismatch_behavior auf einen beliebigen Wert setzt, einschließlich "error". Anthropic sagt, zukünftige Modelle werden es für alle erzwingen.
Nicht betroffen: Claude Code, claude.ai, Claude Managed Agents und das Claude Agent SDK, die das Präfix für Sie intakt halten. Claude Mythos 5.1 führt die Überprüfung überhaupt nicht durch, obwohl Historienbearbeitungen immer noch seinen Cache neu starten.
Betroffen: jeder Code, der das messages-Array selbst aufbaut. Das ist jede benutzerdefinierte Agenten-Schleife, jedes Chat-Backend und jedes Framework, das die Messages API umschließt.

Die Falle für Tool-Autoren: Wenn Sie etwas liefern, das Leute mit ihren eigenen API-Schlüsseln ausführen, befindet sich Ihr Schlüssel wahrscheinlich auf einem älteren Konto, und ihrer möglicherweise nicht. Testen Sie mit dem gesetzten Feld, damit Sie die Überprüfung treffen, bevor Ihre Benutzer dies tun. Um herauszufinden, ob Ihr eigenes Konto erzwungen wird, senden Sie eine Anfrage, die den Verlauf ohne den Beta-Header bearbeitet; ein 400er, der den Header benennt, bedeutet, dass dies der Fall ist.

Was jeden späteren Thinking-Block ungültig macht

Bearbeiten, Neuordnen oder Entfernen einer früheren Runde. Dazu gehört das Löschen alter Tool-Ergebnisse, das Herausschneiden von Runden aus der Mitte des Transkripts und die clientseitige Verdichtung, die die letzten Runden wörtlich hinter einer Zusammenfassung beibehält.
Einfügen von Inhalten, die Sie nicht persistieren. Eine pro-Runden-Erinnerung, die nach den Tool-Ergebnissen angehängt und bei der nächsten Anfrage entfernt wird. Eine Statuszeile. Eine verbleibende Token-Anzahl, die sich jede Runde ändert.
Neuerstellung von system oder tools zwischen Anfragen. Aktualisieren des aktuellen Datums im System-Prompt. Hinzufügen oder Entfernen eines Tools mitten in der Sitzung.
Eine Bild- oder Dokument-URL, die später andere Bytes liefert. Die Bytes sind gebunden, nicht die URL-Zeichenkette, daher ist eine rotierende signierte URL für dieselbe Datei in Ordnung.
Entfernen eines Thinking-Blocks von einer anderen Stelle als dem Start des Laufs. Führende Blöcke können entfernt werden, beginnend mit dem ältesten. Ein Block aus der Mitte kann nicht entfernt werden.

Was sie gültig hält

Append-only Historien, einschließlich angehängter role: "system" Nachrichten und gelöschter rundenbasierter Nachrichten, die an Ort und Stelle belassen wurden.
Entfernen einer führenden Sequenz von Thinking-Blöcken, die ältesten zuerst.
Ändern beliebiger Parameter außerhalb von system, tools und messages: max_tokens, output_config einschließlich effort, tool_choice, metadata.
Hinzufügen, Verschieben oder Entfernen von cache_control Markierungen.
Serverseitige Verdichtung und Kontextbearbeitung, einschließlich des Löschens von Thinking-Blöcken. Diese zählen nicht als Bearbeitungen, da die Überprüfung die Konversation so vergleicht, wie Sie sie gesendet haben, nicht die bearbeitete Kopie des Servers. Nach einer Verdichtung beginnt das überprüfte Präfix mit dem Verdichtungsblock.

Der Notausgang: drop_block

Senden Sie den thinking-binding-controls-2026-08-01 Beta-Header und setzen Sie das Feld explizit:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={"type": "adaptive", "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)
for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

Mit "drop_block" verwirft die API den ersten nicht übereinstimmenden Block und jeden Thinking-Block danach, fährt mit der Anfrage fort und meldet jedes Verwerfen in einem Top-Level-input_transformations-Array:

"input_transformations": [
  {"type": "thinking_dropped", "path": "messages.1.content.0", "reason": "prefix_binding_mismatch"}
]

Drei Dinge, die Sie über das Feld wissen sollten. Es gilt nur für diese Anfrage, senden Sie es also für den Rest der Sitzung. Die Standardwerte unterscheiden sich je nach Oberfläche: Ohne den Header führt ein erzwungenes Konto zu Fehlern; das alleinige Senden des Headers wechselt zum eigenen Standard der Beta, der drop_block ist; setzen Sie es also explizit und verlassen Sie sich niemals auf einen der Standardwerte. Und das Senden von block_binding ohne den Header führt zu einem 400er, der mit block_binding: Extra inputs are not permitted endet.

Das reason-Feld unterscheidet zwei Fälle. prefix_binding_mismatch bedeutet, dass Ihr Verlauf geändert wurde. model_binding_mismatch bedeutet, dass die Konversation Modelle gewechselt hat (ein Router, ein erneuter Versuch, ein Verweigerungs-Fallback) und das Ziel keinen Fable 5.1-Block lesen konnte. Letzteres ist kein Fehler in Ihrem Code. Mit dem Header enthält jede Antwort das Array, leer wenn nichts verworfen wurde.

Blöcke einmal, an einer Verdichtungsgrenze, zu verwerfen, kostet wenig. Ein Harness, der seinen eigenen Verlauf bei jeder Anfrage ungültig macht, verliert die Argumentation des Modells in jeder Runde und startet den Prompt-Cache in jeder Runde neu, und Anthropic warnt, dass dies die Kosten pro Aufgabe erhöht. Behandeln Sie drop_block als Diagnose- und Sicherheitsnetz, nicht als Dauerzustand.

Die Beta-freie Wiederherstellung

Auf einer Plattform ohne die Kontrollen (Microsoft Foundry bot sie zum Start nicht an; Bedrock und Google Cloud fügten sie modellweise hinzu), entfernen Sie jeden thinking und redacted_thinking Block aus dem Verlauf, behalten Sie die text und tool_use Blöcke jeder Runde bei und versuchen Sie es einmal erneut. Das Modell beantwortet diese Runde ohne die Argumentation, die diese Blöcke enthielten. Dies ist eine einmalige Wiederherstellung, kein Muster.

Das Drei-Schritte-Audit

Erfassen Sie die genauen Anforderungs-Bodies, die Ihr Harness über einige normale Runden sendet, einschließlich einer Verdichtung oder einer Tool-Änderung, falls Ihr Produkt diese besitzt. Für jedes Paar aufeinanderfolgender Anfragen vergleichen Sie den system-Prompt, das tools-Array und das gemeinsame Präfix von messages. Sie sollten bis zu den neu angehängten Runden byte-identisch sein.
Führen Sie eine normale Multi-Turn-Sitzung gegen claude-fable-5-1 mit dem Beta-Header und prefix_mismatch_behavior: "drop_block" aus und protokollieren Sie input_transformations bei jeder Antwort. Ein leeres Array in jeder Runde bedeutet, dass der Verlauf intakt ist. Ein prefix_binding_mismatch-Eintrag bedeutet, dass sich etwas vor dem Block am path geändert hat. Dies funktioniert von jedem Konto aus, da das Setzen des Feldes die Anfrage zur Erzwingung optiert. In CI setzen Sie stattdessen "error", damit eine Bearbeitung den Lauf fehlschlagen lässt.
Wählen Sie eine Produktionseinstellung und setzen Sie diese explizit unter dem Header: "error", wenn eine Nichtübereinstimmung nur einen Fehler bedeuten kann, "drop_block", um herabzustufen, anstatt fehlzuschlagen. Überwachen Sie die 400er oder die input_transformations-Einträge in jedem Fall. Lassen Sie das Feld auf einem älteren Konto nicht ungesetzt, da die Überprüfung dann nur serverseitig aufgezeichnet wird und Sie nichts zu überwachen haben.

In Apidog ist Schritt 2 ein Zwei-Anfragen-Test: Senden Sie eine Runde, bearbeiten Sie den System-Prompt, senden Sie die nächste Runde mit dem gesetzten Header und prüfen Sie auf input_transformations. Behalten Sie es in der Sammlung, damit jede Harness-Änderung es erneut ausführt. Laden Sie Apidog herunter, um es zu erstellen.

Ein Harness append-only machen

Jede Zeile ersetzt eine Historienbearbeitung durch etwas, das das Präfix intakt hält und den Cache warm hält.

Sie haben dies getan	Tun Sie dies stattdessen
Bearbeiten des System-Prompts mitten in der Sitzung (neues Datum, neuer Modus)	Frieren Sie `system` zu Sitzungsbeginn ein. Hängen Sie `{"role": "system", "content": "The current date is 2026-09-14."}` an dem Punkt an, an dem die Änderung wirksam wird (Systemnachrichten mitten in der Konversation). Kein Beta-Header; es erhält System-Prompt-Autorität und wird Teil des Präfixes, an das spätere Blöcke gebunden sind.
Bearbeiten des `tools`-Arrays mitten in der Sitzung	Deklarieren Sie den vollständigen Satz zu Sitzungsbeginn (`defer_loading: true` bei denen, die ausgeblendet beginnen). Senden Sie `tool_addition` und `tool_removal` Blöcke in einer `role: "system"` Nachricht (Beta `mid-conversation-tool-changes-2026-07-01`).
Einfügen einer rundenbezogenen Erinnerung und Löschen bei der nächsten Anfrage	Senden Sie sie als rundenbezogene Systemnachricht: `{"role": "system", "clear_at": "next_user_message", "content": "..."}` (Beta `mid-conversation-system-clear-at-2026-08-21`) nach der Tool-Ergebnisnachricht, und belassen Sie jede frühere Kopie an Ort und Stelle. Gelöschte Kopien rendern nichts und kosten nichts. Ohne die Beta, platzieren Sie die Erinnerung in einem Textblock nach den `tool_result`-Blöcken in derselben Benutzernachricht, wobei frühere Kopien beibehalten werden.
Löschen alter Tool-Ergebnisse clientseitig	Serverseitige Kontextbearbeitung mit Tool-Ergebnis-Löschung.
Clientseitige Verdichtung	Bevorzugen Sie die serverseitige Verdichtung (Beta `compact-2026-01-12`; ihr `instructions`-Parameter nimmt Ihren eigenen Zusammenfassungs-Prompt). Wenn Sie clientseitig bleiben, verwenden Sie einfache Verdichtung: Ersetzen Sie den gesamten Verlauf durch eine Zusammenfassungsnachricht plus die neue Benutzerrunde und spielen Sie nichts anderes ab.
Referenzieren eines Bildes oder Dokuments per URL über mehrere Runden hinweg	Einmal in die Files API hochladen und die `file_id` senden, oder base64 senden.

Zwei clientseitige Verdichtungsformen brechen unter der Überprüfung und erfordern drop_block oder entfernte Thinking-Blöcke bei den beibehaltenen Runden. Keep-tail Verdichtung (ältere Runden zusammenfassen, die neuesten wörtlich beibehalten) scheitert bei den beibehaltenen Runden, da ihr Thinking gegen den vollständigen Verlauf produziert wurde. Hintergrund-Verdichtung (die Zusammenfassung außerhalb des kritischen Pfades erstellen und später einfügen) scheitert bei jeder Runde, die zwischen dem Start der Zusammenfassung und dem Einfügen produziert wurde. Das Herausschneiden einzelner Runden aus der Mitte des Transkripts macht jeden späteren Block ungültig, und keine clientseitige Form vermeidet dies. Verwenden Sie eine Systemnachricht mitten in der Konversation für die Anweisungsänderung, die Sie vorgenommen haben, oder serverseitige Kontextbearbeitung für selektives Entfernen.

Eine weitere Kostenüberlegung: Da Cache-Reads jetzt 0,25 $ pro Million kosten, ist das frühzeitige Kompaktieren zur Kosteneinsparung bei Fable 5.1 möglicherweise nicht mehr der richtige Kompromiss. Anthropic schlägt vor, mit späteren Kompaktierungspunkten zu experimentieren.

Warum dies auch die Cache-Geschichte ist

Alles in der obigen Tabelle ist auch die Liste der Dinge, die einen Prompt-Cache neu starten. Fable 5.1 machte Cache-Hits viermal billiger als Fable 5 und machte Misses proportional schmerzhafter, sodass ein append-only Harness doppelt belohnt wird: Das Thinking überlebt, und jede Runde liest das Präfix für 0,25 $ anstatt es für 12,50 $ neu zu schreiben. Die Preisübersicht enthält die Zahlen; die API-Anleitung zeigt die rundenbezogenen und pro-Nachricht-Aufwandsanfrageformen im Kontext, der Prompting-Leitfaden behandelt, welche rundenbezogenen Anweisungen es wert sind, auf diese Weise gesendet zu werden, und der Claude Code-Leitfaden erklärt, warum Claude Code-Benutzer diesen Fehler nie sehen.

FAQ

Was bedeutet „Der Block ist an eine andere Konversation gebunden“? Ein Claude Fable 5.1 Thinking-Block wurde wiedergegeben, nachdem sich etwas davor geändert hatte: der System-Prompt, das Tool-Array oder eine frühere Nachricht. Die API lehnt die Anfrage mit einem 400er bei erzwungenen Konten ab.

Welche Konten erzwingen die Fable 5.1 Historienprüfung? Konten, die am oder nach dem 31. August 2026 erstellt wurden, auf jeder Plattform. Ältere Konten erzwingen sie nur, wenn eine Anfrage thinking.block_binding.prefix_mismatch_behavior setzt. Anthropic plant, sie für alle zukünftigen Modelle zu erzwingen.

Wie behebe ich den Fehler schnell? Senden Sie den thinking-binding-controls-2026-08-01 Beta-Header mit prefix_mismatch_behavior: "drop_block". Die API verwirft die betroffenen Blöcke und fährt fort. Beheben Sie dann die Historienbearbeitung, da das Verwerfen von Blöcken in jeder Runde die Argumentation kostet und Ihren Cache neu startet.

Führt eine Änderung von Effort oder max_tokens dazu, dass Thinking-Blöcke ungültig werden? Nein. Jeder Parameter außerhalb von system, tools und messages kann frei geändert werden, ebenso wie cache_control Markierungen.

Bricht die serverseitige Verdichtung die Überprüfung? Nein. Verdichtung und Kontextbearbeitung erfolgen nach der Überprüfung, die die Konversation so vergleicht, wie Sie sie gesendet haben. Clientseitige Verdichtung, die die letzten Runden wörtlich beibehält, bricht sie jedoch.

Hat Claude Mythos 5.1 die gleiche Überprüfung? Nein. Mythos 5.1 führt die Konversationsprüfung nicht durch, obwohl es Thinking-Blöcke immer noch an das produzierende Modell bindet und Historienbearbeitungen immer noch seinen Cache neu starten.