Claude Opus 5.5 vs. GPT-6 Sol: So wählst du die Standard-Runtime deiner Crew

Eine Zeile in einer Konfigurationsdatei entscheidet, wohin in diesem Quartal der Großteil der Tokens deines Teams fließt. Am 22.09.2026 änderten sich beide Kandidaten für diese Zeile gleichzeitig: Anthropic veröffentlichte Claude Opus 5.5, OpenAI veröffentlichte GPT-6 Sol und GPT-6 Luna. Wenn du mehrere Coding-Agents parallel laufen lässt, ist die Frage nicht, welches Modell klüger ist. Sondern welches deine Agents standardmäßig verwenden – und was das mit der Warteschlange an Arbeit macht, die darauf wartet, dass ein Mensch sie abnimmt.

In der Beweislage steckt ein Haken, den man kennen sollte, bevor man einen der beiden Launch-Posts liest. OpenAI hat Sol gegen Claude Opus 5 gebencht. Nicht gegen Opus 5.5. Opus 5.5 existierte noch nicht, als dieser Post geschrieben wurde, und erschien Stunden später zu 4 $ pro Million Input-Tokens gegenüber den 5 $ von Opus 5. Jede Zeile im OpenAI-Post, die „schlägt Opus 5 zu einem Bruchteil der Kosten“ lautet, ist also gegen ein Modell gemessen, das noch am selben Tag abgelöst wurde. Das macht die Zahlen nicht falsch. Es macht sie zu den zuletzt veröffentlichten Zahlen statt zu den aktuellen.

TL;DR

Eine Standard-Runtime ist das Modell, das deine Agents verwenden, wenn niemand etwas anderes gewählt hat – in der Praxis betrifft das die meisten Runs. Wähle sie anhand von drei Achsen: Kosten pro abgeschlossener Aufgabe, wie lange sie eine Aufgabe hält, bevor sie dich braucht, und was sie tut, wenn sie feststeckt. Nach den veröffentlichten Zahlen ist Sol pro abgeschlossener Aufgabe günstiger, wobei der einzige veröffentlichte Vergleich gegen Opus 5 läuft – und Opus 5.5 ist das Modell, das bei einer langen Aufgabe ohne Unterbrechung dranbleibt. Niemand hat die beiden auf einem gemeinsamen Harness gegeneinander laufen lassen. Behandle also beide Launch-Posts als Anbieterbehauptungen und kläre es in deinem eigenen Repository.

Was die Anbieter tatsächlich veröffentlicht haben

Anthropic gibt an, dass Opus 5.5 im Betrieb 40 % weniger kostet als Opus 5, etwa 30 % schneller Ausgaben erzeugt und 18 Stunden oder länger bei der Aufgabe bleibt. Die maximale Ausgabe liegt bei 128k Tokens, und ein Fast-Modus wird separat mit 8 $ / 40 $ berechnet.

OpenAI gibt an, dass Sol und Luna jeweils 50 % günstiger sind als der Aktionspreis von GPT-5.6. Das Wort „promotional“ stammt von OpenAI selbst und es ist wichtig: Der Vergleich bezieht sich auf einen rabattierten Preis, nicht auf den Listenpreis von GPT-5.6. OpenAI sagt außerdem, dass GPT-6 Astra „weiterhin in allen Bereichen unser bestes Modell ist“ – eine nützliche Erinnerung daran, dass Sol die Preis-Leistungs-Stufe der eigenen Familie ist, nicht das Flaggschiff.

Achse 1: Kosten pro abgeschlossener Aufgabe, nicht pro Million Tokens

Der Token-Preis ist nur ein Näherungswert für die Zahl, die du tatsächlich zahlst. Ein Modell zum halben Preis, das drei Anläufe braucht, kostet mehr als eines, das es in einem einzigen Durchlauf schafft. OpenAI veröffentlicht die Kosten pro Aufgabe direkt neben dem Score, was ungewöhnlich transparent ist.

Die erste Zeile ist die, die alle zitieren. Sol mit extra-high Reasoning erzielt einen höheren Wert als Claude Opus 5 mit max Reasoning – bei etwa 9 % der Kosten pro Aufgabe von Opus 5. Multipliziert man 0,27 $ mit 11,1, landet Opus 5 bei max auf diesem Harness bei knapp 3 $ pro Aufgabe. Das ist unsere Rechnung aus zwei von OpenAI genannten Zahlen und keine Zahl, die OpenAI selbst gedruckt hat.

