Der Prefix-Check von Claude Fable 5.2: ein 400-Fehler, der davon abhängt, was dein Code im letzten Turn getan hat

Claude Fable 5.2 ist am 9. November erschienen, für $8 Input und $40 Output pro Million Tokens. Das ist weniger als die $10 und $50 von Fable 5.1 und immer noch doppelt so viel wie die Basispreise von Opus 5.5. Das meiste, was beim Umstieg bricht, scheitert schon beim ersten Request, der es berührt. Eine Änderung scheitert erst bei einem Request, der auf eine Bearbeitung der Konversation folgt.

Das ist der Prefix-Check. Im September habe ich geschrieben, dass ein 400 die gute Art von Bruch ist: sofort abgelehnt, mit der Lösung in der Meldung. Hier steht die Lösung auch in der Meldung, und trotzdem besteht der Check jeden frischen Test mit einem einzelnen Request. Er ist eine Eigenschaft der Konversation, nicht des Requests.

Welche Änderungen in Claude Fable 5.2 scheitern beim ersten Request?

Drei. Wer das alte Tool computer_20251124 deklariert, bekommt überall außer auf Amazon Bedrock ein 400; der Ersatz ist das Toolset computer_toolset_20260801 mit eigener Agent-Loop. Ein Advisor-Tool auf einem Fable-5.2-Executor muss selbst Fable 5.2 oder Mythos 5.2 sein, und sein Rat kommt verschlüsselt zurück. Wer von Opus 5.5 mit Zero Data Retention kommt, bei dem scheitert auf der Claude API jeder Request: Fable 5.2 verlangt 30 Tage Retention, außer Anthropic hat eine Ausnahme genehmigt. Ein weiterer Verlust hat keinen dokumentierten Fehler: In Organisationen mit kundenverwalteten Schlüsseln hat Fable 5.2 keine Structured Outputs. Laut Doku entfernst du dann strict: true und output_config.format und validierst die Ausgabe selbst.

Wann greift der Prefix-Check von Claude Fable 5.2?

Wenn dein Code den system-Prompt, die tools oder eine frühere Nachricht ändert und danach einen Thinking-Block zurückschickt, der nach dieser Stelle entstanden ist. Jeder Block gilt nur für den Prefix, aus dem er erzeugt wurde. Opus 5.5 und Fable 5.1 geben den Fehler standardmäßig nur für Accounts zurück, die am oder nach dem 31. August 2026 angelegt wurden; bei älteren Accounts kamen die nicht passenden Blöcke still beim Modell an. Fable 5.2 gibt ihn auf jedem Account zurück. Die Doku nennt den Fehler so:

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

Ein Retry mit demselben Body scheitert genauso. Eine Ausnahme: In der Message Batches API bekommt ein Eintrag, der die Einstellung nicht setzt, kein 400.

Wenn Claude Code, das Agent SDK oder Managed Agents deine Requests bauen, ändert sich nichts. Selbstgebauter Code ist sicher, wenn er system und tools für die ganze Konversation einfriert, an messages nur anhängt, jeden Assistant-Turn genau so zurückschickt, wie er kam, und die übrigen Änderungen aus der Doku vermeidet. effort, max_tokens oder cache_control-Marker zu ändern zählt nicht als Bearbeitung.

Die Änderungen, die zählen, sind genau die, die man schreibt, um Tokens zu sparen: Memory, die bei jedem Turn in system eingefügt wird, und clientseitiges Kürzen alter Turns. Tools ein- und auszutauschen zählt auch. Für jede gibt es einen unterstützten Ersatz: System-Nachrichten mitten in der Konversation für Anweisungen und Tools, serverseitige Compaction fürs Kürzen. Zwei leisere Änderungen tauchen beim Umstieg selbst auf. Ein MCP-Connector-Server, dessen Tool-Liste nicht gepinnt ist und sich zwischen Requests ändert, ist eine Bearbeitung für Fable-5.2-Blöcke, nicht aber für Opus-5.5-Blöcke. Und das model des Advisors zu ändern, was die Pairing-Regel erzwingt, ist eine Änderung an tools. Mach diesen Wechsel also in neuen Konversationen.

