Das Reasoning von Sonnet 5.5 bleibt bei einem Modell und einem Konto

Claude Sonnet 5.5 erschien am 28. September zu denselben Preisen wie Sonnet 5, und Claude Code v2.1.284 hat es am selben Tag zum Standard-Sonnet auf der Anthropic API gemacht. Anthropic nennt fünf Stellen, an denen Code für Sonnet 5 unter Sonnet 5.5 bricht. Erzwungenes tool_choice gibt 400 zurück, und Computer Use wandert auf der Claude API und Google Cloud ins Toolset, beides bekannt von Opus 5.5. Das Advisor-Tool lehnt Opus 4.8, Opus 4.7 und Sonnet 5 als Advisor ab. Thinking abschalten funktioniert anders als bei Opus 5.5: disabled gibt 400 zurück, der Ersatz heißt between_tools, bei Effort high oder darunter. Und Thinking-Blöcke sind jetzt an das Modell und das Konto gebunden.

Ich habe letzte Woche geschrieben, dass ein 400 die gute Art von Bruch ist. Die fünfte Änderung ist die, die keins auslöst, und sie verschiebt still die Einheit, in der ein Model-Router arbeiten sollte: vom Turn zur Konversation.

Welche Modelle können das Thinking von Sonnet 5.5 lesen?

Keins außer Sonnet 5.5 selbst. Die Doku ist eindeutig: Sonnet 5.5 liest Thinking-Blöcke von Sonnet 5, Opus 4.8, Haiku 4.5 und älteren Modellen, aber nicht von Opus 5, Opus 5.5 oder irgendeinem Fable- oder Mythos-Modell, und "no other model reads thinking blocks from Claude Sonnet 5.5."

Schau dir an, welches Paar dadurch getrennt wird. Das Routing, zu dem diese Modellreihe einlädt, ist Sonnet 5.5 für Routine-Turns und Opus 5.5 für die schweren. Genau diese beiden teilen nichts, in keiner Richtung. Opus 5.5 liest Blöcke von Opus 5 und älteren Opus-, Sonnet- und Haiku-Modellen, also bleibt beim Wechsel von Sonnet 5 zu Opus 5.5 das Reasoning erhalten. Von Sonnet 5.5 zu Opus 5.5 nicht, und eine Route zurück nach unten zu Haiku 4.5 auch nicht.

Was passiert mit einem Block, den das Modell nicht lesen kann?

Die API entfernt ihn, bevor der Prompt das Modell erreicht, und der Request ist erfolgreich. Verworfene Blöcke werden nicht abgerechnet und zählen nicht zu input_tokens. Die text- und tool_use-Blöcke bleiben, das Modell sieht also weiter, was gesagt und getan wurde. Es beantwortet diesen Turn nur ohne das Reasoning dahinter.

Der Verlust gilt pro Request, nicht dauerhaft. Die API verändert dein messages-Array nie, also bekommt der nächste Request an ein Modell, das diese Blöcke lesen kann, sie wieder. Anthropic rät, immer die volle Historie inklusive Thinking zu schicken und die API verwerfen zu lassen, was das aktuelle Modell nicht nutzen kann. Endgültig weg ist das Reasoning nur, wenn dein eigener Client es entfernt.

Was kommt durch die Kontobindung hinzu?

Eine zweite Mauer, die mit dem Modell nichts zu tun hat. Blöcke, die Sonnet 5.5 erzeugt, "work only in the account that produced them, or in an account linked to it." Schick einen aus einem anderen Konto, und die API verwirft ihn, wieder mit 200. Blöcke älterer Modelle sind nicht betroffen.

Eine Konversation, die über nicht verknüpfte Konten verteilt ist, verliert also bei jedem kontoübergreifenden Turn Reasoning: ein Gateway, das die Last über Keys mehrerer Organisationen verteilt; der Wechsel auf ein zweites Konto, wenn das erste ins Rate Limit läuft; eine Konversation, die aus einem Dev-Konto in Prod nachgespielt wird.

