In Teams, die mehrere Coding-Agents einsetzen, wechselt ein Task ständig den Besitzer. Ein Sonnet-Worker schreibt die Änderung und ein Opus-Reviewer prüft sie. Ein Claude-Code-Agent bleibt hängen und der Task wandert zu einem Codex-Agenten. Claude Sonnet 5.5, veröffentlicht am 28. September, hält nun schwarz auf weiß fest, was im Grunde schon immer teilweise galt: Das Reasoning des Modells wandert nicht mit der Arbeit mit. Auf Anthropics Seite What’s new in Sonnet 5.5 heißt es, jeder Thinking-Block halte fest, welches Modell ihn erzeugt habe – und kein anderes Modell lese die Blöcke von Sonnet 5.5.
Das Problem dabei ist, wie lautlos das geschieht. Wenn ein Request einen Block enthält, den das Modell nicht lesen kann, verwirft die API ihn, noch bevor das Modell ihn zu Gesicht bekommt. Der Request ist erfolgreich, die verworfenen Blöcke werden nicht in Rechnung gestellt, und die einzige Spur ist ein Eintrag unter input_transformations – und dieser taucht überhaupt nur auf, wenn man den Beta-Header thinking-binding-controls-2026-08-01 mitgeschickt hat. Der Reviewer-Agent erhält das Diff ohne die Begründung, es tritt kein Fehler auf, und das Review wirkt fundierter, als es in Wahrheit ist.
TL;DR
Beim Kontexttransfer zwischen Modellen gilt eine einfache Grundregel: Der einzige Kontext, der eine Übergabe übersteht, ist der, der schriftlich im Task festgehalten wurde. Thinking-Blöcke sind an das Modell gebunden, das sie erzeugt hat, an die exakte Konversation und bei Sonnet 5.5 zusätzlich an das Konto. Sorgen Sie dafür, dass jeder Agent seinen Durchlauf mit einem Handoff-Kommentar beendet: getroffene Entscheidungen samt Begründung, Annahmen, verworfene Ansätze und Fehlschläge, offene Fragen, geänderte Dateien und durchgeführte Prüfungen. Wenn Sie ein eigenes Harness bauen: Führen Sie den Verlauf strikt als Append-Only.
Ein Thinking-Block ist dreifach gebunden
Ein Thinking-Block enthält das Reasoning, das ein Modell für einen einzelnen Turn erzeugt hat – versehen mit einer Signatur, die die API validiert, bevor ein nachfolgender Request darauf zugreifen kann. Die Dokumentation zu Preserved Thinking beschreibt drei Bindungen, und jede davon entspricht einer Übergabe, die in Ihrem Team längst alltäglich ist.
Modell. Sonnet 5.5 liest Blöcke von Sonnet 5, Opus 4.8, Haiku 4.5 und früheren Modellen, nicht aber von Opus 5, Opus 5.5, Fable oder Mythos. Die Richtung ist entscheidend: Laut Anthropics Hinweisen zum Modellwechsel mitten in einer Konversation behält eine Unterhaltung, die von Sonnet 5 zu Sonnet 5.5 wechselt, ihr Reasoning bei. Wechselt man hingegen von Sonnet 5.5 zu einem beliebigen anderen Modell, laufen die folgenden Turns ohne das Reasoning ab. Das gilt auch für Anthropics eigenen serverseitigen Fallback, der abgelehnte Sonnet-5.5-Requests teilweise mit Sonnet 5 wiederholt.
Konversation. Ein Block lässt sich nur dann nutzen, wenn er exakt demselben System-Prompt, denselben Tools und denselben Messages folgt, aus denen er entstanden ist. Die FAQ der Dokumentation bringen die Konsequenz auf den Punkt: Reasoning lässt sich nicht in eine andere Konversation übertragen; starten Sie die neue Konversation daher mit einer Zusammenfassung des aktuellen Task-Status (Ziel, getroffene Entscheidungen, bisherige Dateien und Ergebnisse, nächster Schritt). Wechselt ein Task zu einem anderen Agenten, startet die Runtime eine neue Session – und das ist selbst beim selben Modell eine neue Konversation. Aus genau demselben Grund startet eine neue Session eines Tools ohne Vorwissen, wie in Kontext über KI-Sessions hinweg bewahren beschrieben.
Konto. Die Blöcke von Sonnet 5.5 funktionieren ausschließlich in dem Konto, in dem sie generiert wurden, oder in einem damit verknüpften Account. Anthropics Ankündigungsbeitrag nennt ein konkretes Szenario, in dem dies auffällt: der Kontowechsel mitten in einer Session in Claude Code.
Zusammenfassend: Zwischen Agenten wurde Reasoning in Wahrheit noch nie übertragen. Sonnet 5.5 hat dies nun offiziell zum Bestandteil des API-Vertrags gemacht.
Drei Übergaben, bei denen Reasoning lautlos verloren geht
| Übergabe | Was übertragen wird | Was verloren geht | Woran man es erkennt |
|---|---|---|---|
| Sonnet-5.5-Worker-Agent an Opus-5.5-Reviewer-Agent | Das Diff, das Repository, die Task-Beschreibung und die Kommentare | Das Thinking von Sonnet 5.5. Kein anderes Modell kann es lesen, und der Review-Lauf ist ohnehin eine neue Session | Über Agenten hinweg: nichts. Innerhalb einer einzelnen API-Konversation: ein model_binding_mismatch-Eintrag bei gesetztem Beta-Header |
| Claude-Code-Agent an Codex-Agent | Das Diff, der Branch, der Task-Eintrag, die gemeinsame Regeldatei des Repositories | Das gesamte Thinking von Claude sowie der Session-Status von Claude Code. Codex startet eine eigene Konversation | Nichts |
| Gleiches Modell, anderes Konto (Kontowechsel mitten in einer Session in Claude Code oder Wiedergabe einer gespeicherten Session mit den Zugangsdaten eines anderen Kontos) | Das sichtbare Transkript: Messages, Tool Calls, Ergebnisse | Jeder Thinking-Block von Sonnet 5.5, der unter dem ersten Konto erstellt wurde | Ein organization_binding_mismatch-Eintrag bei gesetztem Beta-Header auf der Claude-API und Google Cloud. Andernfalls nichts |
Die letzte Spalte ist das eigentliche Problem. Alle drei Übergaben verlaufen technisch erfolgreich, und der empfangende Agent antwortet voller Zuversicht auf Basis von weniger Wissen, als der vorherige besaß. Ein Reviewer auf einem anderen Modell winkt so möglicherweise eine Änderung durch, bei der der Worker noch Bedenken hatte – schlicht weil diese Bedenken im Thinking-Block standen, den der Reviewer nie zu Gesicht bekam.
Wir haben bereits früher darüber geschrieben, dass der Wechsel zwischen Coding-Agents „den Code bewahrt, aber das Reasoning verwirft“. Das gilt nun auch auf API-Ebene – was für Teams von Bedeutung ist, die Claude Code und Codex auf derselben Codebasis einsetzen, sowie für Routing-Regeln bei Eskalationen. Wenn komplexe Tasks von einem Sonnet-5.5-Worker an Opus 5.5 weitergegeben werden, wie in Sonnet 5.5 oder Opus 5.5: Welcher Agent bekommt den Task? beschrieben, entspricht jede Eskalation einer Übergabe aus der ersten Tabellenzeile.
Was eine Übergabenotiz enthalten muss, wenn das Reasoning verloren geht
Eine Übergabenotiz für Coding-Agents hat genau eine Aufgabe: das entscheidende Reasoning schriftlich festzuhalten, damit der nächste Bearbeiter es lesen kann. Die folgenden Felder erweitern Anthropics Zusammenfassungsformat um zwei Aspekte, die in den Thinking-Blöcken steckten, aber in keinem Diff sichtbar sind: warum ein bestimmter Weg gewählt wurde und welche Ansätze bereits ausgeschlossen wurden. Fügen Sie dies in die Instruktionen jedes Agenten ein, der einen Task weiterreichen kann:
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
Drei Details sorgen für Zuverlässigkeit.
Entscheidungen abfragen, nicht das Reasoning selbst. Sonnet 5.5 ist das erste Sonnet-Modell mit Sicherheitsklassifikatoren gegen Reasoning-Extraction, und seine Ablehnungskategorie reasoning_extraction greift bei Aufforderungen, internes Reasoning im Antworttext wiederzugeben. „Füge dein Thinking in den Kommentar ein“ ist genau eine solche Anfrage. „Liste jede Entscheidung samt Begründung auf“ ist hingegen ein ganz gewöhnlicher Bericht.
„Tried, failed“ spart die meiste Zeit. Eine Sackgasse ist in einem Diff unsichtbar. Ohne den Hinweis läuft der nächste Agent geradewegs in denselben Irrweg.
Prüfungen bedeuten konkrete Befehle und Ausgaben. „Tests bestanden“ ist eine bloße Behauptung. Der ausgeführte Befehl samt Zählergebnissen ist ein handfester Beleg, den ein Reviewer nachvollziehen und erneut ausführen kann.
Die Faustregel: Verzichten Sie auf die Notiz, wenn ein einzelner Agent einen Task von der Zuweisung bis zum Review in einem einzigen Durchlauf erledigt und die abnehmende Person das Diff ohnehin selbst liest. Verlangen Sie die Notiz jedoch in dem Moment, in dem ein Task den Assignee oder das Modell wechselt oder an einen Reviewer-Agenten übergeben wird. Die Coding-Agent-Handoff-Templates behandeln die Schnittstellen zwischen Mensch und Agent; diese Notiz schließt die Lücke an der Schnittstelle zwischen zwei Agenten.
Wer ein eigenes Harness baut: Das Bearbeiten des Verlaufs führt jetzt zu Fehlern
Die meisten Leser können diesen Abschnitt überspringen. Laut der Dokumentation zu Preserved Thinking ändert sich nichts, wenn Claude Code, claude.ai, Claude Managed Agents oder das Claude Agent SDK Ihre Requests zusammenstellen. Relevant ist das erst, wenn eigener Code direkt die Messages-API aufruft.
Für Konten, die am oder nach dem 31. August 2026 um 00:00 UTC auf der Claude-API, Amazon Bedrock oder Google Cloud erstellt wurden, führt das erneute Senden eines Thinking-Blocks von Sonnet 5.5 zu einem HTTP-Fehler 400, sobald davor irgendetwas verändert wurde (der System-Prompt, die Tools oder eine frühere Nachricht). Bei älteren Konten greift diese Prüfung nur, wenn ein Request sie explizit aktiviert. Das birgt eine Falle: Mit dem eigenen API-Key funktioniert alles reibungslos, doch ein Nutzer, der das Tool mit den Zugangsdaten eines neueren Kontos ausführt, läuft sofort in den 400er-Fehler. Die Lösung: Konversationen strikt als Append-Only behandeln.
- Frieren Sie den System-Prompt und die Tools zu Beginn der Session ein. Ändern Sie Instruktionen ausschließlich durch das Anhängen einer System-Nachricht mitten in der Konversation – was Sonnet 5.5 unterstützt, Sonnet 5 hingegen nicht.
- Senden Sie jeden Assistant-Turn exakt so zurück, wie er empfangen wurde, einschließlich leerer Thinking-Blöcke.
- Kompaktieren Sie über die API und nicht durch das Umschreiben vergangener Turns. „Compact on demand“ (Beta
compact-2026-09-04) liefert einen signierten Zusammenfassungsblock zurück, den Sie anstelle der betroffenen Nachrichten mitsenden. Die von der Dokumentation empfohlene einfache Kompaktierung sendet eine Zusammenfassungsnachricht zusammen mit der nächsten Anweisung, sodass kein altes Thinking erneut übertragen wird.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Mit dem Beta-Header verwirft prefix_mismatch_behavior: "drop_block" fehlschlagende Blöcke, statt einen Fehler auszugeben. Die Dokumentation stellt jedoch klar, dass dies die Modifikation lediglich verschleiert, anstatt sie zu beheben.
Bemerkenswert ist hier der Aufbau der von Anthropic empfohlenen Kompaktierung: Wenn Reasoning nicht wiederverwendet werden kann, lautet Anthropics Antwort eine schriftliche Zusammenfassung – im Grunde nichts anderes als eine Übergabenotiz unter anderem Namen.
Wo die Übergabe in Sharkly stattfindet
Der Task dient als zentrales, geteiltes Protokoll – und genau dorthin gehört die Übergabe, denn nichts sonst überdauert die Session. Ein Task umfasst die Conversation (ein dialogbasierter Kommentarverlauf), die Activity-Timeline mit Kommentaren und Änderungen sowie die Executions-Historie jedes einzelnen Laufs. Agenten-Texte für das Team werden als mit dem Lauf verknüpfte Kommentare gespeichert. Benötigt ein Agent eine Auskunft, erscheint seine Frage als Kommentar im Task, der Status wechselt auf das Warten auf eine menschliche Rückmeldung, und die Frage landet in der Inbox der zuständigen Person.
Bei einer Neuzuweisung zahlt sich das aus. Wechselt der Assignee von einem Sonnet-5.5-Agenten zu einem Opus-5.5-Reviewer oder zu einem Codex-Agenten, startet der nächste Durchlauf auf Basis des Tasks und nicht anhand eines Transkripts. Sharklys Dokumentation führt auf, was ein taskbasierter Lauf enthalten kann: Titel und Beschreibung, kürzliche Kommentare sowie den Kommentar, der den Lauf ausgelöst hat, die Instruktionen des Agenten und seine Repositories. Der Übergabe-Kommentar gehört zu dieser Liste. Das Thinking des vorherigen Agenten hingegen nicht – und bei einem Modellwechsel würde die API es ohnehin verwerfen.
Daraus ergeben sich zwei bewährte Gewohnheiten: Die Dokumentation empfiehlt, für das gesamte Team relevante Ergebnisse in Kommentaren oder der Task-Beschreibung festzuhalten – alles, was in einem direkten Chat mit einem Agenten geklärt wurde, gehört also dorthin, bevor der Task weiterwandert. Und da ein Durchlauf die jüngsten Kommentare einliest, sollten Entscheidungen, die dauerhaft für den gesamten Task gelten, in die Beschreibung übernommen werden.
Hier zahlt sich Provider-Neutralität aus. Der Agent orientiert sich am Standardmodell der Runtime; die Übergaberegel ist somit in den Instruktionen des Agenten hinterlegt und funktioniert identisch – ganz gleich, ob die nachfolgende Runtime Claude Code auf Sonnet 5.5 oder Codex auf einem anderen Modell ist. Die Einrichtung wird in Claude-Sonnet-5.5-Agents in Sharkly ausführen beschrieben. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen das Ergebnis anhand desselben schriftlichen Protokolls ab, das auch der nächste Agent liest – genau darauf basiert die menschliche Gesamtverantwortung für Agenten-Ergebnisse.
Preserved Thinking nahm mit Fable 5.1 seinen Anfang und umfasst mittlerweile auch Opus 5.5 sowie Sonnet 5.5. Wenn Sie Übergaben so gestalten, dass sie niemals darauf angewiesen sind, dass Reasoning mitwandert, bringt auch der nächste Modellwechsel Ihre Abläufe nicht aus dem Takt. Falls Sie bereits mehrere Agenten einsetzen, bietet Sharkly Ihnen eine zentrale Plattform, um deren Tasks und Resultate zu verwalten.