Jetzt kommt der Haken. Anthropic gibt an, dass sich Opus 5.5 40 % günstiger betreiben lässt als Opus 5, also ist die 3-$-Zahl veraltet. Sie sinkt aber auch nicht einfach um dieselben 40 %, denn die Kosten pro Aufgabe hängen davon ab, wie viele Tokens ein Modell bis dorthin verbrennt, nicht allein vom Listenpreis. Die veröffentlichte Lücke war groß, eine Seite davon bewegte sich noch am selben Tag um einen genannten Betrag, und niemand hat den Vergleich neu durchgeführt. Wenn du diese Zahl für deine Codebasis willst, führe den Vergleich in deinem eigenen Repository durch, statt darauf zu warten, dass ein Labor ihn für dich durchführt.

Zur Einordnung: OpenAI berichtet, dass der Median seiner Forscher über 600 $ pro Tag für Coding-Agents ausgibt, das 90. Perzentil 7.000 $ pro Tag. Die Kosten pro Aufgabe sind schnell keine Abstraktion mehr.

Achse 2: Wie lange es die Aufgabe hält

Die beiden Anbieter haben dasselbe Problem an unterschiedlichen Stellen gelöst.

Anthropic hat es im Modell gelöst. Opus 5.5 bleibt 18 Stunden oder länger bei der Aufgabe. Ein Run, der deinen Arbeitstag überdauert, verändert die Aufsicht: Du beobachtest ihn nicht mehr, sondern kehrst zu ihm zurück – was nur funktioniert, wenn der Run irgendwo berichtet, das nicht das Terminal ist, das du geschlossen hast.

OpenAI hat es im Cache gelöst. GPT-6 rabattiert gecachte Input-Reads um 90 %, erhöht die Trefferraten standardmäßig und bricht – was für Agent-Arbeit wichtig ist – den Cache nicht mehr, wenn du den Reasoning-Aufwand oder die Menge der verfügbaren Tools änderst. Explizite Breakpoints lassen dich wählen, wo ein gecachtes Präfix endet. GitHub berichtet von über 50 % weniger Prompt-Tokens, die über Milliarden von Anfragen hinweg frisch verarbeitet werden müssen. Ein langer Agent-Run besteht größtenteils darin, denselben Kontext viele Male zu lesen. Das ist also eine Lösung für die Kosten der Dauer, nicht für die Dauer selbst.

Setze Opus 5.5 als Standard ein, wenn deine typische Task eine Migration, ein breit angelegtes Refactoring oder irgendetwas ist, bei dem ein Abbruch auf halbem Weg mehr kostet als die Tokens. Setze Sol als Standard ein, wenn deine typische Task begrenzt, viele Male am Tag wiederholt und günstig erneut auszuführen ist. Die meisten Teams haben beide Arten – deshalb ist der Standard weniger wichtig, als bewusst mit den Ausnahmen umzugehen.

Achse 3: Was es tut, wenn es feststeckt

Für diese Achse gibt es keinen Benchmark, und sie ist diejenige, die Support-Anfragen erzeugt.

Artificial Analysis, ein Drittanbieter und nicht einer der Anbieter, hat die „max“-Reasoning-Varianten gemessen: 115,2 Output-Tokens pro Sekunde für Sol bei 102,15 Sekunden bis zum ersten Token und 153,9 Tokens pro Sekunde für Luna bei 124,23 Sekunden. Das sind Max-Effort-Konfigurationen, und du solltest sie gegen das aktuelle Listing prüfen, bevor du darauf wettest. Entscheidend ist die Form: Bei hohem Reasoning-Aufwand sind die günstigen Modelle nicht die schnell startenden.

Ein Agent, der 102 Sekunden lang nachdenkt, und ein Agent, der hängt, sehen im Terminal identisch aus. Ebenso einer, der vor 40 Minuten fertig wurde, und einer, der angehalten hat, um eine Frage zu stellen, die niemand gesehen hat. Kein Modell-Release behebt das. Ein Status, der zur Task zurückkehrt, schon: In Progress, Waiting for human, Failed, Ready for release – mit angehängtem Log und der Frage. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.

