Erhaltenes Nachdenken

„Preserved thinking“ (bewahrtes Nachdenken) ist eine Eigenschaft neuerer Claude-Modelle, die vor Destillation schützt. Sie bestimmt, ob das Modell einen „thinking block“ (Thinking-Block) verwenden kann, den du aus einem früheren Turn zurücksendest. Ab Claude Fable 5.1 prüft die API, wenn ein thinking- oder redacted_thinking-Block in einer Anfrage zurückkommt, die signature des Blocks auf zwei Dinge:

• Das Modell kann den Block lesen. Jedes Modell liest seine eigenen Thinking-Blöcke und die einer festen Gruppe anderer Modelle. Claude Fable 5.1 liest Blöcke von Claude Opus 5 und, auf der Claude API, von Claude Opus 5.5; weder Claude Opus 5 noch Claude Opus 5.5 liest Blöcke von Claude Fable 5.1. Wenn das aktuelle Modell einen Block nicht lesen kann, entfernt die API ihn ohne Fehler aus dieser Anfrage. Siehe Modellwechsel mitten im Gespräch.
• Vor dem Thinking-Block hat sich nichts geändert. Der system-Prompt auf oberster Ebene, tools und die messages vor dem Block bilden sein Präfix. Wenn sich das Präfix von dem unterscheidet, was du gesendet hast, als der Block erzeugt wurde, sind dieser Block und jeder spätere Thinking-Block ungültig, und die API lehnt die Anfrage mit einem 400-Fehler ab oder entfernt die ungültigen Blöcke, je nachdem, was du wählst. Siehe Das Präfix unverändert lassen.

Thinking-Blöcke von Claude Sonnet 5.5 und Claude Haiku 5.5 sind außerdem an das Konto gebunden, das sie erzeugt hat. Unter Thinking-Blöcke bleiben bei dem Konto, das sie erzeugt hat erfährst du, wo die API dies durchsetzt.

Die Modellprüfung gilt für jedes Konto. Die Präfixprüfung setzt die API standardmäßig für Konten durch, die am oder nach dem 31. August 2026, 00:00 UTC, erstellt wurden. Bei älteren Konten setzt sie die Präfixprüfung nur bei Anfragen durch, die thinking.block_binding.prefix_mismatch_behavior setzen. Gestalte deine Integration unabhängig vom Alter deines Kontos append-only, damit derselbe Code auf jedem Konto funktioniert, einschließlich neuerer Konten, bei denen die Prüfung standardmäßig durchgesetzt wird.

Wer etwas ändern muss

Für dich ändert sich nichts, wenn Claude Code, claude.ai, Claude Managed Agents oder das Claude Agent SDK deine Anfragen erstellt, oder wenn dein Code system und tools für eine Sitzung unverändert lässt und an messages immer nur anhängt. Claude Mythos 5.1 und Modelle vor Claude Fable 5.1 führen die Präfixprüfung nicht aus. Wenn du nie Thinking-Blöcke zurücksendest, hat die Präfixprüfung nichts abzulehnen, und das Modell erhält nichts von seinem früheren Nachdenken.

Prüfe deine Integration, wenn sie zwischen zwei Anfragen in einem Gespräch eines der folgenden Dinge tut. Jeder Punkt verlinkt darauf, was du stattdessen tun solltest:

• Den system-Prompt neu aufbauen: das Datum, ein Modus-Flag, neu eingelesene Projektanweisungen oder ein Plugin oder MCP-Server, der sich nach dem ersten Turn verbindet
• Den Kontext in der ersten Benutzernachricht neu rendern
• Alte Tool-Ergebnisse leeren oder kürzen oder alte Bilder neu kodieren
• Alte Turns auf dem Client zusammenfassen oder entfernen und neuere Turns mit ihrem Nachdenken behalten
• Einträge in tools hinzufügen, entfernen oder bearbeiten
• Einem Benutzer-Turn eine Erinnerung hinzufügen und sie später entfernen oder umschreiben
• Einige thinking-Blöcke entfernen und spätere behalten oder sie entfernen und später wieder einfügen
• Eine gespeicherte Sitzung aus Vorlagen neu aufbauen, statt das erneut abzuspielen, was gesendet wurde

Auf einem älteren Konto erzeugt keiner dieser Punkte einen Fehler, es sei denn, die Anfrage setzt prefix_mismatch_behavior. Ein fehlerfreier Lauf mit deinem eigenen Key zeigt also nicht, ob dein Code betroffen ist. Wenn Leute dein Tool mit ihren eigenen API-Keys ausführen, erhalten diejenigen mit neueren Konten den 400-Fehler vor dir. Um zu sehen, was sie sehen, ohne das Verhalten deiner Anfragen zu ändern, sende den Beta-Header thinking-binding-controls-2026-08-01. Auf einem älteren Konto markiert dann jede Antwort Blöcke, die die Prüfung nicht bestehen, und das Modell liest sie trotzdem (siehe Das Mismatch-Verhalten festlegen und input_transformations lesen).

Prüfe deine Integration auch, wenn sie Thinking-Blöcke von Claude Sonnet 5.5 oder Claude Haiku 5.5 aus einem Konto in einer Anfrage sendet, die von einem anderen Konto gestellt wird. Siehe Thinking-Blöcke bleiben bei dem Konto, das sie erzeugt hat.

Modellwechsel mitten im Gespräch

Claude Fable 5.1 und Claude Mythos 5.1 lesen Thinking-Blöcke, die voneinander und von früheren Claude-Modellen erzeugt wurden. Kein anderes Modell liest Thinking-Blöcke von Claude Fable 5.1 oder Claude Mythos 5.1.

Claude Opus 5.5 liest Thinking-Blöcke von Claude Opus 5, von früheren Opus-, Sonnet- und Haiku-Modellen und, auf der Claude API und Google Cloud, von Claude Sonnet 5.5 und Claude Haiku 5.5, aber nicht von Claude Fable- oder Claude Mythos-Modellen. Auf der Claude API lesen Claude Fable 5.1 und Claude Mythos 5.1 Thinking-Blöcke von Claude Opus 5.5; kein anderes Modell tut das. Ein Gespräch, das von Claude Opus 5 zu Claude Opus 5.5 wechselt, behält also sein Nachdenken, ebenso eines, das auf der Claude API von Claude Opus 5.5 zu Claude Fable 5.1 oder Claude Mythos 5.1 aufsteigt. Ein Gespräch, das von Claude Fable 5.1 oder Claude Mythos 5.1 zu Claude Opus 5.5 wechselt, oder von Claude Opus 5.5 zu einem anderen Modell als diesen beiden, führt die Turns nach dem Wechsel ohne das Nachdenken des vorherigen Modells aus. Die Blöcke werden entfernt, nicht abgelehnt, wie später in diesem Abschnitt beschrieben.

