Einen Thinking-Block beheben, der an eine andere Konversation gebunden ist

Dieselbe Anfrage erneut zu senden, kann nicht funktionieren, weil dein Verlauf immer noch enthält, was dein Code geändert hat. Sende "drop_block" (Fehler jetzt stoppen). Die langfristige Lösung besteht darin, deinen Code „append-only“ (nur anhängend) zu machen.

Fehler: The block is bound to a different conversation

Der Thinking-Block hat die „prefix check“ (Präfixprüfung) nicht bestanden: Etwas vor ihm hat sich geändert, nachdem Claude ihn erzeugt hat (siehe Was als Änderung zählt), oder ein Thinking-Block zwischen anderen wurde weggelassen oder verschoben. Der Fehler sieht so aus und kann außerdem benennen, was sich geändert hat:

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

„A different conversation“ bedeutet anderen Inhalt vor dem Block: Die Präfixprüfung vergleicht keine Sitzungen oder Benutzer. Die Fehlermeldung sagt, dass du den Block entfernen sollst, aber nur diesen Block zu entfernen, reicht nicht aus. Andere Fehler können ähnlich aussehen.

Wenn die App nicht deine ist, starte eine neue Konversation und informiere ihren Maintainer. Wenn du ein Geheimnis, personenbezogene Daten oder eingeschleusten Text entfernt hast oder deine Anfragen das Nachdenken ausschalten, entferne das Nachdenken von Hand anstelle von Schritt 1.

1. 1

   Fehler jetzt stoppen

   Setze thinking.block_binding.prefix_mismatch_behavior auf "drop_block" und sende den Beta-Header anthropic-beta: thinking-binding-controls-2026-08-01. Tu dies bei jeder späteren Anfrage in der Konversation, weil die API die Einstellung zwischen Anfragen nicht speichert. Eine gespeicherte Konversation enthält die Änderung weiterhin, selbst nachdem du deinen Code behoben hast, also speichere die Einstellung mit ihr. Setze type auf "adaptive", wie gezeigt:

   {
     "thinking": {
       "type": "adaptive",
       "block_binding": {
         "prefix_mismatch_behavior": "drop_block"
       }
     }
   }

   

   Rufe im SDK die Beta-Messages-Methode auf und übergib den Header-Wert, wie es das Testprogramm tut. Wenn der Fehler immer noch nach dem Header fragt, ist der Header nicht angekommen.

   Das stoppt die Fehler, indem das ungültige Nachdenken weggelassen wird, aber es kann mehr kosten und kann die Ausgabequalität und die Latenz beeinflussen. Die nächste Anfrage ist erfolgreich, und ihr input_transformations-Array listet jeden Block auf, den die API weggelassen hat.

   Wenn deine Anfragen den Parameter thinking nicht setzen, ändert sein Hinzufügen sonst nichts, weil Modelle mit bewahrtem Nachdenken standardmäßig adaptiv nachdenken.

2. 2

   Langfristige Lösung

   Mache deine Integration append-only:

   1. Finde die Änderung. Der Fehler kann sie benennen. Um herauszufinden, wo dein Code sie vornimmt, führe claude update aus und führe dann /claude-api preserved-thinking-migration in Claude Code im Repository deines Codes aus. Oder suche von Hand.
   2. Höre auf, die Änderung vorzunehmen, sonst können auch neue Konversationen den Fehler bekommen. Sende stattdessen am Ende ein Update.
   3. Sende jeder laufenden Konversation weiterhin das system und die tools ihrer letzten erfolgreichen Anfrage.

Wenn die Änderung neu war, kannst du sie stattdessen rückgängig machen: Stelle wieder her, was dein Code geändert hat. Das Nachdenken von vor der Änderung ist dann wieder gültig. Nachdenken, das seitdem erzeugt wurde, besteht die Präfixprüfung nicht, also entferne es oder sende weiterhin "drop_block".

Was das Weglassen von Nachdenken kostet

Claude kann mehr Ausgabe-Token dafür aufwenden, Reasoning zu erarbeiten, das es nicht mehr lesen kann. Das Weglassen der Blöcke macht außerdem den Prompt-Cache ab dem ersten weggelassenen Block ungültig.

Wenn sich bei jedem Turn etwas ändert, verliert jeder Turn das Nachdenken aus früheren Turns, sodass sich der Anstieg wiederholt. Führe Evals mit deiner eigenen Arbeitslast durch, bevor du dich auf "drop_block" verlässt.

