Gemini 4 Argon, GPT-6 Astra, Claude Opus 5.5: Drei Frontier-Modelle, drei verschiedene Gewinner

Googles Ankündigungsbeitrag zu Gemini 4 Argon enthält eine Benchmark-Tabelle mit 19 Zeilen – und nach unserer Auswertung dieser Tabelle führt Argon in 13 Zeilen klar und teilt sich in einer weiteren den ersten Platz. Die fünf Kategorien, in denen es unterliegt, sind keineswegs zufällig. GPT-6 Astra gewinnt FrontierSWE v2, Terminal-Bench Science und OSWorld-2.0; Claude Opus 5.5 entscheidet Terminal-bench 4.0 und PostTrainBench für sich. Dabei handelt es sich um beide Terminal-Bench-Zeilen, eine Zeile für agentenbasiertes Coden, die ML-Engineering-Zeile und eine der beiden Computer-Use-Zeilen: also um einen Großteil der Aufgaben, für die ein Coding-Team seine Runs tatsächlich aufwendet. Und die Frage ist längst nicht mehr hypothetisch. Seit dem 13. Oktober 2026 ist Argon in der kostenpflichtigen Gemini-API allgemein als gemini-4-argon verfügbar.

Auf die Frage „Welches Modell gewinnt?“ gibt es je nach Zeile also drei verschiedene Antworten – und für ein Team, das mehrere Coding-Agents einsetzt, ist das alles andere als nebensächlich. Wenn jeder Agent auf dem Board dieselbe Runtime nutzt, übernimmt das Team mit den Stärken eines Anbieters auch dessen Schwächen, und jeder neue Modell-Launch entfacht die Diskussion von vorn. Welcher Agent woran arbeitet, was abgeschlossen ist, was ein Review benötigt: Nichts davon sollte davon abhängen, wer in dieser Woche gerade eine Benchmark-Tabelle anführt.

TL;DR

Kein führendes KI-Labor dominiert jede Kategorie – nicht einmal auf der eigenen Benchmark-Tabelle. Betrachten Sie jeden neuen Modell-Launch als Anhaltspunkt für das Routing, nicht als Grund für eine sofortige Migration: Binden Sie mehr als eine Runtime an, halten Sie die Routing-Regeln schriftlich fest (einen Standard, die Bedingungen, unter denen ein Task an einen anderen Agenten übergeben wird, sowie die Zuständigkeit für das Review) und testen Sie das Ganze an drei Tasks aus Ihrer eigenen Codebasis. Astra läuft über Codex, Opus 5.5 über Claude Code und Gemini-Modelle über das Gemini CLI mit einem kostenpflichtigen Key. Google hat bisher nicht bestätigt, dass das Gemini CLI Argon unterstützt; unterziehen Sie gemini-4-argon daher einem Smoke-Test, bevor Sie ihm echte Tasks anvertrauen.

Was Googles Tabelle nach Aufgabentyp aussagt

Die für Coding-Agents relevanten Zeilen, gruppiert nach Googles eigenen Kategorien:

Allein in der Kategorie für agentenbasiertes Coden gibt es vier Zeilen und drei verschiedene Spitzenreiter. Seinen Durchmarsch erzielt Argon bei Wissensaufgaben, Long-Context-Auswertungen und multimodalen Benchmarks – Bereiche, die für ein Team, dessen Tasks in einem Diff enden, weniger ins Gewicht fallen.

Man sollte diese Zahlen jedoch mit einer gewissen Vorsicht betrachten: Es handelt sich um Googles eigene Tabelle. Google hat Argon bei mehreren Benchmarks selbst getestet, die Werte der Konkurrenz basieren größtenteils auf Selbstauskünften oder stammen von öffentlichen Leaderboards, und die Test-Harnesses unterscheiden sich. In der Evaluierungsmethodik ist die Quelle für jede einzelne Zelle aufgeführt. Auch unabhängige Ergebnisse seit dem Launch widersprechen einander: Scale AIs Humanity’s Sixth Sense sieht Argon mit 55,4 % vor GPT-6 Astra mit 53,6 %, Cursor stuft es im hauseigenen CursorBench auf Augenhöhe mit Opus 5.5 ein, und Artificial Analysis führt Argon (High) mit Stand vom 15. Oktober auf Platz acht von 216 gelisteten Modellvarianten.

