Artificial Analysis Coding Agent Index setzt Claude auf Platz eins, doch die Kosten ordnen die Spitzenreiter neu
Artificial Analysis setzte Claude Sonnet 5.5 mit 68 Punkten auf Platz eins, doch die neuen Ergebnisse zu Coding Agents erzählen bei den Kosten eine deutlich weniger komfortable Geschichte.
Der Artificial Analysis Coding Agent Index platziert Claude Code mit Sonnet 5.5 bei maximalem Aufwand vor Gemini 4 Argon und GPT-6.1 Sol. Der Sieger verbraucht pro Aufgabe jedoch erheblich mehr Zeit, Tokens und API-Budget als seine nächsten neuen Rivalen.
Dieser Unterschied verändert die praktische Entscheidung für Entwicklungsteams. Claude führt beim zusammengesetzten Benchmark, während Codex mit GPT-6.1 Sol nahezu vergleichbare Ergebnisse mit einem Bruchteil der gemessenen Ressourcen erzielt. Gemini 4 Argon liegt dazwischen und verbindet einen starken Gesamtwert mit einem bemerkenswerten Vorteil bei langfristigen Softwareaufgaben.
Der ursprüngliche Benchmark-Beitrag präsentiert die drei Veröffentlichungen als neue Spitzenreiter. Die zugrunde liegenden Ergebnisse belegen ihre Bedeutung, rechtfertigen jedoch kein einfaches Podium mit drei Plätzen. Auch andere Konfigurationen, darunter Claude Opus 5.5, erscheinen nahe der Spitze.
Noch wichtiger ist, dass jedes Ergebnis zu einem Modell, einer Reasoning-Einstellung und einem Agent-Harness gehört. Die Rangliste testet nicht allein abstrakte Modellintelligenz. Sie testet vollständige Coding-Systeme wie Claude Code, Codex und Antigravity CLI.
Diese Unterscheidung steht im Zentrum der Geschichte. Teams wählen nicht mehr nur das Modell mit dem höchsten Wert. Sie entscheiden, wie viel zusätzliche Zeit und Rechenleistung ihnen ein weiterer Benchmark-Punkt wert ist.
Was sich im Artificial Analysis Coding Agent Index geändert hat
Die jüngsten Ergebnisse trennen Benchmark-Führerschaft und operative Effizienz deutlicher als frühere Modellvergleiche.
Artificial Analysis bewertet Coding Agents anhand von End-to-End-Arbeit statt anhand isolierter Fragen zur Code-Vervollständigung. Der Index verbindet Repository-Änderungen, Terminal-Arbeit und Codebase-Verständnis zu einem Wert.
Claude Code mit Sonnet 5.5 bei maximalem Aufwand führt mit 68 Punkten. Die Teilwerte liegen bei 72 Prozent für DeepSWE v1.1, 66 Prozent für Terminal-Bench 4.0 und 67 Prozent für SWE-Atlas-QnA.
Antigravity CLI mit Gemini 4 Argon erzielt 64 Punkte. Die Konfiguration erreicht 79 Prozent bei DeepSWE, 56 Prozent bei Terminal-Bench und 56 Prozent bei Repository-Fragen.
Codex mit GPT-6.1 Sol bei xhigh-Aufwand erzielt 63 Punkte. Diese Konfiguration erreicht 73 Prozent bei DeepSWE, 55 Prozent bei Terminal-Bench und 61 Prozent bei SWE-Atlas-QnA.
Zwischen Claude und Sol liegen damit nur fünf Punkte. Artificial Analysis maß bei der Claude-Konfiguration allerdings etwa 8,7-mal so viele Tokens pro Aufgabe. Sie lief zudem nahezu sechsmal so lange.
Die gemessenen API-Kosten zeigen einen noch größeren Abstand. Die Claude-Konfiguration mit maximalem Aufwand kostet pro Aufgabe etwa 13,6-mal so viel wie xhigh Sol in Codex.
Gemini 4 Argon liegt zwischen diesen Extremen. Seine gemessenen Kosten betragen ungefähr das 5,6-Fache von Sols Kosten, während sein Indexvorsprung einen Punkt beträgt. Es verbraucht etwa 4,3-mal so viele Tokens und benötigt mehr als doppelt so viel Zeit.
Der Benchmark-Vergleich erzählt daher zwei Geschichten. Claude erzielt den höchsten zusammengesetzten Wert, während Sol unter diesen drei Konfigurationen das beste gemessene Verhältnis von Wert zu Kosten liefert.
Artificial Analysis berichtet außerdem mehrere Aufwandseinstellungen für Sonnet 5.5. Dieses Detail ist wichtig, weil maximaler Aufwand nicht die Standardeinstellung von Claude Code ist.
Sonnet 5.5 bei xhigh-Aufwand erzielt 63 Punkte und entspricht damit Sols Spitzenwert. Es verwendet mehr als doppelt so viele Tokens wie Sol und verursacht gemessene Kosten, die mehr als dreimal so hoch sind.
Bei hohem Aufwand erzielt Sonnet 55 Punkte. Bei mittlerem Aufwand, der Standardeinstellung in Claude Code, sind es 46 Punkte. Diese Ergebnisse zeigen, wie stark das Reasoning-Budget das bewertete Produkt verändert.
Dasselbe Muster zeigt sich innerhalb der Sol-Ergebnisse. GPT-6.1 Sol bei mittlerem Aufwand erzielt 61 Punkte, nur zwei Punkte weniger als seine xhigh-Konfiguration. Auch die gemessenen Kosten und die Laufzeit sinken erheblich.
Maximales Reasoning führt nicht automatisch zum besten Ergebnis. Sols xhigh-Ergebnis übertrifft sein Ergebnis bei maximalem Aufwand in der veröffentlichten Bewertung um drei Punkte.
Dieses kontraintuitive Resultat erinnert daran, dass Agent-Benchmarks Varianz enthalten. Mehr Inferenzzeit kann helfen, aber auch längere Abläufe, unnötige Tool-Aufrufe oder unproduktives Überdenken erzeugen.
Der Spitzenreiter bleibt Claude Code mit Sonnet 5.5 bei maximalem Aufwand. Die folgenschwerere Veränderung besteht darin, dass Käufer nun sehen können, wie hoch die letzten fünf Punkte bepreist sind.
Der Benchmark misst Systeme, nicht allein Modelle
Ein Wert für einen Coding Agent spiegelt das Zusammenspiel aus Modell, Harness, Tools und Reasoning-Budget wider.
Der Coding Agent Index v1.5 verwendet drei gleich gewichtete Komponenten. Laut der veröffentlichten Index-Methodik prüft jede Komponente einen anderen Teil der Softwarearbeit.
DeepSWE v1.1 enthält 113 langfristige Aufgaben. Agents müssen bestehende Repositories verändern, während separate Verifizierungsumgebungen beurteilen, ob ihre eingereichten Patches bestehen.
Terminal-Bench 4.0 enthält 66 Aufgaben aus Bereichen wie Software Engineering, Machine Learning, Sicherheit und Systemadministration. Agents arbeiten in Kommandozeilenumgebungen; anschließend bewerten Test-Suites ihre Ergebnisse.
SWE-Atlas-QnA enthält 124 Fragen zu Repositories. Diese Aufgaben messen, ob ein Agent unbekannten Code nachvollziehen und sein Verhalten korrekt erklären kann.
Jede Aufgabe erhält drei Versuche. Artificial Analysis berechnet für jede Komponente Pass-at-one-Ergebnisse und gewichtet die drei Komponenten im zusammengesetzten Index gleich.
Diese Struktur ist breiter angelegt als ein herkömmlicher Test zur Codegenerierung. Sie belohnt Agents, die Repositories untersuchen, Tools auswählen, Terminals bedienen, Kontext aufrechterhalten und Fehler korrigieren können.
Dadurch wird auch das Harness wichtig. Ein Harness ist die Softwareschicht, die ein Modell mit Dateien, Terminals, Anweisungen, Kontextverwaltung und Tool-Ausführung verbindet.
Claude Code, Codex und Antigravity CLI bieten keine identischen Workflows. Sie können Kontext unterschiedlich verpacken, unterschiedliche Muster bei der Tool-Nutzung fördern oder verschiedene Grenzen setzen.
Folglich kann der Benchmark nicht belegen, dass Sonnet 5.5 immer ein besseres Coding-Modell als GPT-6.1 Sol ist. Er belegt, dass eine getestete Claude-Code-Konfiguration höher abschnitt als eine getestete Codex-Konfiguration.
Die Unterscheidung wird in den Teilwerten sichtbar. Gemini 4 Argon führt das Trio bei DeepSWE mit 79 Prozent an, obwohl es insgesamt hinter Claude rangiert.
Sol übertrifft Sonnet bei maximalem Aufwand bei DeepSWE knapp. Claude baut seine Gesamtführung durch Terminal-Bench und SWE-Atlas-QnA aus, wo es größere Vorsprünge erzielt.
Die Ergebnisse beschreiben daher unterschiedliche Fähigkeitsprofile. Gemini wirkt bei den langfristigen Repository-Änderungen des Benchmarks am stärksten. Claude erscheint über Terminal-Arbeit und Repository-Verständnis hinweg ausgewogener.
Sol bleibt in allen drei Bereichen konkurrenzfähig und nutzt dabei weniger gemessene Ressourcen. Es gewinnt keine enthaltene Komponente gegen beide Rivalen, vermeidet jedoch eine gravierende Schwäche.
Diese Ausgewogenheit ist für den Produktionseinsatz relevant. Ein Team, das ein großes Repository pflegt, könnte die Fertigstellung von Patches höher bewerten als die Beantwortung von Repository-Fragen. Ein anderes Team benötigt möglicherweise zuverlässige Terminal-Arbeit in unterschiedlichen Umgebungen.
Die einzelne Zahl des Index hilft Leserinnen und Lesern, das Feld schnell zu überblicken. Bei der Auswahl eines Tools für eine klar definierte Arbeitslast sollte sie die Teilwerte nicht ersetzen.
Artificial Analysis bündelt außerdem Daten zu Tokens, Kosten und Zeit aus derselben Benchmark-Suite. Fehlende Telemetrie wird aus dem jeweiligen Durchschnitt ausgeschlossen, statt als null behandelt zu werden.
Die Kostenberechnung berücksichtigt reguläre Eingabe, zwischengespeicherte Eingabe, Cache-Schreibvorgänge, Reasoning- und Output-Tokens, wenn Anbieter diese Kategorien separat bepreisen. Sie bildet API-Kosten pro Token ab, nicht Abonnementpreise.
Die berichteten Kosten schließen außerdem mehrere operative Ausgaben aus. Sie umfassen weder Engineering-Integration, menschliche Überprüfung, Einrichtung der Umgebung, Sicherheitskontrollen noch die Folgen eines fehlerhaften Patches.
Diese Ausschlüsse schwächen den Vergleich nicht. Sie definieren, was er beantworten kann: wie viel Modellnutzung die bewerteten Agents unter diesem Test verbrauchten.
Sie erklären auch, warum der günstigste Benchmark-Lauf nicht immer den günstigsten akzeptierten Pull Request erzeugt. Ein schwächeres Ergebnis kann zusätzliche Kosten für Überprüfung, Korrektur und erneute Ausführung verursachen.
Teams sollten daher sowohl die direkten Inferenzkosten als auch die Kosten pro erfolgreichem Ergebnis bewerten. Der veröffentlichte Index liefert nützliche Bestandteile, berechnet dieses umfassende betriebswirtschaftliche Maß jedoch nicht.
Claude Sonnet 5.5 gewinnt bei der Leistung – mit einem hohen Effizienzaufschlag
Claudes Führung ist innerhalb dieses Benchmarks real, doch maximaler Aufwand verwandelt einen moderaten Punktevorsprung in einen erheblichen Ressourceneinsatz.
Anthropic veröffentlichte Sonnet 5.5 am 28. September 2026. Das Unternehmen positioniert es als schnellere, kostengünstigere Ergänzung zu Opus 5.5 für klar abgegrenzte tägliche Aufgaben, Debugging und die Erstellung von Dokumenten.
Anthropics Details zur Modellveröffentlichung betonen den anpassbaren Aufwand. Niedrigere Einstellungen priorisieren Geschwindigkeit und Wirtschaftlichkeit, während höhere Einstellungen dem Modell mehr Zeit zum Schlussfolgern und Überprüfen seiner Arbeit geben.
Die Ergebnisse von Artificial Analysis zeigen beide Seiten dieses Designs. Die Umstellung von Sonnet von mittlerem auf maximalen Aufwand erhöht seinen Indexwert von 46 auf 68.
Diese Verbesserung um 22 Punkte ist erheblich. Sie geht mit ungefähr 21-mal so vielen Tokens, mehr als der zehnfachen Laufzeit und nahezu den 23-fachen gemessenen API-Kosten einher.
Maximaler Aufwand erzeugt zudem sehr lange Agent-Abläufe. Artificial Analysis verzeichnet für die führende Konfiguration etwa 266 Schritte pro Aufgabe und insgesamt 27,7 Millionen Tokens.
Diese Zahlen bedeuten nicht, dass jede reale Aufgabe dieselben Ressourcen verbraucht. Sie zeigen das durchschnittliche Verhalten über eine anspruchsvolle Benchmark-Suite mit Hunderten Aufgabenversuchen hinweg.
Sie verdeutlichen auch, wie das Modell gewinnt. Die leistungsstärkste Konfiguration erzeugt nicht einfach eine intelligentere Antwort mit demselben Budget. Sie verbringt wesentlich mehr Zeit mit der Interaktion mit ihrer Umgebung.
Diese Strategie zahlt sich im zusammengesetzten Wert aus. Claude liegt vier Punkte vor Gemini und fünf vor Sol. Es erzielt zudem die besten Ergebnisse des Trios in zwei der drei Komponenten-Benchmarks.
Der Aufschlag lässt sich schwerer rechtfertigen, wenn Claudes Einstellungen mit geringerem Aufwand in den Vergleich einbezogen werden. Sonnet bei xhigh entspricht Sols Wert von 63 Punkten, verbraucht jedoch mehr Tokens und Zeit und verursacht höhere gemessene Ausgaben.
Bei hohem Aufwand liegt Claude acht Punkte hinter Sol xhigh. Sein Ressourcenverbrauch liegt näher bei dem von Sol, doch die Leistungslücke wird bedeutend.
Bei mittlerem Aufwand wird Claude erheblich günstiger und schneller als in seiner maximalen Konfiguration. Sein Wert liegt jedoch 17 Punkte unter Sol xhigh und 18 Punkte unter Gemini.
Zwischen diesen Ergebnissen besteht kein Widerspruch. Anthropic ermöglicht Nutzerinnen und Nutzern, mehr Testzeit-Reasoning zu kaufen, und der Benchmark zeigt, dass zusätzliches Reasoning die Aufgabenerledigung verbessern kann.
Der Zielkonflikt betrifft die Skalierung. Eine einzelne Entwicklerin oder ein einzelner Entwickler kann einen langen, teuren Lauf für eine schwierige Migration akzeptieren. Ein Unternehmen, das Tausende routinemäßige Änderungen verarbeitet, steht vor einer anderen Rechnung.
Die beste Einstellung kann sich auch innerhalb eines Workflows unterscheiden. Ein Team kann mittleren Aufwand zur Exploration, hohen Aufwand zur Implementierung und maximalen Aufwand nur für hartnäckige Fehlschläge nutzen.
Diese Routing-Strategie würde den Zugang zu Claudes Spitzenleistung bewahren, ohne jedem Ticket das höchste Ressourcenbudget zuzuweisen. Sie erfordert Messung und klare Eskalationsregeln.
Claudes Benchmark-Sieg ist daher vor allem für Aufgaben relevant, bei denen die Qualität der Fertigstellung alle anderen Einschränkungen überwiegt. Beispiele sind schwierige Fixes über mehrere Repositories hinweg, anfällige Migrationen oder Vorfälle mit hohen Fehlerkosten.
Für volumenstarke Wartungsarbeit ist er weniger ausschlaggebend. Abhängigkeitsupdates, kleine Refactorings, Testgenerierung und routinemäßige Bugfixes profitieren oft von akzeptabler Qualität zu vorhersehbaren Kosten.
Deshalb sollte der Artificial Analysis Coding Agent Index nicht zu einer Kaufabkürzung werden. Das Ergebnis von 68 Punkten steht für eine Spitzenkonfiguration, nicht für eine automatische Standardeinstellung.
GPT-6.1 Sol und Gemini 4 Argon setzen Claude aus unterschiedlichen Richtungen unter Druck
Sol fordert Claude bei der Effizienz heraus, während Argon bei langfristiger Repository-Arbeit konkurriert.
OpenAI stellte GPT-6.1 Sol am 29. September vor, einen Tag nachdem Anthropic Sonnet 5.5 veröffentlicht hatte. Google folgte am 30. September mit Gemini 4 Argon.
Das Timing gab Artificial Analysis innerhalb weniger Tage drei neue Frontier-Konfigurationen zum Vergleich. Ihre Benchmark-Positionen zeigen eine stärkere Differenzierung, als ihre Launch-Beschreibungen vermuten lassen.
OpenAI beschreibt Sol als nahezu Flaggschiff-Modell für Coding, Computernutzung und professionelle Arbeit bei niedrigeren Kosten. Die Sol-Modellkarte unterstützt fünf Reasoning-Einstellungen von niedrig bis maximal.
Im Coding Agent Index ist xhigh Sols beste getestete Einstellung. Sie erzielt 63 Punkte, während maximaler Aufwand 60 Punkte erreicht.
Dieses Ergebnis untergräbt die Annahme, dass das größte Reasoning-Budget immer die sicherste Wahl ist. Es legt nahe, dass Teams Aufwandseinstellungen benchmarken sollten, statt standardmäßig die höchste Stufe zu wählen.
Sols zentraler Vorteil ist seine Konsistenz pro Ressourceneinheit. Die xhigh-Konfiguration erledigt eine durchschnittliche Aufgabe in etwa 15,5 Minuten und verbraucht 3,2 Millionen Tokens.
Claude mit maximalem Aufwand benötigt etwa 90 Minuten und 27,7 Millionen Tokens. Gemini braucht etwa 34,5 Minuten und 13,7 Millionen Tokens.
Sol schneidet auch in jeder einzelnen Komponente konkurrenzfähig ab. Sein DeepSWE-Ergebnis von 73 Prozent übertrifft Claudes 72 Prozent, liegt jedoch hinter Geminis 79 Prozent.
Seine Werte bei Terminal-Bench und Repository-Fragen bleiben hinter Claude zurück. Diese Defizite verursachen den Abstand von fünf Punkten beim Gesamtergebnis.
Für viele Organisationen wird dieser Abstand akzeptabel sein. Sols geringerer Ressourcenverbrauch ermöglicht mehr Versuche, eine breitere Bereitstellung oder zusätzliche Überprüfung innerhalb desselben Budgets.
Der Vergleich belegt nicht, dass Sol universell wirtschaftlicher ist. Anbieterpreise können sich ändern, Caching-Muster unterscheiden sich, und interne Workloads können andere Token-Verteilungen erzeugen.
Er stützt jedoch eine starke Hypothese, die es zu prüfen lohnt. Wenn die Aufgaben eines Teams dem Benchmark ähneln, könnte Codex mit Sol ein besseres Verhältnis von Kosten und Leistung liefern als Claude mit maximalem Aufwand.
Gemini 4 Argon erzeugt eine andere Art von Druck. Google führte Argon als Modell für anhaltendes Reasoning über komplexe professionelle Workflows hinweg ein.
Googles Argon-Ankündigung beschreibt interne Anwendungen in den Bereichen Code-Migration, Speicheroptimierung, Forschung und Cybersicherheit. Diese Beispiele bleiben Unternehmensbehauptungen, sofern sie nicht unabhängig reproduziert werden.
Der Coding Agent Index liefert Drittanbieter-Evidenz für einen Teil dieser Darstellung. Argons DeepSWE-Ergebnis von 79 Prozent ist das stärkste der drei hervorgehobenen Systeme.
Dieses Ergebnis passt zu Googles Fokus auf langfristige Arbeit. Es deutet darauf hin, dass Argon für umfangreiche Repository-Änderungen Beachtung verdient, obwohl Claude den Gesamtindex anführt.
Argons schwächeres Ergebnis bei Repository-Fragen drückt sein Gesamtergebnis. Seine 56 Prozent liegen fünf Punkte hinter Sol und elf Punkte hinter Claude.
Dem Modell fehlt zudem Sols gemessene Effizienz. Argon gewinnt gegenüber Sol einen Gesamtpunkt, benötigt aber pro Aufgabe mehr als viermal so viele Tokens.
Das macht die Konfiguration nicht irrational. Eine höhere DeepSWE-Erfolgsquote kann für Organisationen mit schwierigen Implementierungsaufgaben den Ressourcenverbrauch überwiegen.
Die entscheidende Frage ist die Passung zum Workload. Sol wirkt als effizienter Generalist attraktiv, während Argon ein stärkeres Signal bei langfristigen Repository-Modifikationen liefert.
Claude bleibt bei seiner aggressivsten Einstellung der ausgewogene Leistungsführer. Der Marktdruck kommt von Rivalen, die unterschiedliche Teile dieses Vorsprungs weniger wertvoll machen.
Das ist ein gesünderes Wettbewerbsbild als ein universelles Ranking. Es gibt Engineering-Teams klar unterscheidbare Optionen statt drei nahezu austauschbarer Modellmarken.
Es erhöht auch die Bedeutung portabler Workflows. Teams sollten Prompts, Review-Praktiken und Kontextaufbereitung nicht an ein einziges Modell binden, sofern der Nutzen nicht messbar ist.
Ein durchsuchbares Verzeichnis von Anforderungen, Entscheidungen und früheren Änderungen kann diese Vergleiche konsistenter machen. Teams können eine Engineering-Wissensdatenbank nutzen, um diesen Kontext über Agentenversuche hinweg zu bewahren.
Das Ziel ist nicht, jede Woche Modelle zu wechseln. Es geht darum, Wechsel und Bewertung zu ermöglichen, wenn sich die Leistungsgrenze verschiebt.
Was die Zahlen nicht beweisen
Ein Benchmark-Vorsprung von fünf Punkten garantiert weder besseren Code, sicherere Deployments noch geringere gesamte Engineering-Kosten in einer realen Organisation.
Artificial Analysis veröffentlicht mehr methodische Details als viele Betreiber von Bestenlisten. Die Komponentenaufgaben, Versuchszahlen, Bewertungsmethoden und Effizienzdefinitionen sind dokumentiert.
Trotzdem bleibt ein Benchmark eine Stichprobe. Er kann nicht jede Sprache, Repository-Struktur, Abhängigkeitsumgebung, Sicherheitsrichtlinie oder jeden Review-Standard abbilden.
Der Index gewichtet seine drei Komponenten gleich. Ein reales Unternehmen bewertet Repository-Fragen, Terminal-Operationen und Patch-Fertigstellung nur selten in exakt gleichen Anteilen.
Eine Organisation verbringt möglicherweise den Großteil ihrer Zeit mit TypeScript-Diensten mit umfangreichen Tests. Eine andere pflegt eingebetteten C-Code, Datenpipelines oder regulierte Finanzsysteme.
Ihre interne Rangfolge kann von der öffentlichen Bestenliste abweichen. Ein Modell, das bei DeepSWE überzeugt, kann dennoch mit proprietären Frameworks oder schlecht dokumentiertem Legacy-Code kämpfen.
Pass-at-one-Bewertungen verdichten zudem wichtige Qualitätsunterschiede. Zwei Patches können beide einen automatisierten Verifier bestehen, sich aber bei Wartbarkeit, Sicherheit, Lesbarkeit oder architektonischer Passung unterscheiden.
Auch das Gegenteil ist möglich. Eine hilfreiche Teillösung kann an einer Verifier-Bedingung scheitern und dasselbe binäre Ergebnis erhalten wie ein unbrauchbarer Versuch.
SWE-Atlas-QnA führt eine weitere Abhängigkeit ein. Artificial Analysis verwendet einen automatisierten Judge, um zu entscheiden, ob Repository-Antworten alle erforderlichen Kriterien erfüllen.
Automatisierte Bewertung ermöglicht Evaluierung im großen Maßstab. Sie kann jedoch weiterhin Mehrdeutigkeit, Modell-Bias oder Bewertungsfehler übernehmen, insbesondere bei Erklärungen mit mehreren gültigen Formulierungen.
Die zusammengefassten Durchschnittswerte des Benchmarks verdecken auch die Streuung. Durchschnittliche Kosten zeigen nicht, ob die meisten Aufgaben vorhersehbar sind, während eine kleine Gruppe extrem lange Verläufe erzeugt.
Diese Varianz ist für die Budgetierung relevant. Ein Dienst kann einen moderaten Durchschnitt verkraften und dennoch unter einzelnen Läufen leiden, die übermäßig viele Tokens verbrauchen oder Umgebungen über Stunden belegen.
Auch das Agentenverhalten kann sich nach Produktupdates ändern. Tool-Auswahl, Kontextkomprimierung, Retry-Logik und versteckte Systemanweisungen können sich verschieben, ohne dass ein neuer öffentlicher Modellname erscheint.
Aus diesem Grund sollte der Benchmark als zeitgebundene Messung behandelt werden. Er ist keine dauerhafte Eigenschaft von Claude Code, Codex, Antigravity CLI oder ihren zugrunde liegenden Modellen.
Claude mit maximalem Aufwand verdeutlicht das Risiko, ein Spitzenergebnis als Standarderfahrung zu lesen. Die getestete Konfiguration ist wesentlich ressourcenintensiver als der mittlere Standard von Claude Code.
Der Index vergleicht außerdem API-Ausgaben nach Token. Abonnementlimits, ausgehandelte Enterprise-Tarife, regionale Verarbeitung und interne Infrastruktur können die tatsächliche Wirtschaftlichkeit eines Teams verändern.
Auch menschliche Kosten fehlen. Ein langsamerer Agent kann akzeptabel sein, wenn er asynchron arbeitet. Ein schnellerer Agent kann wertvoller sein, wenn ein Entwickler auf Feedback wartet.
Der Review-Aufwand ist eine weitere ungelöste Variable. Ein günstiger Patch, der eine umfassende Prüfung benötigt, kann insgesamt mehr kosten als ein teurer Patch, der nach einem kurzen Review akzeptiert wird.
Sicherheit verdient ähnliche Vorsicht. Keiner der Schlagzeilenwerte allein belegt, dass ein Agent Least-Privilege-Zugriff einhält, bösartigen Repository-Anweisungen widersteht oder das Preisgeben sensiblen Kontexts vermeidet.
Google hat Argons anfängliche Verfügbarkeit eingeschränkt, während schrittweise Sicherheitsarbeit durchgeführt wird. Dieser Rollout bedeutet, dass die öffentliche Nutzungsevidenz dünner bleiben kann, als die Benchmark-Aufmerksamkeit vermuten lässt.
Auch Herstellerangaben erfordern sorgfältige Attribution. Anthropic, OpenAI und Google heben jeweils vorteilhafte Evaluationsergebnisse aus unterschiedlichen Suites und Einstellungen hervor.
Diese Ergebnisse können korrekt sein, ohne direkt vergleichbar zu sein. Unterschiedliche Harnesses, Aufgabensätze, Budgets und Bewertungsregeln führen oft zu unterschiedlichen Spitzenreitern.
Der Artificial Analysis Benchmark verbessert die Vergleichbarkeit, indem er Konfigurationen in einem Framework ausführt. Er kann jedoch nicht jede durch proprietäre Agenten und Modellschnittstellen eingeführte Differenz beseitigen.
Engineering-Verantwortliche sollten vor einer Standardisierung einen kleinen internen Test reproduzieren. Ein nützlicher Testsatz umfasst abgeschlossene Tickets, bekannte Fehlerfälle und repräsentative Repository-Einschränkungen.
Reviewer sollten Korrektheit, unnötige Änderungen, Sicherheit, Testabdeckung, Erklärungsqualität und Zeit bis zur Akzeptanz bewerten. Die Token-Ausgaben sollten neben diesen Ergebnissen erfasst werden.
Die daraus entstehende Kennzahl sollte akzeptierte Arbeit pro Dollar oder akzeptierte Arbeit pro Engineering-Stunde sein. Ein öffentlicher Gesamtscore kann die Kandidatenauswahl lenken, aber diese Messung nicht ersetzen.
Drei Signale werden entscheiden, ob Claudes Vorsprung relevant ist
Die nächste Phase wird durch Leistung bei Standardeinstellungen, die Wirtschaftlichkeit akzeptierter Änderungen und die Benchmark-Stabilität über Updates hinweg entschieden.
Das erste Signal ist die Leistung bei praxisnahen Aufwandseinstellungen. Maximalkonfigurationen erzeugen Schlagzeilen, doch Standardeinstellungen prägen den Großteil der täglichen Nutzung.
Sonnet 5.5 mit mittlerem Aufwand erzielt deutlich weniger Punkte als sein maximales Ergebnis. Sol verliert in den veröffentlichten Daten beim Wechsel von xhigh auf medium nur zwei Punkte.
Wenn Anthropic diese Lücke bei den Standardeinstellungen schließt, wird Claudes Obergrenze von 68 Punkten für gewöhnliche Teams relevanter. Bleibt die Lücke bestehen, wird Sols Effizienzargument stärker.
Das zweite Signal sind die Kosten pro akzeptierter Änderung. Öffentliche Benchmarks messen derzeit API-Ausgaben pro Aufgabe, nicht den vollständigen Weg von der Anfrage bis zum gemergten Code.
Teams sollten beobachten, ob Anbieter oder unabhängige Evaluatoren Ergebnisse veröffentlichen, die den Review-Aufwand berücksichtigen. Dazu sollten erneute Durchläufe, menschliche Korrekturzeit und nach der Verifizierung entdeckte Regressionen gehören.
Claudes Premium lässt sich leichter rechtfertigen, wenn seine Patches weniger Review erfordern. Sols Vorteil wird stärker, wenn sein geringerer Inferenzverbrauch keine zusätzliche Korrekturarbeit verursacht.
Argon könnte bei komplexen Repository-Änderungen diese Kennzahl anführen, wenn seine DeepSWE-Stärke auf die Produktion übertragbar ist. Sein Gesamtscore allein kann diese Frage nicht beantworten.
Das dritte Signal ist die Stabilität der Rangfolge. Coding-Agenten verändern sich durch Modellupdates, Harness-Revisionen, Tool-Richtlinien und Verbesserungen im Kontextmanagement.
Ein stabiler Spitzenreiter sollte seine Position über wiederholte Läufe und Benchmark-Versionen hinweg halten. Große Veränderungen nach kleinen Systemupdates würden das Vertrauen in geringe Punktunterschiede senken.
Artificial Analysis veröffentlicht bereits Komponentenergebnisse, Effizienzmetriken und Methodik-Revisionen. Künftige Wiederholungen werden zeigen, ob der Abstand von fünf Punkten eine dauerhafte Trennung oder vorübergehende Konfigurationseffekte darstellt.
Entwicklungsteams müssen nicht auf einen perfekten Benchmark warten. Sie können schon jetzt eine fundierte Entscheidung innerhalb klarer Grenzen treffen.
Beginnen Sie mit einem repräsentativen internen Aufgabenpaket. Vergleichen Sie Claude auf mehr als einer Aufwandsstufe mit Sol und Argon, sofern der Zugriff dies erlaubt.
Halten Sie Agentenberechtigungen, Repository-Snapshot und Erfolgskriterien konsistent. Erfassen Sie Laufzeit, Tokens, Fehler, Review-Zeit und ob die abschließende Änderung akzeptiert wurde.
Nutzen Sie eine Konfiguration mit hohem Aufwand nur, wenn die Aufgabe eine Eskalation rechtfertigt. Routinearbeiten sollten mit der kostengünstigsten Einstellung beginnen, die die Akzeptanzschwelle des Teams erfüllt.
Wiederholen Sie den Vergleich nach größeren Modell- oder Harness-Updates. Der Artificial Analysis Coding Agent Index ist gerade deshalb nützlich, weil sich die Spitze des Feldes bewegt.
Vorerst ist seine Botschaft klar. Claude Sonnet 5.5 erreicht unter den drei neuen Konfigurationen den höchsten veröffentlichten Wert, doch es führt nicht bei jeder praktischen Definition von Platz eins.
GPT-6.1 Sol bietet ein überzeugendes Effizienzprofil, während Gemini 4 Argon das Trio bei langfristiger Repository-Arbeit anführt. Die richtige Wahl hängt davon ab, welches Ergebnis ein Team priorisiert.
Würde Ihre Organisation einen hohen Ressourcenaufschlag für fünf zusätzliche Indexpunkte zahlen oder mit Sol mehr Versuche und Verifizierung finanzieren? Prüfen Sie diese Frage anhand Ihrer eigenen gemergten Arbeit, bevor Sie eine Standardeinstellung wählen.
