Anthropic hat Claude Sonnet 5.5 am 28. September zu einem Preis von 2 $ pro Million Input-Token und 10 $ pro Million Output-Token veröffentlicht. OpenAI brachte GPT-6 Sol am 22. September zum selben Preis von 2 $ bzw. 10 $ heraus. Sechs Tage Abstand, identische Listenpreise und beide Modelle liegen jeweils genau eine Stufe unter dem Flaggschiff des jeweiligen Anbieters. Für ein Team, das ein Standardmodell für Coding-Agents sucht, entscheidet der Preis daher gar nichts. Die eigentliche Frage lautet: Claude Code oder Codex als Runtime um das jeweilige Modell – und wie viel jedes Gespann pro erledigter Aufgabe kostet.
Ein echter Vergleichstest bedeutet: zwei Runtimes, zwei Konfigurationen, zwei Ergebnis-Sets und eine Review-Person, die krampfhaft versucht nachzuvollziehen, welches Terminal welchen Diff erzeugt hat. Das Modell auszuwählen ist eine Zeile in den Einstellungen. Beide fair miteinander zu vergleichen, gleicht hingegen einem handfesten Agenten-Chaos im Kleinformat.
TL;DR
Claude Sonnet 5.5 und GPT-6 Sol kosten pro Token exakt dasselbe und unterscheiden sich vor allem durch die Runtime, in der Teams sie typischerweise betreiben: Claude Code für Sonnet 5.5, Codex für Sol. Anthropics Vergleichstabelle zum Launch enthält vier Zeilen mit GPT-6 Sol: In dreien liegt Sonnet 5.5 klar vorn; die vierte – FrontierCode – hängt vom konfigurierten Effort-Level ab. Auch bei den Kosten pro Aufgabe kehrt sich das Bild je nach Benchmark um: Bei FrontierCode erreicht Sonnet 5.5 das Spitzenergebnis von Sol zu etwa einem Fünftel der Kosten; bei AA-Briefcase kostet das beste Ergebnis von Sol 2,67 $ pro Aufgabe, das von Sonnet 5.5 hingegen 29,19 $. Dabei handelt es sich jedoch um die Benchmark-Tabelle eines einzelnen Anbieters. Die Entscheidung zwischen Sonnet 5.5 und GPT-6 Sol treffen Sie am besten, indem Sie denselben Task in beiden Runtimes auf Ihrer eigenen Codebasis ausführen und die Review-Minuten pro akzeptierter Änderung messen. Wenn der Task als zentrales System of Record dient, spricht auch vieles dafür, einfach beide beizubehalten.
Was sich aus den veröffentlichten Zahlen wirklich ablesen lässt
Vier Zeilen. Der Launch-Beitrag zu Claude Sonnet 5.5 vergleicht Sonnet 5.5, Sonnet 5, Opus 5.5 und GPT-6 Sol – doch nur die folgenden Zeilen enthalten überhaupt Messwerte für Sol:
| Zeile in Anthropics Tabelle | Durchgeführt von | Sonnet 5.5 | GPT-6 Sol |
|---|---|---|---|
| FrontierCode 1.1 (Main) | Cognition: Claude-Modelle in Claude Code, GPT-Modelle in Codex CLI | 46,2 % bei max, 52,1 % bei xhigh | 49,3 % |
| GDPval-AA v2.1 | Artificial Analysis | 1844 | 1487 |
| AA-Briefcase v1.1 | Artificial Analysis | 1811 | 1483 |
| Chartography, no tools | Benchmark von Surge AI; Sonnet 5.5 bewertet durch Anthropic, Sol gemäß Bericht von Surge AI | 61,6 % | 53,6 % |
Das ist die Übersicht eines einzelnen Anbieters. Der Ankündigungsbeitrag von OpenAI zu Sol erschien sechs Tage vor der Veröffentlichung von Sonnet 5.5 – die einzige Hersteller-Tabelle, die beide Modelle aufführt, stammt folglich von Anthropic. Beide Spalten sind zudem mit Einschränkungen durch Softwarefehler behaftet: Die Benchmark-Läufe von Artificial Analysis für Sonnet 5.5 basierten auf einem Pre-Release-Deployment mit einem Fehler bei Structured Outputs, der inzwischen behoben wurde; OpenAI wiederum hat kürzlich einen Bug beim Bildverständnis in Sol behoben, der in den Werten von Artificial Analysis und Surge AI möglicherweise noch nicht berücksichtigt ist.
Die Zeile zu FrontierCode ist für Entwicklungsteams besonders aufschlussreich, da sie bereits einen echten Runtime-Vergleich darstellt: 52,1 % gegenüber 49,3 % vergleichen Claude Code auf Sonnet 5.5 mit Codex CLI auf Sol – also genau jene Setups, die man tatsächlich in der Praxis einsetzen würde. Ebenso wichtig ist die Fußnote zum Maximalwert: FrontierCode bestraft Änderungen außerhalb des eigentlichen Aufgabenbereichs (Out-of-Scope-Änderungen). Auf der höchsten Aufwandstufe (max effort) aktivierte Sonnet 5.5 häufiger die Code-Review-Funktion von Claude Code, die sich auf zahlreiche Sub-Agents auffächert. In zwei von Cognition untersuchten Fällen führte genau das zu Timeouts oder Änderungen am Code vorbei. Mehr Aufwand, größerer Diff, mehr Review-Bedarf.
Keine weitere Benchmark auf der Seite enthält Messwerte für Sol. Die Effort-Diagramme für Terminal-Bench 4.0 und CursorBench 4.0 bilden lediglich GPT-5.6 Sol ab, da für GPT-6 Sol schlicht keine Daten veröffentlicht wurden.
Es gibt immerhin einen aggregierten Drittanbieter-Vergleich: Artificial Analysis bewertet den Max-Effort-Endpunkt von Sonnet 5.5 mit 56 Punkten auf seinem Intelligence Index – Platz drei von 216 mit Stand vom 29. September. Sol lag am 23. September, bei unserer letzten Erfassung, bei 48 Punkten. Zwei Stichtage, ein dynamischer Index – und keine der beiden Zahlen sagt etwas über die Leistung in Ihrem konkreten Repository aus.
Kosten pro erledigter Aufgabe, nicht pro Token
Identische Token-Preise sagen wenig über die tatsächliche Rechnung aus, denn wie viele Token pro Aufgabe anfallen, hängt vom Modell, dem Aufwand (Effort) und der verwendeten Runtime ab. Anthropics Ankündigungsseite listet Scores und Kosten pro Aufgabe nach Effort-Stufen für zwei der gemeinsamen Benchmarks auf:
| Effort | FrontierCode: Sonnet 5.5 | FrontierCode: GPT-6 Sol | AA-Briefcase: Sonnet 5.5 | AA-Briefcase: GPT-6 Sol |
|---|---|---|---|---|
| low | 29,3 %, 0,19 $ | 37,3 %, 0,43 $ | 1264, 0,87 $ | 905, 0,12 $ |
| medium | 36,5 %, 0,24 $ | 45,9 %, 0,77 $ | 1461, 1,64 $ | 1142, 0,34 $ |
| high | 49,4 %, 0,42 $ | 47,7 %, 1,04 $ | 1634, 3,95 $ | 1289, 0,63 $ |
| xhigh | 52,1 %, 1,59 $ | 48,4 %, 1,32 $ | 1746, 9,63 $ | 1364, 1,19 $ |
| max | 46,2 %, 20,78 $ | 49,3 %, 2,07 $ | 1811, 29,19 $ | 1483, 2,67 $ |
Betrachten wir zuerst FrontierCode. Sonnet 5.5 erzielt auf der Stufe „high“ 49,4 % für 0,42 $ pro Aufgabe und liegt damit auf Augenhöhe mit dem Bestwert von Sol (49,3 % für 2,07 $). Anthropic fasst dies als „etwa ein Fünftel der Kosten pro Aufgabe“ zusammen. Das entscheidende Detail liegt jedoch eine Zeile höher: Auf der Stufe „medium“ erreicht Sonnet 5.5 lediglich 36,5 % – und liegt damit noch unter dem Wert von Sol auf der Stufe „low“. Genau „medium“ ist jedoch die Standardeinstellung in Claude Code für Sonnet 5.5. Anthropics Prompting-Leitfaden empfiehlt, standardmäßig mit „high“ zu beginnen, oder „medium“ nur für agentisches Coden bei klar spezifizierten Aufgaben zu nutzen. Ausgerechnet die Konfiguration, die kaum jemand anfasst, kann also über das Gesamtergebnis entscheiden.
Bei AA-Briefcase, einer Benchmark für Wissensarbeit, verhält es sich genau umgekehrt. Das beste Ergebnis von Sol kostet 2,67 $ pro Aufgabe; das beste Resultat von Sonnet 5.5 schlägt mit 29,19 $ zu Buche – etwa das Elffache – bei einem höheren Score. Die Einstellung von Sonnet 5.5, die den Kosten von Sols Maximalwert am nächsten kommt (medium bei 1,64 $), erreicht 1461 gegenüber 1483 Punkten. Dieselben beiden Modelle liefern also ein völlig gegensätzliches Bild darüber, welches von ihnen für das jeweilige Ergebnis günstiger ist.
Prompt-Caching verringert diesen Abstand nicht nur, sondern verschiebt ihn auch. Sonnet 5.5 berechnet Cache-Reads für Input-Token mit 0,10 $ pro Million, während Cache-Writes (für 5 Minuten) 2,50 $ kosten (Anthropic-Preise). GPT-6 gewährt 90 % Rabatt auf gecachte Input-Reads, was bei einem Basispreis von 2 $ genau 0,20 $ entspricht – ein gecachter Lesezugriff ist bei Sonnet 5.5 also halb so teuer. Der wesentliche Unterschied liegt darin, wann der Cache ungültig wird: Laut OpenAI führen Änderungen am Reasoning-Effort oder an verfügbaren Tools nicht mehr zur Cache-Invalidierung. Anthropics Leitfaden für Sonnet 5.5 weist dagegen darauf hin, dass eine Änderung des übergeordneten Effort-Levels zwischen Requests den Cache bricht, und verweist auf eine Beta-Einstellung für Effort auf Nachrichtenebene. Agents, die den Aufwand mitten in einer Aufgabe anpassen, bekommen das direkt auf der Rechnung zu spüren.
Keine dieser Zahlen beziffert jedoch Ihre tatsächlichen Kosten pro akzeptierter Code-Änderung. Ein vermeintlich günstiger Durchlauf, der zwei Nachbesserungen und ein langwieriges Review erfordert, ist am Ende die teurere Variante.
So treffen Sie die Entscheidung auf Ihrer eigenen Codebasis
Lassen Sie denselben Task durch beide Runtimes laufen und messen Sie den menschlichen Zeitaufwand, der für die Abnahme des Ergebnisses nötig ist. Die Kriterien hierfür finden Sie im Leitfaden Coding-Agents auf der eigenen Codebasis vergleichen; hier ist das konkrete Setup für dieses Modellpaar.
Sharkly wählt keine Modelle aus. Die Agents-Dokumentation stellt dies unmissverständlich klar: „Der Agent folgt dem Standardmodell der Runtime. Er garantiert und zeigt keinen spezifischen Modellnamen an. Ändern Sie Modelle in der Runtime- oder Computer-Tool-Konfiguration, nicht am Agenten selbst.“ Die Modellauswahl erfolgt also auf dem Computer:
- Claude Code auf
claude-sonnet-5-5: Erfordert Claude Code v2.1.284 oder höher. Dasdefault-Modell von Claude Code ist Opus 5.5 für Pro, Max, Team, Enterprise und die Anthropic-API – ein Computer führt also Opus aus, solange dies nicht explizit geändert wird, und der Aliassonnetsteht nur auf der Anthropic-API für Sonnet 5.5. Pinnen Sie daher die vollständige ID und überprüfen Sie dies mitclaude --model claude-sonnet-5-5auf dem jeweiligen Host. Der Beitrag Sonnet-5.5-Agents in Sharkly ausführen beschreibt die genauen Schritte. - Codex auf
gpt-6-sol: Konfigurieren Sie das Modell in den Codex-Einstellungen auf diesem Computer; die Anleitung GPT-6-Sol-Agents in Sharkly ausführen zeigt das Vorgehen im Detail. - Temporäres Arbeitsverzeichnis auf beiden Agents: Jeder Durchlauf erhält ein isoliertes Verzeichnis, und Repository-gestützte Läufe können einen frischen Worktree vorbereiten, sodass sich die beiden Versuche niemals denselben Checkout teilen.
Halten Sie den Testaufbau schriftlich fest, bevor einer der beiden Läufe startet:
Task: SH-312, one real Task, same description and starting commit for both runs
Run A: Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B: Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept: the same acceptance test for both
Record: accepted y/n, human review minutes, reruns, files touched outside scope,
provider cost from your own Anthropic and OpenAI bills
Decide: after several Tasks of each kind you actually assign, not one
Weisen Sie den Task einem Agenten zu und starten Sie den anderen, indem Sie ihn in einem Kommentar erwähnen – in Sharkly lässt sich ein Agent, der nicht der Assignee ist, über eine explizite Erwähnung starten. Beide Durchläufe liefern ihre Ergebnisse an denselben Task zurück, sodass zwei Diffs, zwei Testläufe und alle Rückfragen in einer gemeinsamen Timeline gebündelt werden, statt über zwei separate Terminal-Verläufe verstreut zu sein. Wie dieser Vergleich anhand eines einzelnen Bugs samt Bewertungsmatrix aussieht, zeigt der Artikel Claude Code vs. Codex am selben Bug.
Gewichten Sie die Review-Minuten am stärksten. Anthropics Prompting-Leitfaden hebt hervor, dass Sonnet 5.5 auf jeder Aufwandstufe zusätzliche Tests, Dokumentationen und Hilfsdateien erstellt, sich bei langen Aufgaben auf den Stufen „low“ und „medium“ frühzeitig rückversichert und auf „xhigh“ und „max“ zusätzliche Review-Runden oder Reviewer-Subagents anstößt. Wie auch immer sich Codex mit Sol an denselben Stellen verhält – der Praxistest wird es aufdecken. All das schlägt sich direkt in der Review-Zeit nieder, taucht aber in keinem Benchmark-Score auf.
Warum „Beide“ eine legitime Antwort ist
Die öffentlich zugänglichen Daten küren keinen universellen Sieger – und Ihr interner Test wird es womöglich genauso wenig tun. Ein geteiltes Ergebnis ist eine wertvolle Erkenntnis, kein Fehlschlag.
Entscheiden Sie sich für eine einzige Runtime, wenn der Test nach Abzug der Review-Minuten keinen spürbaren Unterschied zeigt oder ein kleines Team den Aufwand auf ein einziges Abonnement und eine einheitliche Konfiguration beschränken möchte. Wer ohnehin nur Claude Code nutzt und rein terminal-basiert arbeitet, benötigt möglicherweise gar keinen übergeordneten Management-Layer. Behalten Sie beide, wenn die Ergebnisse je nach Aufgabentyp variieren oder wenn Sie im nächsten Monat problemlos das Standardmodell wechseln möchten, ohne Ihren gesamten Workflow umzubauen. Und „nächster Monat“ ist keineswegs hypothetisch: Opus 5.5, Sol und Luna erschienen an einem einzigen Tag, Sonnet 5.5 folgte nur sechs Tage später.
Beide Systeme parallel zu betreiben funktioniert allerdings nur, wenn der Task – und nicht die Runtime – als verbindliches Protokoll dient. Kein anderes Modell kann die Thinking-Blocks von Sonnet 5.5 verarbeiten. Wechselt ein Task also von einem Claude-Code-Agenten zu einem Codex-Agenten, bleibt der interne Gedankengang zurück, und nur das, was explizit im Task dokumentiert ist, wird übertragen. Entscheidungen, Annahmen und offene Fragen gehören daher in die Beschreibung oder in die Kommentare. Der Artikel Claude Code und Codex gemeinsam auf einer Codebasis einsetzen beleuchtet den Arbeitsalltag, während Sonnet 5.5 oder Opus 5.5 das Routing aufseiten von Claude behandelt.
Agents recherchieren, implementieren, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen die Ergebnisse ab. Die Runtime mag sich jedes Quartal ändern – Kontext, Fortschritt, Blocker, Resultate und das menschliche Review sollten von der Anforderung bis zum Release an einem zentralen Ort sichtbar bleiben.
Die Ausgabe dieser Fragestellung aus der Vorwoche, Opus 5.5 vs. GPT-6 Sol, stand vor dem spiegelbildlichen Problem: OpenAIs Veröffentlichung verglich Sol mit einem Claude-Modell, das nur wenige Stunden später überholt war. Definieren Sie Ihren Standard klar, testen Sie ihn an Ihrem eigenen Code und behalten Sie die Runtime als flexibel anpassbare Einstellung bei. Wenn Sie mehrere Coding-Agents parallel nutzen möchten, statt sich an ein einziges Ökosystem zu binden: Genau für diese Herausforderung wurde Sharkly entwickelt. Binden Sie einen Computer an, richten Sie je einen Agenten pro Runtime ein und weisen Sie beiden denselben realen Task zu.
