Erhaltenes Denken

Auf Claude Fable 5.1 wirkt sich das Ändern früherer Turns in der Konversation (des system-Prompts, der tools oder einer beliebigen früheren Nachricht) auf die API-Antwort aus. Standardmäßig führt es dazu, dass die API die Anfrage mit einem Fehler ablehnt, es sei denn, du entscheidest dich dafür, dass die betroffenen Thinking-Blöcke stattdessen aus dem entfernt werden, was das Modell sieht (prefix_mismatch_behavior: "drop_block"). Die Prüfung wird standardmäßig für neue Konten erzwungen, die am oder nach dem 31. August 2026, 00:00 UTC erstellt wurden. Weitere Details findest du unter So funktioniert es und Wer betroffen ist.

Wenn du einen Block zurücksendest, verwendet die API dessen signature, um zu prüfen, dass die vorherige Konversation unverändert ist und dass das aktuelle Modell den Block lesen kann. Die Prüfung existiert, damit Überlegungen, die unter einem Satz von Anweisungen erzeugt wurden, nicht unter einem anderen, möglicherweise feindseligen Satz von Anweisungen wiedergegeben werden können.

Die API bietet erstklassige Alternativen, um eine Konversation im Verlauf zu ändern, die die meisten Anwendungsfälle für Transkript-Bearbeitungen abdecken: System-Nachrichten mitten in der Konversation für neue Anweisungen, Turn-bezogene System-Nachrichten für Erinnerungen pro Turn, Tool-Änderungen mitten in der Konversation zum Hinzufügen und Entfernen von Tools sowie Effort pro Nachricht, um die Denktiefe pro Turn anzupassen. Der Rest dieser Seite behandelt, wie du erkennst, ob deine Integration betroffen ist, und wie du gängige Harness-Muster auf diese Funktionen migrierst. Als zusätzlicher Vorteil hält es auch das Präfix für das „prompt caching“ (Prompt-Caching) stabil, wenn alles vor jedem Thinking-Block Byte für Byte unverändert bleibt; siehe Prompt-Caching.

Ob du etwas tun musst, hängt davon ab, was deinen Konversationsverlauf verwaltet:

• Du verwendest ein offizielles Claude-Produkt oder SDK: Claude Code, claude.ai, Claude Managed Agents oder das Claude Agent SDK. Diese halten das Präfix für dich intakt.
• Du rufst die Messages API direkt auf, aus deiner eigenen Agent-Schleife oder einer beliebigen anderen Umgebung. Du solltest deinen Code prüfen und sicherstellen, dass das messages-Array als nur anhängbar (append-only) behandelt wird. Diese gängigen Muster bearbeiten das Präfix und machen das Denken nach der Bearbeitung ungültig:
  • Ältere Turns kürzen oder verwerfen
  • Ältere Turns auf dem Client zusammenfassen und die jüngsten behalten
  • Eine Erinnerung in einen früheren Turn einfügen und sie bei der nächsten Anfrage entfernen
  • Den system-Prompt bei jeder Anfrage neu aufbauen (aktuelle Uhrzeit, Token-Budget, Modus-Flags)
  • Einträge in tools mitten in der Sitzung hinzufügen oder entfernen

So funktioniert es

Bei neuen Anfragen prüft die API:

• Das Modell ist dasselbe oder neuer. Ein Block ist für das Modell lesbar, das ihn erzeugt hat, und für spätere Modelle, nicht für frühere. Eine Konversation, die zu einem neueren Modell wechselt, behält ihre Überlegungen. Eine Konversation, die zu einem älteren Modell wechselt, besteht die Modellprüfung für diese Blöcke nicht, und die API verwirft sie für diese Anfrage. Siehe Erhaltenes Denken für die genaue Liste pro Modell.
• Nichts vor dem Block hat sich geändert. Der system-Prompt auf oberster Ebene, die Menge der Tools in tools und jede Nachricht vor dem Block. Bei serverseitiger Compaction beginnt das geprüfte Präfix beim jüngsten Compaction-Block.
• Die Kette früherer Thinking-Blöcke ist ununterbrochen. Frühere thinking- und redacted_thinking-Blöcke sind nicht Teil des Präfixes, aber jeder Thinking-Block zeichnet den vorhergehenden auf, über Turns hinweg. Du kannst Thinking-Blöcke vom Anfang des Verlaufs entfernen. Einen aus der Mitte zu entfernen, macht jeden Thinking-Block danach ungültig.