Verwende "drop_block", um bestehende Konversationen am Laufen zu halten, während sie eine Änderung enthalten, die du behebst, und für ein geplantes Weglassen, etwa nach deiner eigenen Zusammenfassung. Lass es nicht eingeschaltet, um eine Änderung zu verbergen, die dein Code immer wieder vornimmt. Du kannst aufhören, es zu senden, sobald die ungültigen Blöcke aus dem Verlauf entfernt sind.

Finde heraus, was dein Code geändert hat

Die Änderung liegt vor dem ersten Block, den die API benennt. Der 400-Fehler kann sagen, was sich geändert hat, etwa system, tools, ein fehlender Thinking-Block oder die erste Nachricht, die sich unterscheidet. Wenn es keinen Fehler gibt oder einen, der es nicht sagt, beginne mit dem, was du hast, etwa einem prefix_binding_mismatch-Eintrag oder mehr Ausgabe-Token.

Teste deinen Code auf nicht bestandene Präfixprüfungen

Du kannst einem Test vertrauen, sobald du ihn hast fehlschlagen sehen. Führe zuerst über deinen eigenen Code eine Sitzung aus, die Claude zum Nachdenken bringt, und ändere absichtlich etwas. Sende für diesen Schritt "drop_block", damit die Antwort jeden ungültigen Block auflistet, statt beim ersten anzuhalten, wie fünf Schritte und ein Programm zeigen.

Nimm diese Änderung dann wieder heraus und führe deine echten Sitzungen aus. Sende bei jeder Anfrage den Beta-Header thinking-binding-controls-2026-08-01 und setze prefix_mismatch_behavior auf "error", damit eine Änderung, die dein Code in diesen Sitzungen vornimmt, den Build mit dem 400-Fehler fehlschlagen lässt.

Teste Sitzungen, die komprimieren, spät Tools hinzufügen, Anweisungen ändern, Modelle wechseln oder fortgesetzt werden: Einfache Turns erreichen diesen Code nicht.

Ein sauberer Durchlauf hat keinen prefix_binding_mismatch-Eintrag und keinen Fehler. Er zeigt nur, dass die Blöcke, die er geprüft hat, gültig sind, und zwar in den Sitzungen, die du ausgeführt hast. Er beweist nichts, wenn:

• die Sitzung keine Thinking-Blöcke hatte
• dein Code das gesamte Nachdenken entfernt oder das Modell kein bewahrtes Nachdenken hat
• du den Beta-Header nicht gesendet hast und das Modell Blöcke, die die Präfixprüfung nicht bestehen, möglicherweise ohne Fehler durchlässt

Überwache die Produktion und finde Reasoning, das ohne Fehler verloren ging

Protokolliere jeden 400-Fehler und behandle ihn im Code, damit die Konversation weiterläuft. Wenn du prefix_mismatch_behavior stattdessen nicht setzt, überwache den Produktions-Traffic auf Nachdenken, das die Präfixprüfung nicht besteht und Claude erreicht hat.

Reasoning kann ohne Fehler verloren gehen durch "drop_block", ein Batch-Element, einen Modellwechsel, einen Wechsel zu einem anderen Konto oder Code, der kein Nachdenken zurücksendet. Mit dem Beta-Header hinterlässt jeder davon einen Eintrag, außer dem letzten. Prüfe für diesen, dass deine Anfragen thinking-Blöcke enthalten.

Technische Details

Was die Fehlermeldung sonst noch sagen kann

Die Fehlermeldung benennt außerdem, was sich geändert hat, sofern die API es erkennen kann, etwa system, tools, die erste Nachricht oder den ersten Block, der sich unterscheidet, Inhalt, der fehlt oder neu ist, oder einen früheren Thinking-Block, der fehlt oder nicht in der richtigen Reihenfolge ist. Der Wortlaut dieses Satzes kann sich ändern, also gleiche nicht darauf ab. Wenn die Anfrage keinen Beta-Header hatte, fügt die Fehlermeldung diesen Satz hinzu:

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

Der Fehler fragt immer noch nach dem Header oder sagt Extra inputs are not permitted

Wenn der Fehler immer noch nach dem Header fragt, hat der Header die API nicht erreicht: Ein Proxy oder eine Bibliothek könnte ihn entfernt haben. Ein anderer Fehler, der mit block_binding: Extra inputs are not permitted endet, bedeutet dasselbe oder dass das Nachdenken ausgeschaltet ist.

Das ungültige Nachdenken von Hand entfernen

Verwende dies dort, wo du die Einstellung nicht senden kannst, oder in einem dieser Fälle:

• Nachdem du ein Geheimnis, personenbezogene Daten oder eingeschleusten Text entfernt hast, weil "drop_block" das Nachdenken in deinem gespeicherten Verlauf belässt.
• Wenn das Nachdenken ausgeschaltet ist ("disabled" oder "between_tools"), weil "drop_block" "adaptive" benötigt, was das Nachdenken einschalten und Ausgabe-Token hinzufügen würde.

1. Entferne den Block, den der Fehler benennt, und jeden thinking- und redacted_thinking-Block danach, sonst benennt derselbe Fehler anschließend den nächsten ungültigen. Wenn dein Verlauf jedoch role: "system"-Nachrichten oder zwei Nachrichten derselben Rolle hintereinander enthält, entferne jeden thinking- und redacted_thinking-Block. Der Fehler zählt eine solche Nachricht als Teil der Nachricht davor, sodass die Position, die er benennt, niedriger sein kann als der Index in deinem Array. Der path eines input_transformations-Eintrags zählt jede Nachricht separat.
2. Behalte jeden anderen Block und sende die Anfrage erneut. Füge die entfernten Blöcke nicht wieder ein.

Fehler, die diesem ähneln

Diese Fehler sagen nicht, dass der Block an eine andere Konversation gebunden ist, und das Setzen von prefix_mismatch_behavior behebt sie möglicherweise nicht:

• Eine Nachricht, die nach „Invalid signature in thinking block“ endet, „cannot be modified“ sagt oder sich auf budget_tokens bezieht: Fehlerbehebung beim Nachdenken
• Eine Nachricht zu temperature oder einer vorausgefüllten Antwort: Limits und Funktionskompatibilität

Wann du aufhören kannst, "drop_block" zu senden

Um aufzuhören, "drop_block" zu senden, entferne die Blöcke, die es weglässt, und behalte das seitdem erzeugte Nachdenken. Wenn sich sonst nichts geändert hat, besteht die Konversation dann mit "error".

Den Fehler im Code behandeln

Um den Fehler im Code zu behandeln, sende bei jeder Anfrage den Beta-Header und "error", damit eine nicht bestandene Präfixprüfung bei jedem Modell ein 400-Fehler ist. Wenn er auftritt, stelle nur diese Konversation für jede spätere Anfrage auf "drop_block" um, speichere diese Wahl mit ihr, sende einmal erneut und protokolliere den Fehler. Wenn derselbe Fehler zurückkommt, hat die Einstellung die API nicht erreicht: siehe Der Fehler fragt immer noch nach dem Header oder sagt Extra inputs are not permitted.

Dein Code muss diesen Fehler an seinem message-Feld erkennen, die Ausnahme von dem allgemeinen Rat, nicht auf den Text eines Fehlers abzugleichen. Jeder 400-Fehler hat den Typ invalid_request_error, und dieser hat keinen error.details.error_code. Gleiche nur auf „The block is bound to a different conversation“ ab, weil sich der Rest der Meldung ändern kann.

Du hast keinen Fehler oder einen, der nicht sagt, was sich geändert hat

• Der 400-Fehler, und er benennt keine Änderung: Vergleiche die Anfragen selbst. Eine Ursache ist ein Komprimierungsblock, der gesendet wird, ohne die Nachrichten zu entfernen, die er zusammenfasst.

• Ein prefix_binding_mismatch-Eintrag: Vergleiche system, tools und messages bis zum path des ersten Eintrags mit der Konversation, wie sie war, als dieser Block erzeugt wurde. Wenn jeder Block aufgelistet ist, beginne mit system und tools.

  Wenn sich nichts unterscheidet, suche nach einer Bild- oder Dokument-URL, deren Inhalt sich geändert hat, der geänderten Tool-Liste eines MCP-Servers (siehe Die Tool-Liste eines MCP-Servers fixieren) oder einem Thinking-Block, der weggelassen, verschoben oder wieder eingefügt wurde. Ohne Anfrage-Logs sende die Anfrage erneut mit "error" und lies den Satz, der sagt, was sich unterscheidet, falls es einen gibt.

• Ein Proxy oder eine Bibliothek dazwischen, die nicht deine ist: Vergleiche, was sie sendet, mit dem, was du gesendet hast, und verweise ihren Maintainer auf Bibliotheken, Proxys und Gateways.

• Nur ein Verdacht und kein Claude Code: Zeichne die Anfrage-Bodies einer Konversation auf, einer mit einer Komprimierung oder einer Tool-Änderung. Vergleiche jeden mit dem vorherigen und lass dabei seine neuen Turns weg.

Fünf Schritte für einen Test, der fehlschlagen kann, und ein Programm, das sie ausführt