Claude Sonnet 5.5 liest Thinking-Blöcke von Claude Sonnet 5, Claude Opus 4.8, Claude Haiku 4.5 und früheren Modellen sowie, auf der Claude API und Google Cloud, von Claude Haiku 5.5, aber nicht von Claude Opus 5, Claude Opus 5.5 oder einem Claude Fable- oder Claude Mythos-Modell. Auf der Claude API und Google Cloud liest Claude Opus 5.5 Thinking-Blöcke von Claude Sonnet 5.5; kein anderes Modell tut das. Ein Gespräch, das von Claude Sonnet 5 zu Claude Sonnet 5.5 wechselt, behält also sein Nachdenken, ebenso eines, das auf der Claude API und Google Cloud von Claude Sonnet 5.5 zu Claude Opus 5.5 aufsteigt. Ein Gespräch, das von Claude Opus 5, Claude Opus 5.5 oder einem Claude Fable- oder Claude Mythos-Modell zu Claude Sonnet 5.5 wechselt, führt die Turns nach dem Wechsel ohne das Nachdenken des vorherigen Modells aus. Dasselbe gilt für jeden anderen Wechsel weg von Claude Sonnet 5.5, zum Beispiel einen serverseitigen Fallback auf Claude Sonnet 5.

Claude Haiku 5.5 liest Thinking-Blöcke von Claude Sonnet 5, Claude Opus 4.8, Claude Haiku 4.5 und früheren Modellen, aber nicht von Claude Opus 5, Claude Opus 5.5, Claude Sonnet 5.5 oder einem Claude Fable- oder Claude Mythos-Modell. Auf der Claude API und Google Cloud lesen Claude Opus 5.5 und Claude Sonnet 5.5 Thinking-Blöcke von Claude Haiku 5.5; kein anderes Modell tut das. Ein Gespräch, das von Claude Haiku 4.5 zu Claude Haiku 5.5 wechselt, behält also sein Nachdenken, ebenso eines, das auf der Claude API und Google Cloud von Claude Haiku 5.5 zu Claude Opus 5.5 oder Claude Sonnet 5.5 aufsteigt. Ein Gespräch, das von Claude Opus 5, Claude Opus 5.5, Claude Sonnet 5.5 oder einem Claude Fable- oder Claude Mythos-Modell zu Claude Haiku 5.5 wechselt, führt die Turns nach dem Wechsel ohne das Nachdenken des vorherigen Modells aus, und dasselbe gilt für jeden anderen Wechsel weg von Claude Haiku 5.5.

• Ein Gespräch, das von einem früheren Modell oder, auf der Claude API, von Claude Opus 5.5 zu Claude Fable 5.1 wechselt, behält sein Nachdenken. Die Thinking-Blöcke des früheren Modells bleiben lesbar, sodass das Modell ab dem ersten Turn nach dem Wechsel wie gewohnt nachdenkt.
• Ein Gespräch, das von Claude Fable 5.1 zu einem anderen Modell als Claude Mythos 5.1 wechselt, verliert für diese Anfrage das Nachdenken von Claude Fable 5.1. Das passiert, wenn ein Router einen Turn an ein günstigeres Modell sendet, nach einem Fallback bei einer Klassifikator-Ablehnung oder während eines serverseitigen Fallbacks. Die API entfernt die nicht lesbaren Blöcke, bevor der Prompt das Modell erreicht. Sie werden nicht abgerechnet und zählen nicht zu input_tokens.

Sende bei jeder Anfrage weiterhin den vollständigen Verlauf, einschließlich der Thinking-Blöcke, und lass die API entfernen, was das aktuelle Modell nicht lesen kann. Die API bearbeitet dein messages-Array nie, sodass die entfernten Blöcke in deinem Verlauf bleiben. Wenn derselbe Verlauf wieder an Claude Fable 5.1 geht, sind seine Blöcke wieder lesbar, zusammen mit dem Nachdenken des früheren Modells. Das Nachdenken geht nur dann endgültig verloren, wenn dein Client die Blöcke selbst entfernt, zum Beispiel ein Harness, das bei einem Modellwechsel das Nachdenken entfernt oder den Verlauf aus dem neu aufbaut, was jedes Modell verwendet hat.

Mit dem Beta-Header thinking-binding-controls-2026-08-01 listet die Antwort jeden entfernten Block in einem input_transformations-Array auf oberster Ebene mit reason: "model_binding_mismatch" auf:

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

Ohne den Header erfolgt das Entfernen stillschweigend. Dieser Eintrag ist kein Fehler in deiner Integration, und prefix_mismatch_behavior hat keinen Einfluss darauf: Ein Block, den das aktuelle Modell nicht lesen kann, wird immer entfernt.

Thinking-Blöcke bleiben bei dem Konto, das sie erzeugt hat

Thinking-Blöcke, die Claude Sonnet 5.5 oder Claude Haiku 5.5 erzeugt, funktionieren nur in dem Konto, das sie erzeugt hat, oder in einem damit verknüpften Konto. Wenn ein anderes Konto einen dieser Blöcke sendet, entfernt die API den Block, bevor das Modell ihn sieht, und die Anfrage ist erfolgreich. Das Modell antwortet ohne das Nachdenken in den entfernten Blöcken. Blöcke von früheren Modellen sind nicht betroffen.

Auf der Claude API und Google Cloud listet die Antwort mit dem Beta-Header thinking-binding-controls-2026-08-01 jeden entfernten Block in input_transformations als thinking_dropped-Eintrag mit reason: "organization_binding_mismatch" auf. Ohne den Header erfolgt das Entfernen stillschweigend.

Das Präfix unverändert lassen

Bei Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 und Claude Haiku 5.5 bleibt ein Thinking-Block nur gültig, solange alles, was du davor gesendet hast, bei späteren Anfragen unverändert bleibt. Das geprüfte Präfix besteht aus drei Teilen:

• Dem system-Prompt auf oberster Ebene
• Der Menge der tools
• Jeder message vor dem Block

Hinweis: Bei serverseitiger Komprimierung beginnt das geprüfte Präfix beim neuesten Komprimierungsblock.

Anfrageparameter außerhalb dieser drei Felder, wie effort, max_tokens, output_config, tool_choice und metadata, sind nicht Teil der Präfixprüfung, ebenso wenig cache_control-Markierungen. Was als Bearbeitung zählt enthält die vollständige Liste.

Frühere Thinking-Blöcke sind nicht Teil des Präfixes, aber jeder Thinking-Block speichert, welcher Thinking-Block ihm vorausging, über Turns hinweg. Du kannst Thinking-Blöcke vom Anfang des Verlaufs (die ältesten zuerst), vom Ende oder alle entfernen. Was fehlschlägt, ist eine Lücke: Die Thinking-Blöcke, die du behältst, müssen eine ununterbrochene Folge der ursprünglichen Reihenfolge sein, sodass das Entfernen eines Blocks aus der Mitte die Thinking-Blöcke danach ungültig macht. Wenn du einen Block einmal entfernt hast, lass ihn weg. Ihn wieder einzufügen macht die Thinking-Blöcke ungültig, die erzeugt wurden, während er fehlte.

