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 und What’s new in Claude 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.
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 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, 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_: 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 enthält die aktuellen Zahlen. Die API-Anleitung zeigt rundenbezogene und pro-Nachricht-Aufwandsanfragen. Der Prompting-Leitfaden erklärt, welche rundenbezogenen Anweisungen sich für dieses Muster eignen. Der Claude-Code-Leitfaden 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.