Ein Block, der die Modellprüfung nicht besteht, wird immer verworfen. Bei einer Präfix-Abweichung wählst du mit thinking.block_binding.prefix_mismatch_behavior, was passiert; dies erfordert den Beta-Header thinking-binding-controls-2026-08-01:

• "drop_block": Die API entfernt den Block und jeden Thinking-Block danach in der Konversation, und die Anfrage ist erfolgreich. Verworfene Blöcke werden nicht abgerechnet. Die Antwort listet sie in einem input_transformations-Array auf oberster Ebene auf (beim Streaming im message_start-Event).
• "error": Die API lehnt die Anfrage mit einem 400 invalid_request_error ab, der den ersten fehlschlagenden Block benennt.

Der Standard ist "error". Der Header erlaubt dir, das Feld zu setzen, und fügt input_transformations zu Antworten hinzu.

Wer betroffen ist

Claude Fable 5.1. Siehe Erhaltenes Denken für die Modellliste.

Auf Claude Fable 5.1 erzwingt die API die Prüfung für neue Konten. Ein neues Konto ist eines, das am oder nach dem 31. August 2026, 00:00 UTC erstellt wurde. Dieselbe Definition gilt auf der Claude API und auf Cloud-Plattformen. Spätere Modelle werden die Prüfung für alle Nutzer erzwingen.

Eine Anfrage, die prefix_mismatch_behavior setzt, aktiviert die Erzwingung unabhängig vom Kontoalter; so testest du von einem älteren Konto aus. Um zu prüfen, ob dein Konto standardmäßig der Erzwingung unterliegt, sende eine Anfrage, die den Verlauf bearbeitet, ohne den Beta-Header: Ein 400, der den Header benennt, bedeutet erzwungen.

So erkennst du, ob deine Integration betroffen ist

Erfasse die exakten Request-Bodies, die deine Integration über einige normale Turns hinweg sendet, einschließlich einer Compaction oder einer Tool-Änderung, falls dein Produkt diese durchführt. Vergleiche für jedes Paar aufeinanderfolgender Anfragen system, tools und den gemeinsamen Teil von messages. Sie sollten bis zu den neu angehängten Turns Byte-identisch sein.

Bestätige es dann gegen die API. Setze mit dem Beta-Header thinking-binding-controls-2026-08-01 und claude-fable-5-1 den Wert thinking.block_binding.prefix_mismatch_behavior auf "drop_block" und führe eine normale Multi-Turn-Sitzung durch deine Integration aus. Diese Anfrage ist der zweite Turn einer solchen Sitzung und sendet den Assistant-Turn der ersten Antwort genau so zurück, wie er empfangen wurde:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: thinking-binding-controls-2026-08-01" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 16000,
    "thinking": {
      "type": "adaptive",
      "block_binding": { "prefix_mismatch_behavior": "drop_block" }
    },
    "system": "You are a coding agent.",
    "messages": [
      { "role": "user", "content": "Fix the failing test." },
      {
        "role": "assistant",
        "content": [
          { "type": "thinking", "thinking": "", "signature": "EqQBCkYIBxgCKkD..." },
          { "type": "text", "text": "I need to see the test first. Which file is it in?" }
        ]
      },
      { "role": "user", "content": "tests/test_auth.py" }
    ]
  }'