Halte system und tools für die Sitzung unverändert und behandle messages als append-only. Dieselbe Disziplin hält das Präfix für Prompt-Caching stabil: Die Bearbeitungen, die das Nachdenken ungültig machen, sind die Bearbeitungen, die den Cache neu starten.

Was die API mit einem ungültigen Block macht

Du wählst das mit thinking.block_binding.prefix_mismatch_behavior:

• "error" (der Standard): Die API lehnt die Anfrage mit einem 400-invalid_request_error ab, der den ersten fehlschlagenden Block benennt.
• "drop_block": Die API entfernt jeden fehlschlagenden Block und jeden Thinking-Block danach, und die Anfrage ist erfolgreich. Entfernte Blöcke werden nicht abgerechnet. Das Modell beantwortet diesen Turn, ohne das Nachdenken aus entfernten Blöcken zu verwenden, und der Prompt-Cache startet bei der Bearbeitung neu. Die Antwort listet jeden entfernten Block in input_transformations (beim Streaming im message_start-Event) mit reason: "prefix_binding_mismatch" auf.

Zähle die Antworten in jeder Sitzung, deren input_transformations einen prefix_binding_mismatch-Eintrag enthält, löse dafür Alarme aus und ersetze jede Bearbeitung durch das passende Muster in Änderungen vornehmen, ohne das Präfix zu bearbeiten. In der Message Batches API schlägt ein Element, das das Feld nicht setzt, nicht fehl. Wo die API die Prüfung standardmäßig erzwingt, entfernt sie stattdessen die fehlschlagenden Blöcke. Setze dort explizit "error", wenn Batch-Elemente fehlschlagen sollen.

Sowohl das Feld als auch das input_transformations-Array erfordern den Beta-Header thinking-binding-controls-2026-08-01. Das Mismatch-Verhalten festlegen und input_transformations lesen zeigt die Anfrage in jedem SDK.

Die 400-Meldung beginnt so:

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

Wenn die Anfrage den Beta-Header nicht gesendet hat, geht die Meldung so weiter:

That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header.

Sie endet normalerweise mit einem Satz, der benennt, was sich geändert hat, zum Beispiel, dass sich der system-Prompt oder die tools-Liste von dem Zeitpunkt unterscheidet, als der Block erstellt wurde. Fehlerbehebung beim Nachdenken beschreibt, was dieser Satz benennen kann.

Eine manipulierte oder nicht entschlüsselbare Signatur ist ein anderer Fehler. Sie gibt immer einen 400-Fehler zurück (Invalid `signature` in `thinking` block ohne Satz über das Gespräch), und prefix_mismatch_behavior gilt dafür nicht.

Output-Token-Kosten von "drop_block"

In Anthropics Tests mit einem Multi-Turn-Coding-Benchmark erhöhte das einmalige Entfernen von Thinking-Blöcken pro Sitzung die Output-Token um 2,5 % bei niedrigem Effort, 3,9 % bei mittlerem, 4,5 % bei hohem und 20,1 % bei maximalem. Das Entfernen in jedem Turn nach dem ersten erhöhte die Output-Token um 4,6 % bei niedrigem Effort, 9,7 % bei mittlerem, 10,3 % bei hohem und 67,1 % bei maximalem. Diese Zahlen sind Schätzungen mit großen Fehlerbalken, und die Auswirkung auf deinen Workload hängt von deinem Harness ab.

Wenn Claude das Nachdenken aus früheren Turns nicht mehr lesen kann, erstellt es dieses Nachdenken neu, sodass Anfragen, die Thinking-Blöcke entfernen, mehr Output-Token generieren und die Antwort länger dauern kann. Ein Entfernen in jedem Turn kostet mehr als ein gelegentliches Entfernen, und wie viel mehr, hängt von deinem Harness ab: wie oft es das Präfix bearbeitet und wie stark jeder Turn auf früherem Nachdenken aufbaut.

Bevor du dich auf "drop_block" verlässt, führe Evals mit deinem eigenen Workload durch, um den Anstieg zu messen. Wenn er gering ist, kann "drop_block" dafür sorgen, dass Anfragen erfolgreich bleiben, während du die Bearbeitung behebst. So oder so ist es langfristig die bessere Lösung, die Bearbeitung mit einem Muster aus Änderungen vornehmen, ohne das Präfix zu bearbeiten zu beheben.

Den Fehler im Code behandeln

Dies ist der 400 invalid_request_error, der weiter oben in diesem Abschnitt gezeigt wurde. Sende nicht denselben Body erneut: Er schlägt jedes Mal auf dieselbe Weise fehl. Versuche es einmal erneut mit dem Beta-Header und prefix_mismatch_behavior: "drop_block" als Notlösung ("drop_block" kann die Output-Token erhöhen), und speichere diese Wahl mit der Sitzung, damit jede spätere Anfrage sie ebenfalls sendet, auch nach einem Neustart. Bei Claude Sonnet 5.5 und Claude Haiku 5.5 funktioniert block_binding nur mit thinking: {"type": "adaptive"}. Bei between_tools auf Claude Sonnet 5.5 oder thinking: {"type": "disabled"} auf Claude Haiku 5.5 halte den Verlauf append-only oder entferne die Thinking-Blöcke ab dem bearbeiteten Turn. Wenn du den Beta-Header nicht senden kannst, entferne einmal jeden thinking- und redacted_thinking-Block aus dem Verlauf, lass sie weg und fahre fort. Behebe dann die Bearbeitung, die den Mismatch verursacht hat.

Das Mismatch-Verhalten festlegen und input_transformations lesen

Der Beta-Header thinking-binding-controls-2026-08-01 fügt Folgendes hinzu:

• Ein input_transformations-Array auf oberster Ebene in jeder Antwort
• Ein block_binding-Objekt in der thinking-Konfiguration, dessen einziges Feld prefix_mismatch_behavior ist

block_binding wird zusammen mit thinking.type: "adaptive" und thinking.type: "enabled" akzeptiert. Bei Claude Sonnet 5.5 und Claude Haiku 5.5 funktioniert block_binding nur mit thinking: {"type": "adaptive"}. Wenn du es mit between_tools auf Claude Sonnet 5.5 oder mit thinking: {"type": "disabled"} auf Claude Haiku 5.5 sendest, wird ein 400-Fehler zurückgegeben. Wenn du es ohne den Beta-Header sendest, wird ein 400-Fehler zurückgegeben, dessen Meldung mit block_binding: Extra inputs are not permitted endet. Modelle, die die Präfixprüfung nicht ausführen, akzeptieren das Objekt und melden nur Entfernungen durch die Modellprüfung, sodass ein Anfrage-Body modellübergreifend funktioniert. Die API-Referenz nennt die Präfixprüfung die Gesprächsprüfung.

Die folgende Anfrage entscheidet sich für Entfernen statt Ablehnen. Bei einem ersten Turn gibt es nichts erneut abzuspielen, daher kommt input_transformations leer zurück:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=[
        {
            "role": "user",
            "content": "What is the greatest common divisor of 1071 and 462?",
        }
    ],
    betas=["thinking-binding-controls-2026-08-01"],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