Auch der Preis bringt keine eindeutige Entscheidung. Bis zum 30. November 2026 kostet Argon 2 $ pro Million Input-Tokens und 10 $ pro Million Output-Tokens, ab dem 1. Dezember steigen die Preise auf 4 $ bzw. 20 $. Dieser spätere Tarif entspricht exakt dem von Opus 5.5. Astra wiederum ist mit 10 $ und 50 $ gelistet.

Kein Labor dominiert jede Kategorie – keines sollte das gesamte Board beherrschen

Dieses Argument stützt sich auf die Daten der Hersteller selbst, nicht auf unsere. Wenn selbst Googles eigene Tabelle – erstellt von Google, um Googles Modell ins beste Licht zu rücken – dennoch fünf Zeilen an zwei Konkurrenten abtreten muss, dann gibt es schlicht nicht das eine beste Modell für Coding-Agents. Es gibt lediglich das beste Modell für einen bestimmten Aufgabentyp, für das aktuelle Quartal und auf einem bestimmten Test-Harness.

Das verändert den Umgang mit neuen Modell-Launches. Die verlockende Reaktion ist eine vollständige Migration: die Standard-Runtime austauschen, das Setup umschreiben und die Gewohnheiten aller Beteiligten umkrempeln. Der weitaus wirtschaftlichere Ansatz besteht darin, das neue Modell schlicht als weiteren Kandidaten für genau jene Tasks zu behandeln, in denen es glänzen kann, und den Rest des Boards unberührt zu lassen. Wir haben bereits dargelegt, dass der beste Coding-Agent weniger entscheidend ist als die Art und Weise, wie Sie die Arbeit organisieren; eine Tabelle, in der drei Modelle jeweils Teilbereiche gewinnen, untermauert dieses Argument mit Zahlen.

Die nüchterne Abwägung lautet daher:

• Bleiben Sie bei einer Standard-Runtime, wenn die meisten Ihrer Tasks ähnlich gelagert sind und eine einzelne Person sämtliche Reviews übernimmt. Eine zweite Runtime bedeutet eine zusätzliche Konfiguration, die gepflegt werden muss, eine weitere Rechnung und eine neue Reihe möglicher Fehlerquellen.
• Nutzen Sie zwei oder drei Runtimes, wenn sich Ihre Tasks auf Terminal-lastige Arbeit, UI-Verifizierungen und das Erfassen großer Codebasen verteilen – denn genau an diesen Schnittstellen teilt sich auch das Benchmark-Feld.

Halten Sie die Routing-Regeln schriftlich fest

Eine Routing-Regel, die lediglich im Kopf eines Entwicklers existiert, ist reine Gewohnheit – und Gewohnheiten überstehen weder Neuzugänge im Team noch die Woche eines Modell-Launches. Halten Sie die Regeln dort fest, wo das gesamte Team sie einsehen kann:

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

Jede Bedingung benennt die zugrundeliegende Benchmark-Zeile sowie ein leicht erkennbares Aufgabenprofil. Die Review-Zeile ist dabei die wichtigste: Wenn ein Modell ein Diff prüft, das es nicht selbst geschrieben hat, erhält man eine kostengünstige Zweitmeinung – während die finale Abnahme in menschlicher Hand bleibt.

Wo diese Regel hinterlegt wird, hängt davon ab, wer das Routing steuert. Wenn Menschen den Assignee auswählen, gehört sie in die schriftlichen Vereinbarungen des jeweiligen Space. Übernimmt ein Crew-Leader das Routing, gehört sie in die Crew-Instruktionen. In beiden Fällen fließt das Ergebnis in denselben Task zurück, sodass der gesamte Vergleichsverlauf an einem zentralen Ort gebündelt bleibt. Der Beitrag Welches Modell für welchen Coding-Task geht noch detaillierter darauf ein, wie Aufgabenprofile auf Modellrollen abgestimmt werden.