Jede Antwort trägt dann ein input_transformations-Array auf oberster Ebene. Protokolliere es bei jedem Turn:

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

• Bei jedem Turn leer: Deine Integration hält den Verlauf intakt.
• reason: "prefix_binding_mismatch": Etwas vor dem Block bei path hat sich zwischen dieser Anfrage und der vorherigen geändert. Vergleiche system, tools und messages bis zu diesem Turn per Diff, um es zu finden.
• reason: "model_binding_mismatch": Die Konversation ist zu einem Modell gewechselt, das die Blöcke des früheren Modells nicht lesen kann (ein Router, ein Fallback). Kein Bug in deiner Integration. Sende die Blöcke weiterhin und lass die API verwerfen, was das aktuelle Modell nicht lesen kann.

Das funktioniert von jedem Konto aus, weil das Setzen des Feldes die Anfrage in die Erzwingung einbezieht. Um stattdessen in CI laut fehlzuschlagen, setze "error". Der 400 beginnt mit:

messages.1.content.0: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block".

Ohne den Beta-Header in der Anfrage fährt die Meldung fort: That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header. Die Meldung endet üblicherweise mit einem Satz, der benennt, was sich geändert hat, zum Beispiel dass der system-Prompt oder die tools-Liste sich von dem Zeitpunkt unterscheidet, als der Block erstellt wurde.

Siehe Fehlerbehebung beim Denken für jede Variante dieses Fehlers.

Was als Bearbeitung zählt

Zwischen zwei aufeinanderfolgenden Anfragen:

Aktualisiere deine Integration

Jedes Muster ersetzt eine Art von Verlaufsbearbeitung durch eine API-Funktion, die dieselbe Wirkung auf das Modell hat, ohne frühere Bytes zu ändern.

Hänge Assistant-Turns genau so an, wie sie zurückgegeben wurden

Speichere das content-Array aus jeder Antwort und sende es unverändert als Assistant-Turn zurück, jeden Blocktyp in der empfangenen Reihenfolge, einschließlich thinking-Blöcken, deren thinking-Feld leer ist. Serialisiere nicht über einen Zwischentyp neu, der unbekannte Blocktypen oder leere Felder verwirft.

Füge Anweisungen mit einer System-Nachricht mitten in der Konversation hinzu, nicht durch Bearbeiten von system

Wenn dein Code den system-Prompt auf oberster Ebene bei jeder Anfrage neu aufbaut (aktuelle Uhrzeit, Token-Budget, Modus-Flag, neu entdeckter Projektkontext), besteht jeder Thinking-Block in der Konversation die Prüfung nicht. Friere system beim Sitzungsstart ein, und wenn sich etwas ändert, hänge eine role: "system"-Nachricht an der Stelle in messages an, an der es wahr wird:

{
  "role": "system",
  "content": "The user switched the workspace to read-only mode. Do not write files until told otherwise."
}

Das Modell behandelt sie mit System-Prompt-Autorität, und alles davor bleibt unverändert. Auf Claude Fable 5.1 ist kein Beta-Header nötig. Platziere sie in einer Tool-Schleife nach der tool_result-User-Nachricht, niemals zwischen einem Assistant-tool_use und dessen tool_result (siehe Einschränkungen).

Sende Erinnerungen pro Turn als Turn-bezogene System-Nachrichten

Die häufigste Verlaufsbearbeitung ist der Anstoß pro Turn: eine Zeile, die nach jedem Stapel von Tool-Ergebnissen angehängt wird („fordere unabhängige Lesevorgänge gemeinsam an“, „du hast den Nutzer schon eine Weile nicht mehr informiert“) und bei der nächsten Anfrage entfernt wird, damit sich Erinnerungen nicht anhäufen. Das Entfernen ist die Bearbeitung.