print(f"Input transformations: {len(response.input_transformations or [])}")

The greatest common divisor of 1071 and 462 is 21.
Input transformations: 0

Unter dem Beta-Header enthält jede Antwort eines Modells mit Nachdenk-Fähigkeit input_transformations. Jeder Eintrag benennt einen Thinking-Block über seinen path (zum Beispiel messages.1.content.0) und gibt einen reason an. Es gibt zwei Eintragstypen:

• thinking_dropped: Die API entfernt den Block, bevor das Modell ihn liest, und der Block wird nicht abgerechnet. Der reason ist prefix_binding_mismatch oder model_binding_mismatch (siehe Modellwechsel mitten im Gespräch). Der reason kann auch organization_binding_mismatch sein, was bedeutet, dass der Block von einem anderen Konto stammt (siehe Thinking-Blöcke bleiben bei dem Konto, das sie erzeugt hat).
• thinking_mismatch_allowed: Der Block besteht die Präfixprüfung nicht, aber die API setzt diese Prüfung für diese Anfrage nicht durch, sodass der Block das Modell unverändert erreicht und abgerechnet wird. Der reason ist immer prefix_binding_mismatch. Dieser Eintrag erscheint nur bei Anfragen, bei denen die API die Prüfung nicht standardmäßig durchsetzt, etwa bei Anfragen von einem älteren Konto (siehe Wann die API die Prüfung erzwingt). Das Setzen von prefix_mismatch_behavior auf einen der beiden Werte aktiviert die Durchsetzung für die Anfrage, sodass eine Anfrage, die es setzt, diesen Eintrag nie erhält.

Das Array ist leer, wenn kein Block entfernt wurde und keiner die Präfixprüfung nicht bestanden hat. Ignoriere Einträge, deren type oder reason du nicht kennst, da spätere Prüfungen weitere Werte hinzufügen.

Beim Streaming kommt das Array im message-Objekt des message_start-Events an. Nach einem serverseitigen Fallback mitten im Stream enthält das abschließende message_delta-Event es erneut mit den Einträgen des bedienenden Modells. In einem Message Batch wird ein Element, dessen Block die Präfixprüfung unter einem expliziten "error" nicht besteht, als errored aufgelöst. Ein Element, das das Feld nicht setzt, schlägt nicht fehl. Wo die API die Prüfung standardmäßig durchsetzt, entfernt sie stattdessen die fehlschlagenden Blöcke. Der Token-Zählungs-Endpunkt führt dieselbe Präfixprüfung aus und gibt denselben 400 zurück.

Wann die API die Prüfung erzwingt

Die API setzt die Präfixprüfung bei Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 und Claude Haiku 5.5 für neue Konten durch.

• Konten, die am oder nach dem 31. August 2026, 00:00 UTC, erstellt wurden: Die API prüft Anfragen an Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 und Claude Haiku 5.5 und wendet "error" an, sofern du nicht "drop_block" setzt. Dieselbe Definition eines neuen Kontos gilt für die Claude API und für Cloud-Plattformen.
• Ältere Konten: Die API setzt die Prüfung nur bei Anfragen durch, die prefix_mismatch_behavior setzen. Das Setzen des Felds aktiviert die Durchsetzung für eine Anfrage, sodass du sehen kannst, was ein neues Konto sieht, ohne eines zu erstellen. Bei Anfragen, die es nicht setzen, führt die API die Prüfung trotzdem aus, lässt fehlschlagende Blöcke aber zum Modell durch. Mit dem Beta-Header listet die Antwort jeden davon in input_transformations als thinking_mismatch_allowed auf, sodass du Präfixbearbeitungen finden kannst, ohne zu ändern, was das Modell erhält.

Um herauszufinden, zu welcher Gruppe dein Konto gehört, nimm ein Claude Fable 5.1-Gespräch, das einen Thinking-Block enthält, ändere etwas vor diesem Block und sende es ohne den Beta-Header oder das block_binding-Feld an Claude Fable 5.1. Eine 400-Antwort, die den Header nennt, bedeutet, dass die Prüfung für dein Konto standardmäßig durchgesetzt wird. Eine 200-Antwort bedeutet, dass das nicht der Fall ist. Zur Bestätigung sende dieselbe Anfrage erneut mit dem Beta-Header, weiterhin ohne block_binding: Die Antwort listet jeden Thinking-Block nach deiner Bearbeitung in input_transformations als thinking_mismatch_allowed auf.

Was als Bearbeitung zählt

Jede Zeile vergleicht zwei aufeinanderfolgende Anfragen:

Prüfen, ob dein Code das Präfix bearbeitet

Vergleiche zuerst, was du sendest. Zeichne die Anfrage-Bodys auf, die deine Integration über einige normale Turns sendet, einschließlich einer Komprimierung oder einer Tool-Änderung. Vergleiche für jedes Paar aufeinanderfolgender Anfragen system, tools und die messages, die sie gemeinsam haben. Sie sollten bis auf die neu angehängten Turns identisch sein.

Bestätige es dann gegen die API. Füge den Beta-Header thinking-binding-controls-2026-08-01 hinzu, setze prefix_mismatch_behavior auf "drop_block" und führe eine normale Multi-Turn-Sitzung über deine Integration auf claude-fable-5-1 aus. Das folgende Beispiel führt zwei Turns so aus, wie es deine Integration tun sollte: messages wächst nur, jeder Assistant-Turn geht genau so zurück, wie die API ihn zurückgegeben hat, einschließlich der thinking-Blöcke, und block_binding ist bei jeder Anfrage gesetzt. Nach jedem Turn gibt es die Anzahl der thinking-Blöcke in der Antwort und die Anzahl der entfernten Blöcke aus:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many of those are odd?",
]

# messages wächst über die Turns: jeder Assistant-Turn wird genau so zurückgegeben, wie er kam
messages = []
for user_turn in user_turns:
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    dropped = len(response.input_transformations or [])
    print(f"thinking blocks: {thinking_blocks}, dropped: {dropped}")

thinking blocks: 1, dropped: 0
thinking blocks: 1, dropped: 0

Keiner der beiden Turns entfernt einen Block, weil sich nichts Früheres geändert hat. Prüfe, ob die erste Antwort einen thinking-Block enthält. Bei adaptivem Nachdenken haben manche Antworten keinen. Wenn keine Antwort in der Sitzung einen hat, gibt es nichts zu prüfen, und die Anzahl der entfernten Blöcke ist 0, egal was du änderst. Führe das Beispiel dann erneut aus.

Protokolliere input_transformations bei jedem Turn deiner eigenen Integration. Wenn die API einen Block entfernt, sieht der Eintrag wie folgt aus:

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