Wie testest du den Prefix-Check von Claude Fable 5.2 vor dem Umstieg?

Spiel eine echte Konversation noch einmal ab und stell den Check auf Melden statt Scheitern. Mit drop_block nimmt ein Request auf jedem Account am Check teil, du kannst das also gegen das Opus 5.5 laufen lassen, das du heute nutzt:

resp = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    system=system,
    tools=tools,
    messages=history,
    thinking={"type": "adaptive",
              "block_binding": {"prefix_mismatch_behavior": "drop_block"}},
    betas=["thinking-binding-controls-2026-08-01"],
)
for t in getattr(resp, "input_transformations", None) or []:
    if t.reason == "prefix_binding_mismatch":
        log.error("invalidated thinking at %s", t.path)

Jeder Eintrag prefix_binding_mismatch markiert einen Block, den dein Code ungültig gemacht hat; die Änderung liegt irgendwo vor dem frühesten davon. Null Einträge bedeuten nur dann etwas, wenn history tatsächlich einen Thinking-Block über das hinweg zurückgetragen hat, was dein Code zwischen den Turns tut. Lass deine echte Loop also lange genug laufen, bis das Memory-Update oder das Kürzen greift. Mit einem nicht gepinnten MCP-Connector wiederholst du den Lauf gegen claude-fable-5-2, den einen Fall, den Opus 5.5 dir nicht zeigen kann.

Ein Canary mit frischer Konversation, wie das Gerüst in meinem Opus-5.5-Post, kann diesen Check nicht auslösen: Es gibt keinen früheren Turn, den man ändern könnte. Dort bekam der zweite Turn einen Satz. Für Fable 5.2 ist er der ganze Test.

In Produktion bleibst du beim Standard error, außer du brauchst drop_block als Übergangslösung. Die Doku warnt, dass verworfene Blöcke die Output-Tokens erhöhen können.

Was ändert Claude Fable 5.2 ohne Fehlermeldung?

Vor allem die Kosten. Auf der Messages API steht Fable 5.2 standardmäßig auf high Effort, Opus 5.5 auf medium. Ein Request, der nie Effort gesetzt hat, läuft also eine Stufe höher, zum doppelten Basispreis pro Token. Anders als Fable 5.1 denkt es ab medium auch dann, wenn der Prompt sagt „antworte direkt, ohne nachzudenken“. Ein kleines max_tokens kann deshalb mit einem Thinking-Block ohne Text enden. Anthropics eigene Doku empfiehlt, die meisten Workloads auf Opus 5.5 zu starten und erst aufzusteigen, wenn deine Evals auch bei höherem Effort nicht reichen.

Ein Router oder Fallback, der eine Konversation von Fable 5.2 zu Opus 5.5 oder Fable 5.1 verschiebt, verwirft die Fable-5.2-Thinking-Blöcke mit einem 200, dieselbe Bindung, die Sonnet 5.5 eingeführt hat.

Ist der Prefix-Check von Claude Fable 5.2 die richtige Regel?

Ich halte die Regel für richtig, aber die Einführung tut weh. Ein Thinking-Block, der gegen eine andere History abgespielt wird, ist Reasoning über eine Konversation, die so nie stattgefunden hat, und ein 400 ist darauf die ehrliche Antwort. Aber weil sie nach Account-Alter gestaffelt wurde, erfahren ausgerechnet die ältesten Accounts zuletzt davon, also die, auf denen am ehesten noch alter, selbstgebauter History-Code läuft. Und diese Accounts erfahren es bei einem Modellwechsel.

Den Fix willst du wahrscheinlich ohnehin. Eine History, an die nur angehängt wird, sorgt auch dafür, dass der Prompt-Cache weiter trifft, von einem Turn zum nächsten.