Sende den Anstoß stattdessen als System-Nachricht mitten in der Konversation mit clear_at: "next_user_message" nach der tool_result-User-Nachricht (Beta-Header mid-conversation-system-clear-at-2026-08-21). Dieses messages-Array ist die Anfrage nach zwei Tool-Runden. messages[3] ist der Anstoß der vorherigen Anfrage, an Ort und Stelle belassen, und messages[6] ist die Kopie dieser Anfrage:

[
  { "role": "user", "content": "Fix the failing test." },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_01",
        "name": "read_file",
        "input": { "path": "tests/test_auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_01", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "", "signature": "..." },
      {
        "type": "tool_use",
        "id": "toolu_02",
        "name": "read_file",
        "input": { "path": "src/auth.py" }
      }
    ]
  },
  {
    "role": "user",
    "content": [{ "type": "tool_result", "tool_use_id": "toolu_02", "content": "..." }]
  },
  {
    "role": "system",
    "clear_at": "next_user_message",
    "content": "Request every independent read in one turn."
  }
]

Eine User-Nachricht, die nur tool_result enthält, zählt als die „nächste User-Nachricht“, daher ist messages[3] bereits gelöscht: Sie rendert nichts und kostet keine Input-Token, aber sie ist immer noch im Array, sodass das Denken in messages[4] gültig bleibt. messages[6] ist das, was das Modell in diesem Turn sieht. Belasse bei späteren Anfragen beide, wo sie sind, und hänge die nächste Kopie nach der nächsten tool_result-Nachricht an. Turn-bezogene Nachrichten tragen nur text und akzeptieren kein cache_control. Setze den Cache-Breakpoint auf den vorhergehenden User-Turn. Siehe Turn-bezogene System-Nachrichten.

Ohne die Beta hänge den Anstoß als text-Block nach den tool_result-Blöcken in derselben User-Nachricht an und belasse frühere Kopien an Ort und Stelle. Das Modell handelt nach der neuesten.

Ändere Tools mit tool_addition und tool_removal, nicht durch Bearbeiten von tools

Wenn sich die Menge der Tools mitten in der Sitzung ändert (ein Tool wird nach der Authentifizierung freigeschaltet, ein gefährliches Tool wird nach einem Moduswechsel zurückgezogen), bearbeite tools nicht. Deklariere die vollständige Menge beim Sitzungsstart und verwende Tool-Änderungen mitten in der Konversation, um ein Tool ab diesem Punkt anzubieten oder zurückzuziehen (Beta-Header mid-conversation-tool-changes-2026-07-01). Ein Tool, das noch nicht verfügbar ist, erhält defer_loading: true und einen späteren tool_addition-Block, in derselben Form wie dieses tool_removal:

{
  "role": "system",
  "content": [
    { "type": "tool_removal", "tool": { "type": "tool_reference", "name": "delete_branch" } },
    { "type": "text", "text": "Branch deletion is disabled for the rest of this session." }
  ]
}

Ein Tool, dessen Schema du mitten in der Sitzung erfährst (ein zur Laufzeit entdeckter MCP-Server), kann mit defer_loading: true an tools angehängt und mit tool_addition angeboten werden. Ein nicht referenziertes verzögertes Tool ist nicht Teil des Präfixes, daher ist das Anhängen sicher. Das Anhängen eines regulären Tools ist es nicht.

Kürze den Kontext auf dem Server, wo du kannst

Clientseitiges Abschneiden und Zusammenfassen sind die zweithäufigste Bearbeitung: die ältesten Turns verwerfen oder zusammenfassen und die jüngsten wörtlich behalten. Die Thinking-Blöcke der jüngsten Turns wurden erzeugt, während der von dir entfernte Verlauf noch vorhanden war, daher bestehen sie die Prüfung nicht. Die serverseitigen Entsprechungen zählen nicht als Bearbeitungen, weil die Prüfung die Konversation so vergleicht, wie du sie gesendet hast:

• Compaction fasst ältere Turns in einem Compaction-Block zusammen, wenn der Kontext sich einem von dir gesetzten Schwellenwert nähert, und das geprüfte Präfix beginnt ab diesem Block neu. Ihr instructions-Parameter nimmt deinen eigenen Zusammenfassungs-Prompt entgegen („bewahre jeden Ticker, jede Positionsgröße und jede genannte Annahme“).
• Context Editing löscht alte Tool-Ergebnisse (clear_tool_uses_20250919) oder alte Thinking-Blöcke, die ältesten zuerst (clear_thinking_20251015), nach Regel.

Benutzerdefinierte Compaction auf dem Client

Diese Prüfung verbietet clientseitige Compaction nicht. Die Regel ist enger: Behalte keinen Thinking-Block hinter einem Präfix, das du umgeschrieben hast.

Einfache Compaction ist die empfohlene Form und benötigt keine Änderungen. Wenn die Konversation zu lang wird, fasse sie in einer Nachricht zusammen und beginne die nächste Anfrage mit dieser Zusammenfassung plus dem neuen User-Turn, ohne frühere Turns oder Thinking-Blöcke erneut zu senden: messages wird zu [{"role": "user", "content": "<summary of the session so far>\n\n<the next instruction>"}]. Es bleibt kein früheres Denken übrig, also schlägt nichts fehl, und das Modell denkt auf der kompaktierten Konversation neu. Claude-Modelle werden mit diesem Schema auf Aufgaben mit langem Horizont trainiert, und es schneidet für die meisten Workloads vergleichbar mit aufwendigeren Schemata ab. Es setzt den Prompt-Cache am Compaction-Punkt zurück, wie jede Compaction.

Zwei andere gängige Formen schlagen in der beschriebenen Weise fehl und benötigen jeweils eine Änderung:

• Keep-Tail-Compaction fasst ältere Turns zusammen und behält die jüngsten Turns wörtlich. Die Thinking-Blöcke der behaltenen Turns wurden gegen den vollständigen Verlauf erzeugt, daher schlagen sie hinter der Zusammenfassung fehl. Lösung: Entferne thinking und redacted_thinking aus jedem Assistant-Turn, den du übernimmst, und behalte text und tool_use, oder sende prefix_mismatch_behavior: "drop_block" und lass die API sie entfernen.
• Hintergrund-Compaction erstellt die Zusammenfassung abseits des kritischen Pfads und tauscht sie ein, während die Konversation weiterläuft, sodass jeder in der Zwischenzeit erzeugte Turn Denken enthält, das vor dem Austausch entstanden ist. Lösung: Sende "drop_block" bei jeder Anfrage, die noch Thinking-Blöcke trägt, die vor dem Austausch erzeugt wurden (oder entferne diese Blöcke selbst; input_transformations in der ersten Antwort nach dem Austausch listet genau auf, welche), oder kompaktiere synchron.

Einzelne Turns aus der Mitte des Transkripts herauszuschneiden, macht alles danach ungültig, und keine clientseitige Form vermeidet das. Verwende eine System-Nachricht mitten in der Konversation für die Anweisungsänderung, die du vornehmen wolltest, oder serverseitiges Context Editing für selektives Entfernen.

Kompaktiere nicht mitten in einer Tool-Runde: Ein Assistant-Turn, dessen tool_use noch auf ein tool_result wartet, sollte mit intaktem Denken zurückgehen, damit das Modell die Runde mit seinen Überlegungen abschließt (siehe Thinking-Blöcke erhalten).

Referenziere Dateien per ID, nicht per URL, deren Inhalt sich ändert

Bei einem image- oder document-Block mit einer url-Quelle sind die abgerufenen Bytes Teil des geprüften Präfixes, der URL-String nicht. Ein „neuester Screenshot“-Endpunkt oder ein bearbeitetes Dokument macht späteres Denken ungültig. Eine rotierende signierte URL für dieselbe Datei nicht. Lade Inhalte, die du über Turns hinweg referenzierst, einmal mit der Files API hoch und verwende die file_id, oder sende base64.