• Leer bei jedem Turn einer Sitzung, die thinking-Blöcke enthält: Deine Integration lässt das Präfix intakt.
• reason: "prefix_binding_mismatch": Etwas vor dem Block bei path hat sich seit der vorherigen Anfrage geändert. Vergleiche system, tools und messages bis zu diesem Turn, um es zu finden, oder sende die Anfrage erneut mit "error": Der 400 endet normalerweise mit einem Satz, der benennt, was sich geändert hat. Suche dann den passenden Ersatz in Änderungen vornehmen, ohne das Präfix zu bearbeiten.
• reason: "model_binding_mismatch": Das Gespräch ist zu einem Modell gewechselt, das die Blöcke des früheren Modells nicht lesen kann. Das ist keine Präfixbearbeitung. Siehe Modellwechsel mitten im Gespräch.
• reason: "organization_binding_mismatch": Der Block stammt von einem anderen Konto. Siehe Thinking-Blöcke bleiben bei dem Konto, das sie erzeugt hat.

Um absichtlich einen Fehler zu sehen, sende einen dritten Turn aus dem vorherigen Beispiel und füge nur dieser Anfrage einen system-Prompt hinzu, sodass sie sich von den ersten beiden Anfragen unterscheidet, die keinen hatten. Mit "drop_block" ist die Anzahl der entfernten Blöcke nicht mehr 0: Die Antwort hat einen Eintrag für jeden Thinking-Block im Verlauf, jeweils mit reason: "prefix_binding_mismatch". Mit "error" gibt die Anfrage den 400 zurück, der in Was die API mit einem ungültigen Block macht beschrieben ist, und sein letzter Satz nennt den system-Prompt. Entferne in den cURL- und CLI-Tabs den jq-Filter, um den Fehler-Body zu sehen. Wenn die Anzahl immer noch 0 ist, gab es nichts zu prüfen: Bestätige, dass das Modell claude-fable-5-1 ist, dass die Anfrage block_binding setzt, dass der gesendete Verlauf thinking-Blöcke enthält und dass die ersten beiden Anfragen keinen system-Prompt hatten.

Zwei einfache Turns zeigen das Problem selten. Führe eine Sitzung durch jeden der folgenden Fälle aus, mit gesetztem "error", damit eine Regression deine CI fehlschlagen lässt:

• Die erste clientseitige Komprimierung oder Kürzung
• Ein Tool, Plugin oder MCP-Server, der sich nach dem ersten Turn verbindet
• Eine Modus- oder Anweisungsänderung
• Eine lange Tool-Schleife, wenn du Erinnerungen hinzufügst oder alte Tool-Ergebnisse kürzt
• Ein Wechsel zu einem anderen Modell und zurück
• Ein Speichern, ein Neustart und ein Fortsetzen an einem späteren Datum

Auf einem älteren Konto kannst du auch den Produktionsverkehr beobachten, ohne die Durchsetzung zu aktivieren: Sende den Beta-Header, lass block_binding weg und protokolliere input_transformations. Das Senden des Headers allein ändert nicht, was das Modell erhält. Jeder Thinking-Block, der nach dem bearbeiteten Inhalt kommt, besteht die Prüfung nicht und erhält einen eigenen thinking_mismatch_allowed-Eintrag mit denselben Feldern path und reason wie ein thinking_dropped-Eintrag. Blöcke vor der Bearbeitung bestehen weiterhin. Eine Bearbeitung an system oder tools kommt vor jedem Block, sodass jeder Thinking-Block in der Anfrage die Prüfung nicht besteht. Ein Eintrag sieht so aus:

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

Führe das folgende Beispiel von einem älteren Konto aus, da ein neueres Konto seine dritte Anfrage mit dem 400 ablehnt. Es sendet den Header ohne block_binding und erweitert die vorherige Sitzung um eine dritte Anfrage, die einen System-Prompt hinzufügt, was das Präfix absichtlich ändert. Nach jedem Turn gibt es die Anzahl der thinking-Blöcke und der markierten Blöcke aus:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many of those are odd?",
    "And how many of the odd ones are below 100?",
]

# messages wächst über die Turns hinweg: Jeder Assistant-Turn wird genau so zurückgegeben, wie er kam
messages = []
for turn, user_turn in enumerate(user_turns, start=1):
    messages.append({"role": "user", "content": user_turn})
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        thinking={"type": "adaptive"},
        # Nur die letzte Anfrage fügt einen System-Prompt hinzu, was das Präfix absichtlich ändert
        system="Answer briefly." if turn == len(user_turns) else anthropic.omit,
        messages=messages,
        betas=["thinking-binding-controls-2026-08-01"],
    )
    messages.append({"role": "assistant", "content": response.content})
    thinking_blocks = sum(block.type == "thinking" for block in response.content)
    flagged = sum(
        transformation.type == "thinking_mismatch_allowed"
        for transformation in response.input_transformations or []
    )
    print(f"thinking blocks: {thinking_blocks}, flagged: {flagged}")

thinking blocks: 1, flagged: 0
thinking blocks: 1, flagged: 0
thinking blocks: 1, flagged: 2

Die dritte Antwort markiert jeden Thinking-Block aus den früheren Turns, in diesem Lauf einen pro Turn, weil der neue System-Prompt vor allen steht. Das Modell hat sie trotzdem gelesen.

Behandle diese Einträge wie prefix_binding_mismatch-Entfernungen. Die Bearbeitung liegt vor dem ersten aufgeführten Block: Vergleiche system, tools und messages bis zum path dieses Blocks mit der vorherigen Anfrage, um sie zu finden, und ersetze sie dann durch das passende Muster in Änderungen vornehmen, ohne das Präfix zu bearbeiten. Auf einem neuen Konto oder bei jeder Anfrage, die prefix_mismatch_behavior setzt, lehnt die API die Anfrage stattdessen ab oder entfernt die fehlschlagenden Blöcke. Die Einträge sind eine Untergrenze dessen, was die Durchsetzung entfernen würde: Mit "drop_block" nimmt ein fehlschlagender Block auch die restlichen Thinking-Blöcke dieses Turns mit, und das Entfernen eines Blocks kann dazu führen, dass auch der nächste fehlschlägt. Wenn die API die Prüfung nur protokolliert, beurteilt sie jeden Block für sich und listet einen Block nur auf, wenn dieser Block fehlschlägt.

Änderungen vornehmen, ohne das Präfix zu bearbeiten

Für jede häufige Präfixbearbeitung gibt es einen Ersatz, der dem Modell dieselben Informationen gibt und frühere Bytes unverändert lässt, sodass späteres Nachdenken gültig bleibt. Suche die Bearbeitung, die dein Code heute vornimmt, in der ersten Spalte:

All dies setzt voraus, dass du Assistant-Turns genau so zurücksendest, wie sie zurückgegeben wurden. Systemnachrichten mitten im Gespräch, Turn-bezogene Systemnachrichten und Tool-Änderungen sind nicht auf jedem Modell verfügbar: System-Nachrichten und Tool-Änderungen mitten im Gespräch listet die Modelle auf, die sie akzeptieren. Wenn dein Code mehrere Modelle bedient, bearbeite für die Modelle, die sie nicht akzeptieren, weiterhin den system-Prompt auf oberster Ebene.

Um auf der Claude API mehrere Betas in einer Anfrage zu verwenden, kombiniere ihre Namen in einem anthropic-beta-Header:

anthropic-beta: thinking-binding-controls-2026-08-01,mid-conversation-system-clear-at-2026-08-21,inline-tools-2026-09-15

Andere Plattformen, die diese Betas anbieten, verwenden dieselben Namen. Wie du sie dort sendest, erfährst du unter Beta-Funktionen auf anderen Plattformen.

Assistant-Turns genau so zurücksenden, 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. Ein Serializer, der unbekannte Blocktypen oder leere Felder entfernt oder Blöcke umordnet, bearbeitet das Präfix für jeden späteren Turn.

Auf Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 und Claude Haiku 5.5 ist das thinking-Feld standardmäßig leer, und die signature trägt das Nachdenken, sodass ein Serializer, der leere Blöcke überspringt, Nachdenken entfernt. Wenn er alle entfernt, schlägt nichts fehl, und das Modell verliert bei jedem Turn sein früheres Nachdenken. Wenn du den Stream selbst parst, behalte den Block auch dann, wenn kein Nachdenk-Text ankommt: Er öffnet sich, erhält seine signature in einem signature_delta-Event und schließt sich. Ein Block, der mit einer leeren signature zurückgesendet wird, schlägt fehl.

Anweisungen mit einer Systemnachricht mitten im Gespräch hinzufügen

Manche Harnesses bauen den system-Prompt auf oberster Ebene bei jeder Anfrage neu auf, um die aktuelle Uhrzeit, ein Token-Budget, ein Modus-Flag oder neu entdeckten Projektkontext mitzuführen. Das macht jeden Thinking-Block im Gespräch ungültig. Friere stattdessen system zu Beginn der Sitzung ein. Wenn sich etwas ändert, hänge eine role: "system"-Nachricht an der Stelle in messages an, an der die Änderung zutrifft:

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

Das Modell behandelt diese Nachricht mit der Autorität eines System-Prompts, und alles davor bleibt unverändert. Platziere die Nachricht in einer Tool-Schleife nach der tool_result-Benutzernachricht, niemals zwischen einem Assistant-tool_use und seinem tool_result (siehe Einschränkungen). Sobald sie gesendet wurde, ist die Nachricht Teil des Präfixes für späteres Nachdenken: Lass sie bei späteren Anfragen an ihrem Platz.

Sich ändernden Kontext in den neuesten Turn setzen

Manche Harnesses setzen einen Umgebungsblock in die erste Benutzernachricht (Arbeitsverzeichnis, Branch, Datum, Speicher, Projektanweisungen) und rendern ihn bei jeder Anfrage neu. Wenn sich ein Wert ändert, ändert sich messages[0], und jeder Thinking-Block im Gespräch ist ungültig. Rendere diesen Block einmal und sende ihn so erneut, wie er war. Wenn sich ein Wert ändert, teile das im neuesten Turn mit: Füge der Benutzernachricht, die du gleich senden wirst, einen Textblock hinzu, oder hänge eine Systemnachricht mitten im Gespräch an, wenn die Änderung von dir als Betreiber kommt.

{
  "role": "user",
  "content": [
    {
      "type": "text",
      "text": "Environment update: the current branch is now release-2."
    },
    { "type": "text", "text": "Run the tests again." }
  ]
}

Sobald er gesendet wurde, ist dieser Textblock Teil des Präfixes für späteres Nachdenken: Lass ihn bei späteren Anfragen an seinem Platz.

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

Eine häufige Präfixbearbeitung ist der Hinweis pro Turn: eine Zeile wie „fordere unabhängige Lesevorgänge gemeinsam an" oder „du hast den Benutzer schon eine Weile nicht mehr informiert", die dein Code nach jedem Stapel von Tool-Ergebnissen anhängt. Damit sich Erinnerungen nicht anhäufen, sende jeden Hinweis als Systemnachricht mitten im Gespräch mit clear_at: "next_user_message", platziert nach der tool_result-Benutzernachricht. clear_at erfordert den Beta-Header mid-conversation-system-clear-at-2026-08-21. Das folgende messages-Array ist die Anfrage nach zwei Tool-Aufrufen und ihren Ergebnissen. messages[3] ist der Hinweis der vorherigen Anfrage, der an seinem Platz bleibt, 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 Benutzernachricht, die nur tool_result-Blöcke enthält, zählt als „nächste Benutzernachricht", sodass messages[3] bereits gelöscht ist. Sie fügt dem, was das Modell sieht, nichts hinzu und kostet keine Input-Token, aber weil sie noch im Array ist, bleibt das Nachdenken in messages[4] gültig. messages[6] ist die Kopie, die das Modell in diesem Turn sieht. Behalte bei späteren Anfragen beide an ihrem Platz und hänge nach der nächsten tool_result-Nachricht eine neue Kopie an.

Tools mit tool_addition und tool_removal hinzufügen oder entfernen

Das Bearbeiten des tools-Arrays mitten in einer Sitzung macht bewahrte Thinking-Blöcke ungültig. Lass das Array so, wie du es zuerst gesendet hast, und ändere, welche Tools das Modell verwenden kann, indem du eine role: "system"-Nachricht anhängst, die tool_addition- oder tool_removal-Blöcke trägt. Dies sind Tool-Änderungen mitten im Gespräch und benötigen den Beta-Header inline-tools-2026-09-15, der auf der Claude API verfügbar ist. Der ältere Header mid-conversation-tool-changes-2026-07-01 funktioniert weiterhin für Änderungen, die ein Tool per Referenz benennen, auf der Claude API, Amazon Bedrock und Google Cloud.

Du hast zwei Möglichkeiten, diese Blöcke zu verwenden:

• Deklariere jedes Tool im Voraus. Setze jedes Tool, das die Sitzung benötigen könnte, bei der ersten Anfrage in tools, mit defer_loading: true bei allen, die das Modell noch nicht sehen soll. Schalte Tools dann mit tool_addition- und tool_removal-Blöcken, die sie benennen, ein und aus.
• Beginne mit einem Snapshot und füge Tools nach und nach hinzu. Setze die Tools, die du kennst, bei der ersten Anfrage in tools. Wenn ein neues Tool hinzukommt, definiere es in einem tool_addition-Block, statt tools zu bearbeiten.

In beiden Fällen ändert sich tools nie, sodass früheres Nachdenken gültig bleibt und der Prompt-Cache weiterhin trifft, mit der einen Ausnahme, die später in diesem Abschnitt erwähnt wird.

Zum Beispiel, um ein gefährliches Tool nach einem Moduswechsel zurückzuziehen:

{
  "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." }
  ]
}

Um ein Tool einzuschalten, das du mit defer_loading: true deklariert hast, hänge einen tool_addition-Block an, der es benennt:

{
  "role": "system",
  "content": [
    { "type": "tool_addition", "tool": { "type": "tool_reference", "name": "deploy" } },
    { "type": "text", "text": "Authentication succeeded. Deployment is now available." }
  ]
}