Testen Sie die Regel an Ihrer eigenen Codebasis, bevor Sie sich darauf verlassen

Ein Benchmark-Ergebnis setzt einen Aufgabentyp lediglich auf die Auswahlliste; welches Modell zum Standard wird, entscheidet Ihr eigenes Repository. Die Methode aus dem Leitfaden Wie Sie Coding-Agents an der eigenen Codebasis vergleichen lässt sich hervorragend auf diese Tabelle anwenden, da die Benchmark-Ergebnisse bereits vorgeben, welche drei Tasks Sie auswählen sollten:

1. Einen Terminal-lastigen Task, beispielsweise einen fehlgeschlagenen CI-Job.
2. Einen Task, dessen Änderungen über eine Benutzeroberfläche verifiziert werden müssen.
3. Eine Fragestellung, für die ein Großteil des Repositorys im Kontextfenster geladen sein muss.

Geben Sie jedem Agenten dieselbe Task-Beschreibung und dieselben Akzeptanzkriterien, und nutzen Sie den Modus „Create temporary directory“, damit jeder Run seinen eigenen Worktree erhält. Bewerten Sie anschließend das tatsächliche Ergebnis, das in den Task zurückfließt, und nicht die Behauptungen des Agenten: das Diff, die durchgeführten Prüfungen und deren Resultate, die Rückfragen sowie die Zeit, die ein Mensch für die Abnahme benötigt hat.

Argon kann sofort in diesen Vergleich einbezogen werden, sobald ein einzeiliger Smoke-Prompt mit gemini-4-argon in Ihrem Gemini CLI erfolgreich durchläuft. Führen Sie dieselben drei Tasks damit aus, bevor Sie weitere Änderungen vornehmen. Der Vergleich zwischen Opus 5.5 und GPT-6 Sol als Standard-Runtime beleuchtet die Kosten pro erledigtem Task bei genau dieser Entscheidung.

Wo die einzelnen Modelle laufen (Stand: 15. Oktober 2026)

Die Zeilen zu Gemini bergen jedoch einen Fallstrick. Seit dem 18. Juni 2026 unterstützt das Gemini CLI laut Googles Umstellungsmitteilung keine Accounts von Google AI Pro, Ultra oder die kostenlose Version von Code Assist für Einzelpersonen mehr. Zwar beinhalten Pro und Ultra den Zugriff auf Argon in der Gemini-App, doch ein Abonnement ist kein API-Key – und für Argon gibt es kein kostenloses API-Kontingent.

Sharkly wählt keine Modelle eigenständig aus. In der Dokumentation zu den Agents heißt es dazu ausdrücklich: „Der Agent folgt dem Standardmodell der Runtime. Er garantiert oder zeigt keinen spezifischen Modellnamen an.“ Das Modell wird über benutzerdefinierte Argumente am Agenten oder an der Runtime bzw. in der Konfiguration des jeweiligen Tools auf dem Computer festgelegt. Wenn in der Routing-Regel vom „Codex-Agenten“ die Rede ist, meint dies also einen Agenten auf einer Codex-Runtime, der für die Nutzung von Astra konfiguriert ist.

Die detaillierten Einrichtungsschritte finden Sie in den Beiträgen GPT-6 Astra in Sharkly, Claude Opus 5.5 in Sharkly sowie – für die Konfiguration des Gemini CLI und den Wechsel zu Argon – Gemini 4 Argon für Coding-Agents.

Die Tabelle verändert sich – das Board sollte es nicht

Der nächste Modell-Launch wird diese Tabelle erneut umwerfen. Was hingegen stabil bleiben sollte, ist das gesamte System um das Modell herum: die Routing-Regeln, die Tasks, die Belege und Resultate aus jedem Run sowie die Person, die das Ergebnis final abnimmt. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen das Ergebnis ab.

Wenn Sie mehrere Coding-Agents flexibel parallel einsetzen möchten, anstatt sich an ein einziges Ökosystem zu binden: Genau für diese Herausforderung wurde Sharkly entwickelt.