Entscheide, was bei einer Abweichung passiert

Sobald deine Integration nur noch anhängt, wähle ein prefix_mismatch_behavior für die Produktion. Es regelt nur Präfix-Abweichungen. Ein Block, den das aktuelle Modell nicht lesen kann (nach einem Router-Wechsel oder serverseitigem Fallback), wird immer verworfen und in input_transformations gemeldet, wenn der Beta-Header gesendet wird.

• "error" (der Standard), wenn eine Präfix-Abweichung nur einen Bug in deinem Code bedeuten kann. Du erfährst es durch einen 400 beim Testen statt durch stillschweigend verworfene Blöcke. In der Message Batches API verwirft der nicht gesetzte Standard fehlschlagende Blöcke, anstatt das Batch-Element fehlschlagen zu lassen; setze "error" explizit, wenn du möchtest, dass Elemente einen Fehler liefern.
• "drop_block", wenn du lieber die betroffenen Blöcke verwirfst als fehlzuschlagen. Protokolliere input_transformations.

Wenn du den 400 in der Produktion abfängst, behebt ein erneutes Senden derselben Anfrage ihn nicht. Wiederhole mit prefix_mismatch_behavior: "drop_block" (und dem Beta-Header), was genau die Blöcke entfernt, die fehlschlagen, einschließlich aller in einem Assistant-Turn, dessen tool_use noch auf sein tool_result wartet. Das Verwerfen gilt nur für diese Anfrage, sende also "drop_block" (und den Beta-Header) für den Rest der Sitzung weiter. Ohne die Beta entferne jeden thinking- und redacted_thinking-Block aus dem Verlauf, belasse die text- und tool_use-Blöcke jedes Turns an Ort und Stelle und wiederhole einmal. Behebe dann die Bearbeitung, die es verursacht hat.

Auf dieser Seite verwendete API-Funktionen

Um Header in einer Anfrage zu kombinieren:

anthropic-beta: thinking-binding-controls-2026-08-01,mid-conversation-system-clear-at-2026-08-21,mid-conversation-tool-changes-2026-07-01

Dieselben Beta-Namen gelten auf Amazon Bedrock und Google Cloud. Siehe Beta-Header dazu, wie du sie mit jedem SDK sendest.

Checkliste

• Wenn ein offizielles Claude-Produkt oder SDK (Claude Code, claude.ai, Claude Managed Agents, das Claude Agent SDK) deinen Konversationsverlauf verwaltet, kannst du hier aufhören.
• Aufeinanderfolgende Request-Bodies sind in system, tools und dem gemeinsamen messages-Präfix Byte-identisch.
• Eine vollständige Sitzung unter prefix_mismatch_behavior: "drop_block" protokolliert keine prefix_binding_mismatch-Einträge.
• Assistant-Turns gehen Byte für Byte so zurück, wie sie zurückgegeben wurden, alle Blocktypen eingeschlossen.
• system und tools auf oberster Ebene sind für die Sitzung fest. Änderungen gehen in role: "system"-Nachrichten und tool_addition- / tool_removal-Blöcke.
• Erinnerungen pro Turn sind Turn-bezogene System-Nachrichten (oder nachgestellte Textblöcke), die frisch angehängt und nie entfernt werden.
• Kontext wird durch Compaction oder Context Editing gekürzt, oder durch eine clientseitige Compaction, die keine Thinking-Blöcke hinter dem umgeschriebenen Präfix zurücklässt und nie eine Tool-Runde aufteilt.
• Turn-übergreifende Dateien sind file_id oder base64, keine veränderlichen URLs.
• Ein prefix_mismatch_behavior für die Produktion ist gesetzt, und seine 400er oder verworfenen Einträge werden überwacht.

Nächste Schritte