Miss der Art, wie jede Runtime Fortschritt und Fehler signalisiert, genauso viel Gewicht bei wie der Benchmark-Tabelle. Den Status liest du hundertmal pro Woche, den Benchmark einmal.

Stell die beiden Benchmark-Tabellen nicht nebeneinander

Beide Anbieter haben diese Woche eine AutomationBench-Zahl veröffentlicht. OpenAI meldete für Sol bei extra-high Reasoning 33,2 % auf AutomationBench 1.0.6. Anthropic meldete für Opus 5.5 40,0 % auf AutomationBench. Beide meldeten OSWorld 2.0, mit 60,5 % bzw. 81,8 %, wobei sich OpenAIs Zahl auf das Offline-Set bezieht.

Das ist kein direkter Vergleich. Unterschiedliche Reasoning-Einstellungen, mindestens eine andere Benchmark-Variante, unterschiedliche Harnesses, keine gemeinsame Zahl zu Kosten pro Aufgabe – und jeder Durchlauf von der Partei durchgeführt, die davon profitiert. Die Posts, die Opus 5.5 anhand konkreter Zahlen mit GPT-6 Astra vergleichen, sind Tweets, keine Anbieterdaten. Artificial Analysis veröffentlicht zwar einen gemeinsamen Index, der Opus 5.5 mit 58 auf Platz eins von 212 Modellen führt, Sol mit 48 und Luna mit 37 – aber das ist ein Drittanbieter-Aggregat und keine Messung deiner Codebasis.

Die Entscheidung, die den nächsten Launch übersteht

Schreib den Standard auf. Nicht als Vorliebe, die jemand hegt, sondern als Regel, die am Agent hängt: Dieser Agent läuft auf dieser Runtime, diese Tasks gehen an ihn, und hier ist der günstigere Agent, der die Routineaufgaben übernimmt. Etwa so, aufbewahrt dort, wo das Team es liest:

Default Runtime: Claude Code on claude-opus-5-5
  Tasks: migrations, wide refactors, anything that fails badly halfway
Second Runtime: Codex on gpt-6-sol
  Tasks: bounded, repeated many times a day, cheap to retry
Escalation: a Sol Task that fails twice returns to the Task for a person,
  it does not silently re-run on the expensive Runtime

Das ist es, was aus welches Modell welche Aufgabe bekommt Durchsatz macht, und es übersteht den nächsten Launch – denn wenn sich die Antwort ändert, bearbeitest du eine Regel, statt sechs Leute zu fragen, was sie verwendet haben. Zwei Labore haben am selben Tag ihre stärkste Preis-Leistungs-Stufe ausgeliefert, und eines hat gegen ein Modell gebencht, das Stunden später auslief. Eine Standard-Runtime, die du an einer Stelle ändern kannst, ist mehr wert, als diese Woche richtig zu wählen.

Was keiner der beiden Launches geändert hat, ist die Warteschlange. Die Kosten pro abgeschlossener Aufgabe sind auf beiden Seiten stark gefallen, ein festes Budget kauft jetzt also ein Vielfaches mehr an fertiger Agent-Arbeit als letzte Woche. Zusätzliche Reviewer-Stunden kauft es keine einzige. Die Review-Kapazität ist die Obergrenze, und eine Preissenkung drückt mehr Volumen dagegen, statt sie zu entlasten. Halte das Ziel, den Run, die Blocker, den Diff und die menschliche Review von der Anfrage bis zum Release an einem Ort sichtbar, und die Standard-Runtime wird zu einer Einstellung statt zu einer Wette.

Sharkly führt das Modell nicht aus und wählt es nicht für dich aus. Es ist die gemeinsame Task-, Computer-, Kontext- und Review-Schicht um die Tools, die das tun. Wenn du weiterhin mehrere Coding-Agents nutzen willst, statt dich auf ein Ökosystem festzulegen, ist das genau das Problem, für das es konzipiert ist. Verbinde einen Computer, erstelle auf jeder Runtime einen Agent und gib ihnen dieselbe langweilige Task.