1. Sende in deinem eigenen Code bei jeder Anfrage einer Sitzung den Beta-Header und "drop_block" an ein Modell mit bewahrtem Nachdenken.
2. Verwende Prompts, die Claude zum Nachdenken bringen, und prüfe, dass die erste Antwort einen thinking-Block hat. Mit adaptivem Nachdenken kann Claude das Nachdenken bei einem einfachen Prompt überspringen.
3. Lass den Test nur bei einem input_transformations-Eintrag fehlschlagen, dessen Grund prefix_binding_mismatch ist. Ein Test, der ein leeres Array erwartet, schlägt auch nach einem Modellwechsel fehl, weil dann Einträge mit model_binding_mismatch oder organization_binding_mismatch zu erwarten sind.
4. Ändere absichtlich etwas, etwa indem du nur bei der dritten Anfrage einen system-Prompt hinzufügst.
5. Prüfe, dass input_transformations die Thinking-Blöcke auflistet, die nach der Änderung stehen. Wenn es keine auflistet, prüfe, dass der Verlauf einen Thinking-Block enthält.

Dieses Programm führt die Schritte 1, 2, 4 und 5 aus. Es gibt aus, wie viele Thinking-Blöcke und input_transformations-Einträge jede Antwort hat, und dann jeden Eintrag, was Schritt 3 prüft:

client = anthropic.Anthropic()

user_turns = [
    "How many positive integers below 500 have exactly 6 positive divisors?",
    "How many have exactly 8?",
    "How many have exactly 10?",
]

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-opus-5-5",
        max_tokens=16000,
        thinking={
            "type": "adaptive",
            "block_binding": {"prefix_mismatch_behavior": "drop_block"},
        },
        # 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)
    entries = response.input_transformations or []
    print(f"thinking blocks: {thinking_blocks}, entries: {len(entries)}")
    for entry in entries:
        if entry.type == "thinking_dropped":
            print(entry.type, entry.path, entry.reason)

thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 0
thinking blocks: 1, entries: 2
thinking_dropped messages.1.content.0 prefix_binding_mismatch
thinking_dropped messages.3.content.0 prefix_binding_mismatch

Mit "error" anstelle von "drop_block" bekommt die dritte Anfrage den 400-Fehler.

Was jeder input_transformations-Eintrag bedeutet und welche du beheben musst

Mit dem Beta-Header hat eine Antwort von einem Modell, das Nachdenken unterstützt, das input_transformations-Array neben usage. Es ist leer, wenn nichts weggelassen und nichts Ungültiges durchgelassen wurde. Beim Streaming befindet es sich in der message des message_start-Events; nach einem Fallback mitten im Stream enthält das abschließende message_delta-Event das maßgebliche. Anders als die Position im Fehler ist path immer die Stelle des Blocks, so wie du ihn gesendet hast:

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

Der type und reason jedes Eintrags und was sie bedeuten:

• thinking_dropped, prefix_binding_mismatch: Was vor diesem Block stand, ist nicht das, was er aufgezeichnet hat. Von dir zu beheben: Finde heraus, was dein Code geändert hat.
• thinking_mismatch_allowed, prefix_binding_mismatch: Dasselbe, aber Claude hat den Block unverändert gelesen, und er wird in Rechnung gestellt. Dieser Eintrag erscheint nur dort, wo die Einstellung nicht gesetzt ist, bei einigen Modellen. Von dir zu beheben.
• thinking_dropped, model_binding_mismatch: Dieses Modell kann keine Blöcke von dem Modell lesen, das ihn erzeugt hat. Nicht von dir zu beheben: Sende weiterhin die gesamte Konversation.
• thinking_dropped, organization_binding_mismatch: Ein anderes Konto hat den Block erzeugt, daher hat die API ihn weggelassen. Nicht von dir zu beheben.

Ignoriere einen Eintrag, dessen type oder reason du nicht kennst.

Batches und Token-Zählung

• Message Batches: Ein Element, das prefix_mismatch_behavior nicht setzt, bekommt nie den 400-Fehler. Die API lässt die ungültigen Blöcke weg oder kann sie bei einigen Modellen durchlassen. Ein Element, das "error" setzt, wird als errored abgeschlossen, wenn ein Block die Präfixprüfung nicht besteht. block_binding gehört in params.thinking des Elements.
• Token-Zählung: Auf der Claude API kann die Token-Zählung denselben 400-Fehler zurückgeben und akzeptiert prefix_mismatch_behavior unter demselben Header. Sie lässt weggelassene Blöcke bei der Zählung außen vor und gibt keine input_transformations zurück.

Nächste Schritte