Was lässt die Doku offen?

Mehr, als mir lieb ist, für ein Verhalten, das nie einen Fehler wirft. "Linked" ist nicht definiert. Ob die Bindung pro Organisation, Workspace oder Key gilt und ob ein Bedrock-Konto neben einem direkten API-Konto als "anderes Konto" zählt, lässt sich der Seite nicht entnehmen. Das Melden von organization_binding_mismatch ist nur für die Claude API und Google Cloud dokumentiert. Zu Amazon Bedrock, Claude Platform on AWS und Microsoft Foundry steht dort nichts, weder so noch so. Ein Opt-out beschreibt die Doku nicht.

Anthropics eigener Refusal-Fallback ist ebenfalls ein Modellwechsel, und die Doku sagt das auch. Der serverseitige Fallback (fallbacks: "default", Beta, Claude API) wiederholt cyber- und frontier_llm-Refusals auf Sonnet 5, das Sonnet-5.5-Blöcke nicht lesen kann, also werden die Blöcke verworfen. Und es bleibt nicht bei einem Turn: Sticky Routing schickt spätere Requests dieser Konversation etwa eine Stunde lang direkt an das Fallback-Modell, begrenzt auf deine Organisation.

Wie siehst du, dass etwas verworfen wurde?

Pro Block nur, wenn du danach fragst. Mit dem Beta-Header thinking-binding-controls-2026-08-01 enthält jede Antwort auf oberster Ebene ein Array input_transformations, das jeden verworfenen Block mit Grund auflistet: model_binding_mismatch für das falsche Modell, organization_binding_mismatch für das falsche Konto. Ohne den Header passiert das Verwerfen still. Ein Fallback taucht zwar im Feld model der Antwort auf, aber das sagt dir nur, dass das Modell gewechselt hat, nicht, was dabei verloren ging.

resp = client.beta.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    messages=history,
    betas=["thinking-binding-controls-2026-08-01"],
)
for t in getattr(resp, "input_transformations", None) or []:
    if t.type == "thinking_dropped":
        log.warning("reasoning dropped at %s: %s", t.path, t.reason)

Schick dabei dein echtes system und deine echten tools mit, keinen abgespeckten Request. Anthropic kündigt an, dass spätere Prüfungen neue Typen und Gründe hinzufügen, also lass den Code nie an einem unbekannten scheitern.

Was sollte ein Router ändern?

Die Einheit, nach der er routet. Meine Einschätzung: Das Design ist vertretbar, der Default nicht. Ein harter Fehler würde jeden Router lahmlegen, der Thinking über einen inkompatiblen Wechsel weiterreicht, und die Blöcke werden nicht zerstört, nur für diesen Turn nicht genutzt. Aber kein Request schlägt fehl, also hat normales Error-Monitoring nichts zu zählen. Das einzige Signal pro Block steckt hinter einem Beta-Header, den die meisten Integrationen nie senden werden.

Eine Aufteilung nach Rollen, bei der ein Reviewer den Output des Workers in seiner eigenen Konversation bekommt, verliert nichts: Der Reviewer liest das Arbeitsergebnis, nicht das Thinking des Workers. Das ist die Form der Rollenaufteilung, die ich beschrieben habe, als ich das agentischere Modell auf den Platz des Reviewers gesetzt habe. Ein Router, der innerhalb einer Konversation Turn für Turn das Modell wählt, entscheidet jetzt auch, welches Reasoning das Modell sehen darf. Das Portfolio an Modellen, das ich beschrieben habe, als es darum ging, ein Modell als Abhängigkeit zu behandeln, die nicht stillhält, funktioniert weiter, solange jede Konversation bei einem Mitglied davon bleibt.

Also route pro Konversation, wo du kannst, halte eine Konversation auf einem Konto, und wenn du doch mittendrin wechselst, bleib in einem Paar, das die Blöcke des anderen lesen kann. Dann schalte den Header in Staging ein, schick einen Tag echten Traffic durch deinen Router und zähl, was er verwirft.