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

Anthropic's Claude Fable 5.1 introduces a new validation that rejects requests when a preserved thinking block is bound to a different conversation, causing a 400 error. Developers must ensure their code does not modify the conversation history between requests, and can use the 'prefix_mismatch_behavior' setting to handle mismatches. The check is part of three fundamental changes in Fable 5.1 and may be enforced for all accounts in the future.

Wenn Sie einen Agent-Harness auf Claude Fable 5.1 umgestellt haben und einen 400er-Fehler erhalten, wonach ein Thinking-Block „an eine andere Konversation gebunden ist“, verändert Ihr Code den Konversationsverlauf zwischen zwei Anfragen. Fable 5.1 ist das erste Claude-Modell, das diese Änderung beanstandet. Dieser Leitfaden zeigt, wie die Prüfung funktioniert, wen sie betrifft, was sie auslöst und wie Sie mit append-only-Mustern sowohl den Fehler als auch unnötige Prompt-Cache-Misses vermeiden. Die Prüfung ist in preserved thinking https://platform.claude.com/docs/en/build-with-claude/preserved-thinking und What’s new in Claude Fable 5.1 https://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1 dokumentiert. Sie ist die dritte von drei grundlegenden Änderungen in Fable 5.1 und die einzige, die einen eigenen Harness unbemerkt beeinträchtigen kann. Die anderen beiden Änderungen beschreibt der Migrationsleitfaden https://apidog.com/de/blog/claude-fable-5-1-migration?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation . 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 400 invalid request error , der vor jeder Ausgabe entsteht. Ein erneuter Versuch mit demselben Request-Body schlägt ebenfalls fehl. Der Pfad messages.5.content.0 verweist auf den ersten Thinking-Block, der nicht mehr zum gesendeten Verlauf passt. Die Fehlermeldung kann zusätzlich die erste geänderte Nachricht nennen – genau diese Information ist für die Diagnose hilfreich. Der Token-Zähl-Endpunkt führt dieselbe Prüfung durch. Ein ähnlicher, aber anderer Fehler enthält nicht den Satz „an eine andere Konversation gebunden“. Dann wurde die Signatur selbst manipuliert oder ist nicht entschlüsselbar; prefix mismatch behavior hilft in diesem Fall nicht. Jeder Thinking-Block von Fable 5.1 enthält eine Signatur. Sie zeichnet zwei Dinge auf: Zum Präfix gehören: system -Prompt, tools -Array,Jeder Block ist außerdem mit dem vorherigen Thinking-Block verknüpft. Wenn Sie den Verlauf erneut senden, prüft die API, ob das Präfix bytegenau dem Präfix entspricht, mit dem der Block erzeugt wurde. Anthropic nennt dafür zwei Gründe: thinking.block binding.prefix mismatch behavior auf irgendeinen Wert setzt – auch auf "error" . Laut Anthropic werden zukünftige Modelle die Prüfung für alle Konten erzwingen. messages -Array selbst aufbaut – etwa eigene Agentenschleifen, Chat-Backends oder Frameworks, die die Messages API kapseln.Wenn Sie ein Tool veröffentlichen, das Nutzer mit eigenen API-Schlüsseln ausführen, liegt Ihr Schlüssel möglicherweise auf einem älteren Konto, der Schlüssel Ihrer Nutzer aber nicht. Testen Sie deshalb mit gesetztem prefix mismatch behavior , damit Sie die Prüfung bereits während der Entwicklung auslösen. Um festzustellen, ob Ihr eigenes Konto die Prüfung erzwingt, bearbeiten Sie den Verlauf ohne Beta-Header. Ein 400er, der den Header thinking-binding-controls-2026-08-01 nennt, zeigt an, dass die Prüfung erzwungen wird. Jede Änderung vor einem bereits erzeugten Thinking-Block kann alle nachfolgenden Blöcke ungültig machen: system oder tools zwischen Requests neu erzeugen, etwa durch ein aktualisiertes Datum im System-Prompt oder durch das Hinzufügen beziehungsweise Entfernen eines Tools.Folgende Änderungen erhalten die Bindung: role: "system" -Nachrichten; system , tools und messages , etwa max tokens , output config einschließlich effort , tool choice und metadata ; cache control -Markierungen;Serverseitige Bearbeitung zählt nicht als clientseitige Änderung, weil die Prüfung den Verlauf so vergleicht, wie Sie ihn senden – nicht die intern bearbeitete Kopie des Servers. Nach einer Verdichtung beginnt das geprüfte Präfix mit dem Verdichtungsblock. drop block Wenn Sie den Verlauf nicht sofort reparieren können, senden Sie den Beta-Header und setzen Sie das Verhalten 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 Thinking-Block und alle danach folgenden Thinking-Blöcke. Anschließend verarbeitet sie den Request weiter und meldet jede Verwerfung in input transformations : { "input transformations": { "type": "thinking dropped", "path": "messages.1.content.0", "reason": "prefix binding mismatch" } } Beachten Sie drei Details: drop block verwendet. Setzen Sie den Wert deshalb immer explizit. block binding ohne den erforderlichen Header führt zu einem 400er mit block binding: Extra inputs are not permitted .Das Feld reason unterscheidet zwei Ursachen: prefix binding mismatch : Der Verlauf wurde geändert. model binding mismatch : Die Konversation wechselte das Modell, etwa durch einen Router, einen erneuten Versuch oder einen Fallback nach einer Verweigerung. Das ist kein Fehler in Ihrem Verlaufscode.Mit gesetztem Header enthält jede Antwort ein input transformations -Array. Es ist leer, wenn nichts verworfen wurde. Ein einzelnes Verwerfen an einer Verdichtungsgrenze ist meist unproblematisch. Ein Harness, das seinen Verlauf bei jeder Anfrage ungültig macht, verliert jedoch in jeder Runde das Thinking des Modells und startet den Prompt-Cache immer wieder neu. Anthropic warnt, dass dadurch die Kosten pro Aufgabe steigen. Verwenden Sie drop block daher als Diagnose- und Sicherheitsnetz, nicht als dauerhafte Lösung. Auf Plattformen ohne diese Kontrollen – Microsoft Foundry bot sie zum Start nicht an; Bedrock und Google Cloud führten sie modellweise ein – können Sie einmalig alle thinking - und redacted thinking -Blöcke aus dem Verlauf entfernen. Behalten Sie die text - und tool use -Blöcke jeder Runde bei und senden Sie den Request erneut. Das Modell beantwortet die Runde dann ohne die zuvor enthaltene Argumentation. Das ist eine einmalige Wiederherstellung, kein dauerhaftes Muster. Protokollieren Sie die exakten Request-Bodies, die Ihr Harness über mehrere normale Runden sendet. Nehmen Sie auch eine Verdichtung oder Tool-Änderung auf, falls Ihr Produkt diese Funktionen besitzt. Vergleichen Sie für jedes aufeinanderfolgende Request-Paar: system -Prompt; tools -Array; messages .Bis zu den neu angehängten Runden müssen diese Bereiche byteidentisch sein. drop block testen Führen Sie eine normale Multi-Turn-Sitzung gegen claude-fable-5-1 aus und setzen Sie: anthropic-beta: thinking-binding-controls-2026-08-01 thinking.block binding.prefix mismatch behavior: "drop block" Protokollieren Sie input transformations bei jeder Antwort. reason: "prefix binding mismatch" zeigt, dass sich etwas vor dem Block am angegebenen Pfad verändert hat.Dieser Test funktioniert für jedes Konto, weil das gesetzte Feld die Prüfung aktiviert. In CI sollten Sie stattdessen "error" verwenden, damit jede unbeabsichtigte Bearbeitung den Lauf fehlschlagen lässt. Setzen Sie die Einstellung unter dem Beta-Header explizit: "error" , wenn eine Nichtübereinstimmung immer einen Fehler darstellen soll; "drop block" , wenn der Request mit reduziertem Kontext weiterlaufen soll.Überwachen Sie in beiden Fällen die 400er oder die Einträge in input transformations . Lassen Sie das Feld auf älteren Konten nicht ungesetzt: Dort wird die Abweichung sonst möglicherweise nur serverseitig aufgezeichnet, ohne dass Ihr Monitoring sie sieht. In Apidog https://apidog.com/?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation besteht der Test aus zwei Requests: input transformations .Behalten Sie den Test in Ihrer Sammlung, damit jede Änderung am Harness erneut geprüft werden kann. Laden Sie Apidog herunter https://apidog.com/download?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation , um den Test zu erstellen. Ersetzen Sie jede Historienbearbeitung durch ein Muster, das das Präfix unverändert lässt: | Bisher | Stattdessen | |---|---| | System-Prompt mitten in der Sitzung bearbeiten, etwa durch ein neues Datum oder einen neuen Modus | system zu Sitzungsbeginn einfrieren. Die Änderung als neue Nachricht anhängen: {"role": "system", "content": "The current date is 2026-09-14."} . Systemnachrichten mitten in der Konversation erhalten System-Prompt-Autorität und werden Teil des Präfixes. | tools -Array mitten in der Sitzung bearbeiten | Den vollständigen Satz zu Sitzungsbeginn deklarieren. Tools, die zunächst ausgeblendet sein sollen, mit defer loading: true konfigurieren. Änderungen als tool addition - und tool removal -Blöcke in einer role: "system" -Nachricht senden; dafür gilt der Beta-Header mid-conversation-tool-changes-2026-07-01 . | | Eine rundenbezogene Erinnerung einfügen und beim nächsten Request löschen | Als Systemnachricht mit clear at: "next user message" senden: {"role": "system", "clear at": "next user message", "content": "..."} . Nach der Tool-Ergebnisnachricht einfügen und frühere Kopien an Ort und Stelle belassen. Gelöschte Kopien werden nicht gerendert und kosten nichts. Ohne Beta-Header die Erinnerung in einem Textblock nach den tool result -Blöcken derselben Benutzernachricht platzieren und frühere Kopien behalten. | | Alte Tool-Ergebnisse clientseitig löschen | Serverseitige Kontextbearbeitung mit Tool-Ergebnis-Löschung verwenden. | | Clientseitige Verdichtung mit einem erhaltenen Verlaufsschwanz | Serverseitige Verdichtung bevorzugen: compact-2026-01-12 ; der Parameter instructions akzeptiert einen eigenen Zusammenfassungs-Prompt. Wenn clientseitige Verdichtung unvermeidbar ist, den gesamten Verlauf durch eine Zusammenfassungsnachricht plus die neue Benutzerrunde ersetzen und nichts anderes wiedergeben. | | Ein Bild oder Dokument über eine URL über mehrere Runden referenzieren | Einmal in die Files API hochladen und die file id verwenden oder die Daten als Base64 senden. | Zwei Varianten brechen unter der Prüfung: Auch das Herausschneiden einzelner mittlerer Runden macht jeden späteren Thinking-Block ungültig. Verwenden Sie für Anweisungsänderungen Systemnachrichten mitten in der Konversation und für selektives Entfernen serverseitige Kontextbearbeitung. Eine weitere Kostenüberlegung: Cache-Reads kosten bei Fable 5.1 nur noch 0,25 US-Dollar pro Million Tokens. Frühes Kompaktieren zur Kostensenkung ist deshalb möglicherweise nicht mehr der beste Kompromiss. Anthropic empfiehlt, mit späteren Verdichtungspunkten zu experimentieren. Alle Änderungen in der Tabelle können einen Prompt-Cache neu starten. Fable 5.1 macht Cache-Hits viermal günstiger als Fable 5 und macht Cache-Misses proportional teurer. Ein append-only-Harness wird daher doppelt belohnt: Die Preisübersicht https://apidog.com/de/blog/claude-fable-5-1-pricing?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation enthält die aktuellen Zahlen. Die API-Anleitung https://apidog.com/de/blog/claude-fable-5-1-api?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation zeigt rundenbezogene und pro-Nachricht-Aufwandsanfragen. Der Prompting-Leitfaden https://apidog.com/de/blog/prompting-claude-fable-5-1?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation erklärt, welche rundenbezogenen Anweisungen sich für dieses Muster eignen. Der Claude-Code-Leitfaden https://apidog.com/de/blog/claude-fable-5-1-claude-code?utm source=dev.to&utm medium=wanda&utm content=n8n-post-automation erläutert, warum Claude-Code-Nutzer diesen Fehler nicht sehen. Ein Thinking-Block von Claude Fable 5.1 wurde erneut gesendet, nachdem sich etwas davor geändert hat: der System-Prompt, das Tool-Array oder eine frühere Nachricht. Auf Konten, die die Prüfung erzwingen, lehnt die API den Request mit einem 400er ab. Konten, die am oder nach dem 31. August 2026 erstellt wurden – auf jeder unterstützten Plattform. Ältere Konten erzwingen sie nur, wenn der Request thinking.block binding.prefix mismatch behavior setzt. Anthropic plant, die Prüfung für zukünftige Modelle auf alle Konten auszuweiten. Senden Sie den Beta-Header thinking-binding-controls-2026-08-01 und setzen Sie prefix mismatch behavior auf "drop block" . Die API verwirft die betroffenen Blöcke und verarbeitet den Request weiter. Reparieren Sie anschließend die Historienbearbeitung, da das dauerhafte Verwerfen von Blöcken die Argumentation kostet und den Cache neu startet. effort oder max tokens Thinking-Blöcke ungültig? Nein. Parameter außerhalb von system , tools und messages können frei geändert werden. Das gilt auch für cache control -Markierungen. Nein. Verdichtung und Kontextbearbeitung erfolgen nach der Prüfung, die den von Ihnen gesendeten Verlauf vergleicht. Eine clientseitige Verdichtung, die die letzten Runden wörtlich beibehält, bricht die Prüfung dagegen. Nein. Mythos 5.1 prüft die Konversation nicht auf diese Weise. Thinking-Blöcke bleiben jedoch weiterhin an das produzierende Modell gebunden, und Änderungen am Verlauf starten auch dort den Cache neu.