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

Claude Fable 5.1: Thinking-Block-Fehler in eigenen Agent-Harnesses beheben

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.

Jetzt Apidog ausprobieren

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.

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 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.

Was die Prüfung kontrolliert

Jeder Thinking-Block von Fable 5.1 enthält eine Signatur. Sie zeichnet zwei Dinge auf:

1. das Modell, das den Block erzeugt hat;
2. das exakte Konversationspräfix vor dem Block.

Zum Präfix gehören:

• der Top-Level-system-Prompt,
• das tools-Array,
• jede Nachricht vor dem Thinking-Block.

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:

• Anti-Destillation: Der Launch-Post beschreibt, dass neue API-Konten Claudes früheren Kontext in einer Multi-Turn-Konversation nicht mehr manuell bearbeiten können, während das frühere Thinking erhalten bleibt. Damit wird eine dokumentierte Destillationstechnik ausgeschlossen.
• Prompt-Cache-Integrität: Dieselben Änderungen, die die Prüfung brechen, starten meist auch den Prompt-Cache neu. Ein Harness, das die Prüfung besteht, liest sein Präfix weiterhin aus dem Cache – bei Fable 5.1 für 0,25 US-Dollar pro Million Cache-Read-Tokens.

Für wen die Prüfung gilt

• Standardmäßig erzwungen: Konten, die am oder nach dem 31. August 2026 erstellt wurden. Dazu gehören Claude-API-Organisationen, Amazon-Bedrock-Konten, Google-Cloud-Projekte und Microsoft-Foundry-Ressourcen.
• Aufgezeichnet, aber nicht erzwungen: Ältere Konten. Die API registriert Abweichungen, greift aber nur ein, wenn der Request 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.
• Nicht betroffen: Claude Code, claude.ai, Claude Managed Agents und das Claude Agent SDK. Diese Oberflächen halten das Präfix für Sie intakt.
• Nicht geprüft: Claude Mythos 5.1 führt diese Konversationsprüfung nicht durch. Änderungen am Verlauf starten dort jedoch weiterhin den Cache neu.
• Betroffen: Jeder Code, der das messages-Array selbst aufbaut – etwa eigene Agentenschleifen, Chat-Backends oder Frameworks, die die Messages API kapseln.

Die Falle für Tool-Autoren

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.

Was spätere Thinking-Blöcke ungültig macht

Jede Änderung vor einem bereits erzeugten Thinking-Block kann alle nachfolgenden Blöcke ungültig machen:

• Eine frühere Runde bearbeiten, neu anordnen oder entfernen. Dazu gehören gelöschte Tool-Ergebnisse, herausgeschnittene mittlere Runden und clientseitige Verdichtung, bei der die letzten Runden wörtlich hinter einer Zusammenfassung erhalten bleiben.
• Inhalte einfügen, die nicht dauerhaft gespeichert werden, zum Beispiel eine pro-Runden-Erinnerung, die nach den Tool-Ergebnissen angehängt und beim nächsten Request entfernt wird.
• Eine Statuszeile oder eine verbleibende Token-Anzahl einfügen, die sich zwischen Requests verändert.
• system oder tools zwischen Requests neu erzeugen, etwa durch ein aktualisiertes Datum im System-Prompt oder durch das Hinzufügen beziehungsweise Entfernen eines Tools.
• Eine Bild- oder Dokument-URL wiederverwenden, die später andere Bytes liefert. Gebunden sind die Bytes, nicht die URL-Zeichenfolge; eine rotierende signierte URL für dieselbe Datei ist daher in Ordnung.
• Einen Thinking-Block aus der Mitte des Verlaufs entfernen. Führende Blöcke dürfen nur am Anfang und in der Reihenfolge vom ältesten Block an entfernt werden.

Was gültig bleibt

Folgende Änderungen erhalten die Bindung:

• eine append-only-Historie;
• angehängte role: "system"-Nachrichten;
• gelöschte rundenbasierte Nachrichten, die an ihrer ursprünglichen Position verbleiben;
• das Entfernen einer führenden Sequenz von Thinking-Blöcken, beginnend mit dem ältesten;
• Änderungen an Parametern außerhalb von system, tools und messages, etwa max_tokens, output_config einschließlich effort, tool_choice und metadata;
• das Hinzufügen, Verschieben oder Entfernen von cache_control-Markierungen;
• serverseitige Verdichtung und Kontextbearbeitung, einschließlich des Löschens von Thinking-Blöcken.

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.

Der Notausgang: 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:

1. Die Einstellung gilt nur für den aktuellen Request. Senden Sie sie für den Rest der Sitzung erneut.
2. Die Standardwerte unterscheiden sich je nach Oberfläche. Bei einem erzwungenen Konto führt ein fehlender Header zum Fehler. Das alleinige Senden des Headers aktiviert den Beta-Standard, der drop_block verwendet. Setzen Sie den Wert deshalb immer explizit.
3. 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.

Wiederherstellung ohne Beta-Header

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.

Das Drei-Schritte-Audit

1. Tatsächliche Request-Bodies erfassen

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:

• den system-Prompt;
• das tools-Array;
• das gemeinsame Präfix von messages.

Bis zu den neu angehängten Runden müssen diese Bereiche byteidentisch sein.

2. Mit 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.

• Ein leeres Array in jeder Runde bedeutet, dass der Verlauf intakt ist.
• Ein Eintrag mit 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.

3. Eine Produktionseinstellung festlegen

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.

Der Test in Apidog

In Apidog besteht der Test aus zwei Requests:

1. Senden Sie eine erste Runde.
2. Ändern Sie den System-Prompt.
3. Senden Sie die nächste Runde mit gesetztem Beta-Header.
4. Prüfen Sie 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.

Einen Harness append-only gestalten

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.

Clientseitige Verdichtung ist besonders problematisch

Zwei Varianten brechen unter der Prüfung:

• Keep-tail-Verdichtung: Ältere Runden werden zusammengefasst, während die neuesten Runden wörtlich erhalten bleiben. Die Thinking-Blöcke der erhaltenen Runden wurden jedoch mit dem vollständigen ursprünglichen Verlauf erzeugt.
• Hintergrund-Verdichtung: Eine Zusammenfassung wird außerhalb des kritischen Pfads erstellt und später eingefügt. Alle Runden, die zwischen dem Start der Zusammenfassung und ihrer Einfügung erzeugt wurden, passen danach nicht mehr zum Präfix.

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.

Warum dies auch eine Cache-Frage ist

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:

• Das Thinking des Modells bleibt erhalten.
• Das Präfix wird pro Runde für 0,25 US-Dollar pro Million Tokens gelesen, statt für 12,50 US-Dollar neu geschrieben zu werden.

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.

FAQ

Was bedeutet „Der Block ist an eine andere Konversation gebunden“?

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.

Welche Konten erzwingen die Fable-5.1-Historienprüfung?

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.

Wie behebe ich den Fehler schnell?

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.

Macht eine Änderung von 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.

Bricht serverseitige Verdichtung die Prüfung?

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.

Führt Claude Mythos 5.1 dieselbe Prüfung durch?

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.