Manchmal kannst du ein Tool nicht im Voraus deklarieren, weil du sein Schema noch nicht kennst: ein Tool, das deine Anwendung zur Laufzeit entdeckt, oder ein MCP-Server, der sich nach dem ersten Turn verbindet. Definiere es im tool_addition-Block, statt tools anzufassen. Mit inline-tools-2026-09-15 kann das tool des Blocks {"type": "tool_definition", "definition": {...}} sein und denselben Eintrag enthalten, den du in tools gesetzt hättest:

{
  "role": "system",
  "content": [
    {
      "type": "tool_addition",
      "tool": {
        "type": "tool_definition",
        "definition": {
          "name": "db_query",
          "description": "Run a read-only SQL query against the analytics database.",
          "input_schema": {
            "type": "object",
            "properties": { "sql": { "type": "string" } },
            "required": ["sql"]
          }
        }
      }
    }
  ]
}

Das neue Tool kommt in messages an, tools ändert sich nie, und früheres Nachdenken bleibt gültig. Behalte mindestens ein Tool ohne defer_loading: true in tools: Wenn jedes Tool dort zurückgestellt ist, kostet das erste Tool, das du auf diese Weise definierst, einen vollständigen Prompt-Cache-Miss.

Wenn die API sich über den MCP-Connector für dich mit dem MCP-Server verbindet, sende zusätzlich mcp-client-2026-09-15. Er deckt alles ab, was mcp-client-2025-11-20 abdeckt, also sende ihn anstelle von diesem. Die definition des Blocks kann dann ein mcp_toolset für einen in mcp_servers aufgeführten Server sein. Wenn die API die Tool-Liste eines Servers abrufen muss, beginnt die Antwort mit einem mcp_tool_listing-Block für diesen Server. Sende ihn unverändert mit dem Rest des Assistant-Turns zurück und sende mcp-client-2026-09-15 bei jeder späteren Anfrage, die ihn enthält, weiterhin mit. Der Block fixiert das Toolset auf diese Liste, sodass die API den Server dafür nicht erneut kontaktiert. Diese MCP-Connector-Funktionen sind auf der Claude API verfügbar.

Nur mit dem älteren Header kannst du ein Tool, von dem du mitten in der Sitzung erfährst, trotzdem mit defer_loading: true an tools anhängen und es dann mit einem tool_addition-Block anbieten. Das ist sicher, weil die Präfixprüfung ein zurückgestelltes Tool ignoriert, bis ein tool_addition-Block darauf verweist. Das Hinzufügen eines Tools ohne defer_loading: true ändert das Präfix und macht früheres Nachdenken ungültig.

Die role: "system"-Nachrichten, die diese Blöcke enthalten, werden Teil des Präfixes für späteres Nachdenken. Lass sie bei späteren Anfragen an ihrem Platz.

Effort mit einer output_config pro Nachricht ändern

Das Ändern von output_config.effort auf oberster Ebene zwischen Anfragen macht das Nachdenken nicht ungültig, weil Effort nicht Teil des Präfixes ist. Das Ändern des Efforts auf oberster Ebene startet jedoch den Prompt-Cache neu. Wo Modell und Plattform Effort pro Nachricht unterstützen, verwende stattdessen diesen: Hänge eine role: "system"-Nachricht mit leerem content und der neuen Stufe an. Dafür wird der Beta-Header mid-conversation-output-config-2026-07-01 benötigt. Auf Claude Haiku 5.5 ist Effort pro Nachricht auf der Claude API und Google Cloud verfügbar und erfordert adaptives Nachdenken.

{ "role": "system", "content": [], "output_config": { "effort": "low" } }

Wann die neue Stufe wirksam wird, hängt davon ab, wo du die Nachricht platzierst. Direkt nach einer user-Nachricht mit neuer Eingabe gilt die Stufe ab Claudes Antwort auf diese Nachricht. An jeder anderen Stelle, etwa nach einer assistant-Nachricht oder nach einer user-Nachricht, die nur tool_result-Blöcke enthält, gilt sie ab der nächsten user-Nachricht mit neuer Eingabe, sodass eine bereits laufende Tool-Schleife bis dahin die aktuelle Stufe beibehält. Sobald die Nachricht gesendet wurde, ist sie Teil von messages und damit Teil des Präfixes für späteres Nachdenken: Lass sie bei späteren Anfragen an ihrer Stelle und hänge eine weitere an, um den Effort erneut zu ändern.

Kontext auf dem Server kürzen

Eine weitere häufige Präfixbearbeitung ist das clientseitige Kürzen: die ältesten Turns entfernen oder zusammenfassen und die neueren wörtlich behalten. Die Thinking-Blöcke der behaltenen Turns wurden erzeugt, als der entfernte Verlauf noch vorhanden war, daher bestehen sie die Prüfung nicht. Die serverseitigen Entsprechungen zählen nicht als Bearbeitungen, weil die Prüfung das Gespräch so vergleicht, wie du es gesendet hast:

• Compaction auf Anfrage (Beta) gibt die Zusammenfassung aus einer separaten Anfrage zurück, die im Hintergrund laufen kann, und du sendest den zurückgegebenen Block anstelle der Nachrichten, die er zusammenfasst. Die Prüfung akzeptiert diesen Austausch, sodass die Turns, die du behältst, mit ihrem Nachdenken gültig bleiben können, unter den Bedingungen für beibehaltenes Nachdenken. Eine Zusammenfassung anfordern zeigt die Anfrage und benennt den Beta-Header, den sie benötigt.
• Komprimierung bei einem Token-Schwellenwert fasst ältere Turns in einen Komprimierungsblock zusammen, wenn sich der Kontext einem von dir festgelegten Schwellenwert nähert, und das geprüfte Präfix startet ab diesem Block neu. Sein instructions-Parameter nimmt deinen eigenen Zusammenfassungs-Prompt entgegen, wie etwa „bewahre jeden Ticker, jede Positionsgröße und jede angegebene Annahme".
• Kontextbearbeitung löscht alte Tool-Ergebnisse oder alte Thinking-Blöcke nach Regel, die ältesten zuerst. Die Strategien sind clear_tool_uses_20250919 und clear_thinking_20251015.

Auf dem Client komprimieren

Du kannst weiterhin auf dem Client kompaktieren. Wenn du die Zusammenfassung selbst schreibst, sende keinen Thinking-Block zurück, der vor der Neuschreibung erzeugt wurde. Wenn die API sie mit Compaction auf Anfrage schreibt, listet Bedingungen, unter denen beibehaltenes Thinking gültig bleibt auf, wann beibehaltenes Nachdenken gültig bleibt.

Einfache Komprimierung (empfohlen)

Wenn die Konversation zu lang wird, fasse die gesamte Sitzung in einer Benutzernachricht zusammen und sende nur diese Nachricht plus die nächste Anweisung. Nichts Früheres wird erneut abgespielt, daher bleibt kein Nachdenken übrig, das die Prüfung nicht bestehen könnte, und das Modell denkt ausgehend von der Zusammenfassung neu nach.

