Anthropic hat Claude Sonnet 5.5 am 28. September veröffentlicht – nur sechs Tage nach Opus 5.5. Mit 2 $ pro Million Input-Token und 10 $ pro Million Output-Token kostet es nur die Hälfte von Opus 5.5 (4 $ bzw. 20 $). Auf der Launch-Seite liegt das Modell in den meisten Zeilen nur wenige Punkte hinter Opus 5.5 und bei Terminal-Bench 4.0 – einem von Anthropic selbst durchgeführten Benchmark – sogar davor. Für Teams, die mehrere Coding-Agents einsetzen, liegt die Versuchung nahe, kurzerhand jeden Agent auf Sonnet umzustellen und die Ersparnis einzustreichen.
Die aufgeschlüsselten Effort-Diagramme auf derselben Seite sprechen allerdings eine andere Sprache. Das Vorzeige-Ergebnis bei Terminal-Bench wurde mit Sonnets höchster Effort-Stufe erzielt – bei stolzen 12,54 $ pro Versuch. Bei Einstellungen, die man tatsächlich dauerhaft im Produktiveinsatz laufen lassen würde, kehrt sich die Reihenfolge um: Opus 5.5 auf der Stufe „medium“ erzielt 57,6 % für 2,94 $, Sonnet 5.5 auf „high“ erreicht 43,0 % für 1,94 $, und Sonnet zieht erst bei „xhigh“ an Opus auf „medium“ vorbei – mit 61,5 % für 5,30 $.
TL;DR
Setzen Sie für klar abgegrenzte Aufgaben standardmäßig auf Sonnet 5.5 mit dem Effort „medium“. Übergeben Sie umfangreiche, mehrdeutige oder querschnittliche Aufgaben lieber an Opus 5.5, anstatt Sonnet auf „xhigh“ hochzudrehen: In allen drei von Anthropic veröffentlichten Coding-Diagrammen nach Effort übertrifft Opus auf „high“ Sonnet auf „xhigh“ – bei etwa gleichen oder sogar geringeren Kosten. Halten Sie dies als feste Regel beim Agent fest und nicht nur als vage Absicht im Kopf: ein Agent pro Modell- und Effort-Tier, klar benannte Eskalationsbedingungen und eine präzise Definition of Done. Sharkly wählt weder das Modell noch das Effort-Level aus – es dokumentiert lediglich, welcher Agent was an der Task erledigt hat.
Was die Launch-Zahlen tatsächlich belegen
Die Tabelle aus der Launch-Ankündigung samt dem hinter jeder Zelle stehenden Effort und wer den Test durchgeführt hat:
| Benchmark | Erhoben durch | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | 70,6 % (max) | 66.4% (xhigh) |
| FrontierCode 1.1 | Cognition | 52,1 % (xhigh), 46,2 % (max) | 54,4 % (max) |
| CursorBench 4.0 | Cursor | 55,5 % (max) | 57,8 % (max) |
| SWE-Bench Pro | Anthropic System Card, maximaler Effort | 81,3 | 89,9 |
| HLE, mit Tools | Anthropic | 64,5 % | 67,7 % |
| OSWorld 2.1 | Anthropic | 80,1 % | 81,8 % |
Zwei Einschränkungen zur Zeile für Terminal-Bench: Laut System Card waren 10 % der Durchläufe von Opus 5.5 von markierten Anfragen („flagged requests“) betroffen, verglichen mit lediglich 1,5 % bei Sonnet. Zudem maß Artificial Analysis in einem eigenen Durchlauf für Sonnet 5.5 nur 63,6 % statt 70,6 %. SWE-Bench Pro weist unterdessen einen Vorsprung von 8,6 Punkten zugunsten von Opus aus. Anthropics eigene Positionierung bestätigt das: Sonnet 5.5 für klar umrissene Alltagsaufgaben und Bugfixes, während Opus 5.5 „bei komplexen, ergebnisoffenen Arbeiten weiterhin deutlich stärker bleibt“.
Die prominenten Werte der Ankündigung verschleiern zudem, was eine Routing-Regel eigentlich erfordert: die drei Coding-Benchmarks bei Effort-Stufen, die man in der Praxis auch tatsächlich einsetzen würde – als Score und Kosten pro Task.
| Benchmark | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | 28,8 %, 0,83 $ | 43,0 %, 1,94 $ | 61,5 %, 5,30 $ | 57,6 %, 2,94 $ | 64,2 %, 3,88 $ |
| CursorBench 4.0 | 39,2 %, 0,70 $ | 47,8 %, 1,67 $ | 53,1 %, 3,88 $ | 52,5 %, 2,91 $ | 56,0 %, 3,97 $ |
| FrontierCode 1.1 | 36,5 %, 0,24 $ | 49,4 %, 0,42 $ | 52,1 %, 1,59 $ | 54,6 %, 0,80 $ | 54,0 %, 1,09 $ |
Sonnet 5.5 ist bei „medium“ und „high“ der günstigste Versuch, erzielt dort aber auch die niedrigsten Scores. Jenseits von „high“ kreuzen sich die Linien: Sonnet auf „xhigh“ kostet in allen drei Zeilen mehr als Opus auf „medium“ und unterliegt Opus auf „high“ in allen drei Benchmarks bei vergleichbarem oder geringerem Budget. Das günstige Modell hört genau in dem Moment auf, günstig zu sein, in dem man von ihm verlangt, wie das teure zu agieren. Sonnets Kosten bei CursorBench sind Schätzungen von Anthropic, und keine dieser Aufgaben spiegelt Ihr eigenes Repository wider; betrachten Sie diesen Wendepunkt daher als eine Hypothese, die es in der Praxis zu bestätigen gilt.
Die Routing-Regel konkret ausformuliert
Frühere Beiträge haben dafür plädiert, Modelle auf die Rollen der Agents abzustimmen, anhand des Aufgabentyps zu entscheiden, welcher Agent eine Task erhält, und Tiers als feste Regel zu definieren. Sonnet 5.5 fügt dem eine weitere Dimension hinzu. Bei Terminal-Bench liegen zwischen demselben Modell auf „medium“ und auf „max“ rund das 15-Fache an Kosten pro Durchlauf (0,83 $ gegenüber 12,54 $). Die Anweisung „Leite das an Sonnet weiter“ ist daher erst dann eine vollwertige Regel, wenn sie auch das Effort-Level benennt.
| Art der Aufgabe | Agent (Runtime-Modell) | Effort | Begründung |
|---|---|---|---|
| Bugfix mit Reproduktionsanleitung und konkretem Test | Sonnet 5.5 | medium | Anthropics Prompting-Guide empfiehlt „medium“ für agentenbasiertes Programmieren bei klar spezifizierten Aufgaben |
| Test-Scaffolding, Dokumentation, Changelog, Dependency-Updates | Sonnet 5.5 | medium | Klar abgegrenzt, schnell zu prüfen, unter einem Dollar pro Task in allen drei Diagrammen |
| Abgegrenztes Feature innerhalb eines Moduls mit eindeutigen Akzeptanzkriterien | Sonnet 5.5 | high | In allen Diagrammen immer noch günstiger als Opus auf „medium“; das obere Ende von Sonnets sinnvollem Einsatzbereich |
| Nächtliche Triage großer Mengen an Vorgängen | Sonnet 5.5 | low, plus ein Verifizierungsschritt | Am günstigsten pro Durchlauf, kann bei „low“ jedoch Vollzug melden, ohne Tests ausgeführt zu haben |
| Umfangreiches oder unklares Refactoring, Migration, modulübergreifende Änderungen | Opus 5.5 | medium oder high | Übertrifft auf „high“ Sonnet auf „xhigh“ in allen drei Diagrammen bei ähnlichen oder geringeren Kosten |
| Planung: Vage Anforderungen in konkrete Tasks zerlegen | Opus 5.5 | high | Bei komplexen, offenen Aufgaben behält Opus laut Anthropic klar die Oberhand |
| Review der Ergebnisse eines anderen Agents | Opus 5.5, danach ein Mensch | high | Ein zweites Modell prüft die Belege; ein Mensch gibt das Resultat frei |
Erst bei den Eskalationspfaden macht sich die Regel bezahlt. Wenn ein Sonnet-Agent nicht weiterkommt, ist der erste Reflex meist, einfach den Effort zu erhöhen. Die Daten legen jedoch nahe: Wechseln Sie stattdessen das Modell. Eine Task, die Sonnet auf „xhigh“ benötigt, ist nach diesen Erkenntnissen eine Aufgabe für Opus auf „high“. Definieren Sie Ihre eigenen Bedingungen; die folgenden Beispiele veranschaulichen das Prinzip:
- Derselbe Test schlägt zweimal fehl: Eine Person übergibt die Task samt Log an den Opus-Agent; es gibt keine stillen Wiederholungsversuche auf einem höheren Tier.
- Die Änderung betrifft mehr Dateien, als einem Worker erlaubt sind (beispielsweise mehr als acht), oder verändert Pfade, die in der Task nicht genannt wurden.
- Der Agent stellt eine Frage zum Softwaredesign statt eine Verständnisfrage zur Aufgabenformulierung.
- Ein bestimmter Task-Typ ist mit Sonnet nur bei einem Effort oberhalb von „high“ erfolgreich: Weisen Sie diese Aufgabenkategorie im nächsten Sprint direkt dem Opus-Agent zu.
Das Ganze funktioniert auch umgekehrt: Opus-Tasks, die wiederholt im ersten Anlauf mit minimalen Diffs abgeschlossen werden, gehören ein Tier tiefer angesiedelt.
Was die Modelle für die Review-Queue bedeuten
Eine Regel, die lediglich Modell und Effort festlegt, ist nur die halbe Miete. Die andere Hälfte bestimmt, wie ein fertiges Arbeitsergebnis („Done“) aussieht. Denn jedes Tier übergibt dem Reviewer etwas völlig anderes – und Reviews waren schon vor beiden Releases der eigentliche Engpass. Günstigere Durchläufe schaffen mehr Diffs, aber nicht mehr Reviewer-Arbeitszeit.
Anthropics Prompting-Guide für Sonnet 5.5 spricht offen darüber, was Reviewer zu erwarten haben:
- Bei „low“ und „medium“ meldet es sich bei langen Agent-Tasks frühzeitig zurück: Auf dem Board wartet dann um zwei Uhr nachts eine Task auf menschliche Rückmeldung. Ein Hacker-News-Kommentator führte ein Ergebnis von lediglich 7,4 % in einem eigenen Benchmark (Sonnet 5 erreichte 17,8 %) genau darauf zurück.
- Bei „low“ überspringt es mitunter die Verifikation und meldet Code als fertig, ohne Tests auszuführen. Ein „Done“ eines Triage-Agents ist ohne den Output der Checks wertlos.
- Auf allen Effort-Stufen fügt es ungefragt Tests, Dokumentationen und kleine Dateien hinzu. Manches davon ist nützlich, aber all das bedeutet mehr Diff-Zeilen, die gelesen werden müssen.
- Bei „xhigh“ und „max“ fügt es Review-Runden oder Reviewer-Subagents hinzu. Laut der Launch-Seite erzielte Sonnet 5.5 bei FrontierCode auf „max“ genau deshalb ein schlechteres Ergebnis als auf „xhigh“: Es aktivierte häufiger die Code-Review-Fähigkeit von Claude Code, die sich auf viele Subagents auffächert. In zwei von Cognition untersuchten Fällen führte dies zu Timeouts oder Änderungen außerhalb des definierten Scopes („out-of-scope edits“). Solche Änderungen belasten Reviewer am stärksten, weil jemand den gesamten Code Zeile für Zeile danach absuchen muss.
Opus 5.5 belastet die Queue auf andere Weise. Laut Anthropic kann das Modell 18 Stunden oder länger an einer Aufgabe arbeiten und bis zu 128.000 Tokens an Output erzeugen. Seine Bürde ist also nicht Rauschen, sondern der schiere Umfang – und das Übergabepaket, das ein Reviewer benötigt, gilt hier genauso.
Die Definition of Done gehört daher direkt in die Arbeitsanweisungen des Worker-Agents, die Sharkly jedem Lauf mitgibt:
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Beide Tiers in Sharkly betreiben
Sharkly wählt weder das Modell aus noch setzt es den Effort fest. Die Dokumentation zu den Agents formuliert es unmissverständlich: „Der Agent folgt dem Standardmodell der Runtime. Er verspricht oder zeigt keinen spezifischen Modellnamen an. Ändern Sie Modelle in der Runtime- oder Computer-Tool-Konfiguration, nicht am Agent.“ Es gibt am Agent auch keine Einstellung für die Denktiefe („Thinking Depth“). Ein Tier ist schlicht eine Claude-Code-Konfiguration auf einem Computer; der Agent ist lediglich das Mittel, mit dem das Team ihm Arbeit zuweist.
Daher: ein Agent pro Tier. sonnet-worker läuft auf einem Computer, dessen Claude Code auf claude-sonnet-5-5 eingestellt ist; opus-lead auf einem, der auf claude-opus-5-5 konfiguriert ist. Ein Computer kann ein Container sein – ein zweites Tier bedeutet also keinen zweiten physischen Laptop. Drei Details aus Claude Codes Dokumentation zur Modellkonfiguration entscheiden darüber, ob ein Tier auch tatsächlich der Bezeichnung entspricht:
- Geben Sie immer die vollständige Modell-ID an („pin the full id“). Der Alias
sonnetsteht nur bei der Anthropic-API für Sonnet 5.5 (Bedrock und Google Cloud lösen ihn nach wie vor zu Sonnet 4.5 auf), und Sonnet 5.5 setzt Claude Code v2.1.284 oder höher voraus. - Das
default-Modell von Claude Code ist bei Pro, Max, Team, Enterprise und der API stets Opus 5.5. Ein Computer, den niemand konfiguriert hat, ist somit bereits ein Opus-Tier. - Der Standard-Effort von Sonnet 5.5 in Claude Code ist „medium“ – also das oben beschriebene Worker-Tier. Anpassungen daran erfolgen auf dem Computer, nicht am Agent.
Sharkly kann nicht zuverlässig auslesen, welches Modell eine Runtime gerade verwendet. Nehmen Sie das Tier daher direkt in den Namen des Agents auf und aktualisieren Sie Name und Konfiguration stets gemeinsam. Die genauen Schritte beschreibt die Einrichtungsanleitung für Sonnet 5.5.
Für Aufgaben, die beide Tiers innerhalb einer Task erfordern, empfiehlt sich eine Crew. Eine Crew ist eine wiederverwendbare Gruppe aus Personen und Agents, die von einem Leader-Agent koordiniert wird. Mit opus-lead als Leiter und Sonnet-Workern als Mitgliedern liest der Leader die Task, bearbeitet sie selbst oder erwähnt ein Mitglied für einen Teilabschnitt; die Mitglieder tragen ihre Ergebnisse dann in dieselbe Task ein. Dies entspricht dem Aufbau mit Opus als Orchestrator, wie ihn auch Hacker-News-Kommentatoren vorgeschlagen haben – inklusive sauber dokumentierter Übergaben, die für Menschen nachvollziehbar bleiben. Für kleine, klar umrissene Arbeiten können Sie auf die Crew verzichten und sonnet-worker direkt beauftragen.
Der Alias opusplan von Claude Code bildet eine Variante davon innerhalb einer einzigen Session ab: Opus im Planungsmodus, Sonnet für die Ausführung. Der Sonnet-Part verweist jedoch nur bei der Anthropic-API auf Sonnet 5.5; bei Bedrock, Google Cloud oder Foundry wird er zu einem älteren Sonnet aufgelöst. Nutzen Sie diesen Modus, wenn ein und dieselbe Person die Session ausführt und prüft. Verwenden Sie zwei Agents, wenn für Außenstehende klar erkennbar sein muss, wer geplant und wer implementiert hat.
Eines wird zwischen den Tiers jedoch niemals übertragen: das Reasoning. Die Thinking-Blöcke von Sonnet 5.5 sind strikt an das Modell und die Konversation gebunden. Kein anderes Modell kann sie lesen, und Sonnet 5.5 hat keinen Zugriff auf die Gedankenblöcke von Opus 5.5. Das Teilen von Verzeichnissen innerhalb einer Crew teilt Dateien, nicht jedoch die Session des vorherigen Agents. Was der Leader entschieden hat, erfährt der Worker nur dann, wenn es explizit in der Task festgehalten wird – worum es sich auch im Detail in einem eigenen Blogbeitrag dreht.
Nichts davon ändert etwas daran, wer die Arbeit letztlich abnimmt. Agents recherchieren, implementieren, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen das Ergebnis ab. Die oben aufgeführten Kosten landen auf der Rechnung Ihres jeweiligen Providers, da die Modellnutzung über die in den entsprechenden Tools hinterlegten Abonnements oder API-Schlüssel abgerechnet wird. Die Zuweisung, das Ausführungsprotokoll, Rückfragen, Resultate und der menschliche Review verbleiben stets in der Task – ganz gleich, welches Modell im nächsten Quartal die Spitzenposition einnimmt. Diese Logik gilt herstellerübergreifend, wie auch der Vergleich zwischen Sonnet 5.5 und GPT-6 Sol belegt. Wenn Sie mehrere Coding-Agents flexibel einsetzen möchten, statt sich an ein einziges Ökosystem zu binden: Genau für dieses Problem wurde Sharkly entwickelt.