[
  {
    "role": "user",
    "content": "<summary of the session so far>\n\n<the next instruction>"
  }
]

Claude-Modelle werden mit diesem Schema auf Aufgaben mit langem Zeithorizont trainiert, und für die meisten Workloads funktioniert es gut.

Keep-Tail-Komprimierung

Keep-Tail-Komprimierung fasst die älteren Turns zusammen und behält die neuesten Turns wörtlich, sodass das Modell die letzten Wortwechsel weiterhin Wort für Wort sieht. Wenn du die Zusammenfassung selbst schreibst, verstößt das gegen die Regel: Die behaltenen Assistant-Turns enthalten weiterhin Thinking-Blöcke, die erzeugt wurden, als die ursprünglichen Turns und nicht die Zusammenfassung vor ihnen standen. Diese Blöcke bestehen die Prüfung nicht.

Um dieses Nachdenken zu behalten, lass die API die Zusammenfassung mit Compaction auf Anfrage schreiben. Komprimierung, die die letzten Turns beibehält zeigt, wie das geht, und Bedingungen, unter denen beibehaltenes Thinking gültig bleibt listet auf, wann das behaltene Nachdenken gültig bleibt.

Der Rest dieses Abschnitts behandelt eine Zusammenfassung, die du selbst schreibst.

Lösung: Behalte die Turns genau so, wie sie sind, und sende prefix_mismatch_behavior: "drop_block". Die API verwirft die veralteten Thinking-Blöcke, das Modell liest die text- und tool_use-Blöcke der behaltenen Turns, und die Anfrage ist erfolgreich.

Übergib den komprimierten Verlauf als messages und setze block_binding in der thinking-Konfiguration. Im folgenden Beispiel ist compacted_messages das Array, das dein Komprimierungsschritt erzeugt hat: die Zusammenfassungsnachricht, gefolgt von den behaltenen Turns genau so, wie die API sie zurückgegeben hat, einschließlich der thinking-Blöcke:

client = anthropic.Anthropic()

# compacted_messages: die Zusammenfassungsnachricht, dann die beibehaltenen Turns wie zurückgegeben
response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {"prefix_mismatch_behavior": "drop_block"},
    },
    messages=compacted_messages,
    betas=["thinking-binding-controls-2026-08-01"],
)

print(response.input_transformations)

Die Antwort enthält wie üblich den neuen Assistant-Turn sowie einen input_transformations-Eintrag pro verworfenem Block. Für den Verlauf im Diagramm ist das das Nachdenken bei den Assistant-Turns 3 und 4:

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

Sende "drop_block" bei späteren Anfragen weiter, solange diese beiden Turns im Verlauf bleiben. Nachdenken, das das Modell ab dieser Anfrage erzeugt, folgt auf die Zusammenfassung und bleibt gültig. Wenn du nicht vom Beta-Header abhängig sein möchtest, besteht die Alternative darin, die thinking- und redacted_thinking-Blöcke selbst aus den behaltenen Assistant-Turns zu entfernen, wenn du den komprimierten Verlauf erstellst.

Hintergrund-Komprimierung (asynchron)

Die Hintergrund-Komprimierung baut die Zusammenfassung abseits des kritischen Pfads auf, während das Gespräch weitergeht, und tauscht sie dann ein paar Anfragen später ein. Um das in der Zwischenzeit erzeugte Nachdenken zu behalten, lass die API die Zusammenfassung mit Compaction auf Anfrage schreiben: Komprimierung im Hintergrund enthält die Schritte, und dieses Nachdenken bleibt unter denselben Bedingungen für beibehaltenes Nachdenken gültig wie beibehaltene letzte Turns.

Eine selbst erstellte Zusammenfassung verstößt auf dieselbe Weise gegen die Regel wie Keep-Tail, nur verzögert: Jeder Assistenten-Turn, der erzeugt wurde, während die Zusammenfassung erstellt wurde, enthält Thinking, das vor dem Austausch entstanden ist, und all das schlägt fehl, sobald die Zusammenfassung eingesetzt wird. Wenn du eine solche verwendest, behandle den Austausch wie Keep-Tail und sende ab dem Austausch "drop_block", oder komprimiere synchron.

Muster, die mit Preserved Thinking nicht funktionieren

• Turns aus der Mitte herausschneiden. Das Entfernen einzelner Turns macht jeden Thinking-Block danach ungültig, und kein Komprimierungsschema vermeidet das. Wenn du einen Turn herausgeschnitten hast, um eine Anweisung zu ändern, hänge stattdessen eine Systemnachricht mitten im Gespräch an. Um alte Tool-Ergebnisse oder altes Thinking gezielt zu entfernen, verwende serverseitiges „context editing“ (Kontextbearbeitung).
• Komprimieren mitten in einer Tool-Runde. Komprimiere nicht zwischen dem tool_use eines Assistenten-Turns und dem tool_result, das darauf antwortet. Sende diesen Assistenten-Turn mit intaktem Thinking zurück, damit das Modell die Runde mit seinem Reasoning abschließt. Siehe Thinking-Blöcke bewahren.

Dateien per ID referenzieren, nicht über eine URL, deren Inhalt sich ändert

Bei einem image- oder document-Block mit einer url-Quelle umfasst die Prüfung die abgerufenen Bytes, nicht den URL-String. Eine URL, deren Inhalt sich ändert, macht späteres Thinking ungültig: ein „latest screenshot“-Endpunkt oder ein Dokument, das jemand zwischen Turns bearbeitet. Eine rotierende signierte URL für dieselbe Datei tut das nicht. Für Inhalte, die du über mehrere Turns hinweg referenzierst, lade sie einmal mit der Files API hoch und verwende die file_id, oder sende Base64.

Bibliotheken, Proxys und Gateways

Eine Bibliothek, ein Proxy oder ein Gateway sitzt zwischen dem Verlauf einer anderen Person und der API, daher zählen seine eigenen Umschreibungen als Bearbeitungen, und seine Nutzer können sie weder sehen noch beheben.

• Leite weiter, was du nicht erkennst. Leite die anthropic-beta-Werte und thinking.block_binding des Aufrufers unverändert weiter und gib input_transformations an ihn zurück. Ein Optionsschema, das unbekannte Schlüssel ablehnt, hindert deine Nutzer daran, "drop_block" zu wählen.
• Lass eine role: "system"-Nachricht dort, wo der Aufrufer sie platziert hat. Wenn du sie in das Top-Level-Feld system verschiebst, ändert sich system bei dieser Anfrage, und jeder Thinking-Block in der Konversation wird ungültig.
• Um die Tool-Nutzung für eine Anfrage zu deaktivieren, sende tool_choice: {"type": "none"}. Entferne nicht tools.
• Verstecke den 400-Fehler nicht. Wenn dein Code ihn abfängt, Thinking entfernt und im Namen des Aufrufers erneut versucht, protokolliere das: Sein Verlauf ist trotzdem bearbeitet, und das Modell verliert bei jeder späteren Anfrage sein früheres Reasoning.

FAQ

Nächste Schritte