A-CODE-LLM Bench: Agentischer Coding-Benchmark

Wir haben die führenden Large Language Models (LLMs) über 10 Softwareentwicklungsaufgaben hinweg mit einem agentischen CLI-Tool benchmarkt. Wir führten pro Modell ~3.500 automatisierte Validierungsschritte in sowohl der API- als auch der UI-Ebene durch.

A-CODE-LLM Bench-Ergebnisse

Jeder Alias wurde 3 Mal über 10 Aufgaben hinweg ausgeführt (30 Proben pro Alias, 400 Zellen pro Iteration über 40 Aliase). Weitere Details finden Sie unter Methodik.

• Sonnet der Mittelklasse schlägt das Flaggschiff Opus. Beide Sonnet-Versionen übertreffen jedes Opus-Modell, einschließlich Opus 4.8 (0.702). Anthropics teuerste Stufe ist nicht der beste Coder.
• Die Spitze ist nicht länger Anthropic-exklusiv: Grok 4.5 (0.732) schlägt jede Opus-Variante. OpenAIs neues Flaggschiff GPT 5.6 Sol erzielt die beste Punktzahl des Unternehmens (0.615), liegt jedoch 0.157 unter Sonnet 5, und die stärkeren Pro-Varianten mit höherer Rechenleistung landen meist unter ihren eigenen Basisvarianten (Sol Pro 0.543, Terra Pro 0.568; nur Luna Pro verbessert sich, 0.603 vs. 0.579).
• Code-Spezialisten haben den Coding-Benchmark nicht gewonnen. GPT 5.3 Codex, OpenAIs code-optimierte Variante, erzielt 0.572, im Mittelfeld und unter OpenAIs eigenem allgemeinem GPT 5.4 Mini (0.594). Moonshots Kimi K2.7 Code ist der stärkere Spezialist mit 0.611.
• Kimi K3, ein allgemeines Modell, übernimmt die Führung bei Open-Weights gegenüber Moonshots eigenem Code-Spezialisten: 0.725, insgesamt Platz sechs, 0.114 über K2.7 Code. Sein Backend-Ergebnis von 0.632 rangiert auf Platz fünf, über jedem Opus- und GPT-Alias.
• Inkling, das erste Modell von Thinking Machines, debütiert mit 0.575, Platz drei unter den Open-Weights-Einträgen. Sein Frontend-Ergebnis von 0.747 schlägt jeden GPT-5.6-Alias; das Backend-Ergebnis von 0.501 begrenzt seinen Rang.
• Kein Modell ist zuverlässig im Backend: die Obergrenze liegt bei 0.701 (Sonnet 5), daher scheitert selbst der Gewinner bei etwa einem Drittel der Geschäftslogik- und Vertragsprüfungen. Grok 4.5 kommt dem am nächsten unter den Juli-Ergänzungen mit 0.663. Das Frontend ist bei den Führenden nahezu gelöst (0.79 bis 0.96), daher ist das Backend das offene Problem, und es bestimmt die Rangfolge. Claude Haiku 4.5 rendert gut (0.731), aber ein Backend von 0.277 hält es auf 0.413.
• Die Schwachstelle von GPT ist das Frontend. GPT 5.4 und 5.5 erreichen im Backend das Niveau von Opus 4.8 (etwa 0.6), erzielen aber im Frontend 0.53 bis 0.55; die GPT-5.6-Familie hebt das auf 0.63 bis 0.71 an, immer noch weit unter den über 0.91 der Sonnet-Reihe.

Kosten- und Erfolgsvergleich

• Die Flaggschiff-Modelle bieten das schlechteste Preis-Leistungs-Verhältnis. Opus 4.7 ist das teuerste ($3,08/Zelle) und erzielt 0.610, unter Sonnet 4.6 zu $1,33.
• Die Spitze verlangt einen hohen Aufpreis für wenig Zugewinn: Sonnet 5 schneidet 0.024 besser ab als Sonnet 4.6 bei 70% höheren Kosten pro Zelle.
• Grok 4.5 bietet das neue beste Preis-Leistungs-Verhältnis: 0.732, innerhalb von 0.040 des Gewinners, zu $0.46 pro Zelle, im Vergleich zu Sonnet 5s $2.23. Innerhalb der GPT-5.6-Familie bringt der Preis nichts: $0.18 (Luna) bis $2.76 (Sol Pro) pro Zelle für Werte zwischen 0.543 und 0.615, wobei der günstigste Alias den teuersten übertrifft.
• Kimi K3 erzielt seinen sechsten Platz zu einem Mittelklasse-Preis: $1,47 pro Zelle, nahe an Sonnet 4.6s $1,33, aber 0.007 besser in der Punktzahl, und deutlich unter Sonnet 5s $2,23. Inkling kostet zum Listenpreis $1,64 pro Zelle für 0.575, über Sonnet 4.6 für eine niedrigere Punktzahl.

Vergleich von Bearbeitungszeit und Erfolg

• Das beste Ergebnis gehört zu den langsamsten. Sonnet 5 benötigt etwa 30 Minuten pro Aufgabe, das 3x von Sonnet 4.6 für 0.024 mehr; Sonnet 4.6 liefert nahezu das gleiche Ergebnis in einem Drittel der Zeit.
• Eine lange Laufzeit signalisiert meist ein feststeckendes Modell, nicht ein gründliches: die Schlusslichter, beide Qwen-Varianten, GLM 5.1 Base und Deepseek V4 Pro, liefen jeweils über 1.700 Sekunden aufgrund von Über-Iteration für Punktzahlen unter 0.45.
• Grok 4.3 war schnell, weil es früh abbrach: 142 Sekunden und 18 Tool-Aufrufe für 0.431. Grok 4.5 behält die Geschwindigkeit und vermeidet das Abbrechen: etwa 9 Minuten pro Aufgabe, unter einem Drittel der Zeit von Sonnet 5, für 0.732.
• Kimi K3 sitzt im entgegengesetzten Eck: Spitzenergebnis, schlechteste Geschwindigkeit. Es benötigt durchschnittlich etwa 55 Minuten pro Aufgabe, das langsamste im Feld und ungefähr das Doppelte von Sonnet 5, für einen sechsten Platz mit 0.725. Seine Genauigkeit ist real, aber es ist der am wenigsten praktische Weg in die Spitzenklasse.

Tool-Aufrufe pro Aufgabe

• Die Anzahl der Tool-Aufrufe misst weder vergleichbare Fähigkeiten noch vergleichbaren Aufwand. Sonnet 5 machte die meisten Aufrufe (125) und erzielte die höchste Punktzahl; MiniMax M3 machte 108 für einen mittelmäßigen 0.583; Grok 4.5 erreichte 0.732 bei 40; OpenAIs niedrige Werte von 16 bis 36 resultieren aus apply_patch, das eine ganze Datei in einem Aufruf bündelt. Sol Pro und Terra Pro rufen ein Viertel bis ein Drittel weniger Tools auf als ihre Basisvarianten und schneiden schlechter ab: mehr Reasoning, weniger Ausführung. Bewerten Sie Agents nicht nach Tool-Volumen.
• Zwei Wege führen zur gleichen Punktzahl: Sonnet 5 iteriert stark (125 Aufrufe), Sonnet 4.6 kaum (etwa 50), 0.024 auseinander.

LLM-Leistung bei einer einzelnen erfolgreichen Aufgabe

Kein Modell hat jeden Schritt des gesamten obigen Benchmarks bestanden. Um Kosten und Geschwindigkeit unter gleichen Bedingungen zu vergleichen, haben wir eine einfache Basisaufgabe ausgeführt, die jedes Modell lösen kann: vier CRUD-Endpunkte, einfache Validierung, keine Authentifizierung und keine Datenbank.

Vergleich von Kosten und Codezeilen

• Einfache Aufgaben können Modelle nicht einordnen, daher führen Spielzeug-Bewertungen in die Irre. Bei der Basisaufgabe, die jedes Modell besteht, konvergiert der Code auf 40 bis 64 Zeilen und die Kosten sinken auf Cent-Beträge; Unterschiede zeigen sich nur bei umfangreichen, dateiübergreifenden Arbeiten.
• Die „schnell und leicht“-Kategorie war hier die teuerste: Die Gemini 3.5 Flash Basis schrieb 131 Zeilen für die triviale Aufgabe, das Zwei- bis Dreifache des Feldes, und war damit die teuerste Basisvariante, entgegen ihrer eigenen Positionierung.
• Sonnet 5s starke Iteration ist aufgabengetrieben, keine Gewohnheit: 9 Aufrufe und $0,09 hier, gegenüber 125 Aufrufen im Benchmark.

Weitere Details finden Sie im Artikel LLM Pricing.

Bearbeitungszeit & Token-Nutzung

• Die Vorhersagbarkeit der Kosten teilt Modelle in zwei Gruppen. Adaptive Modelle geben nur bei Bedarf aus (Opus 4.8: 34s Basis, 1.072s Benchmark); Modelle mit festem Tempo laufen selbst bei trivialen Aufgaben langsam und teuer (MiniMax M3: 475 vs. 1.684s).
• Die Ausgabelänge ist eine feste Modelleigenschaft mit einer Spanne von fast dem 10fachen für dieselbe Aufgabe (787 bis 7.508 Tokens), was sich direkt auf die Kosten auswirkt.

Was sind agentische LLM-Systeme?

Softwareentwicklung ist iterativ: Code schreiben, ausführen, Fehler lesen, beheben, wiederholen. Agentic AI-Systeme ermöglichen es LLMs, diesem gleichen Zyklus zu folgen. Das Modell arbeitet in einer Entwicklungsumgebung, in der es Dateien schreiben, Befehle ausführen, Ausgaben lesen und basierend auf dem Gesehenen Änderungen vornehmen kann, bis die Aufgabe abgeschlossen ist.

Das ist wichtig, weil echte Anwendungen nicht aus einzelnen Dateien bestehen. Sie haben Backends mit Routen und Datenbankmodellen, Frontends mit Komponenten und API-Aufrufen, Konfigurationsdateien, Abhängigkeiten und Tests. Diese zum Zusammenwirken zu bringen, erfordert iteratives Testen und Verfeinern, genau das, was die agentische Architektur ermöglicht.

So funktioniert es

Das Modell befindet sich in einem Rahmen mit Zugriff auf eine Shell, das Dateisystem und die Ausführungsergebnisse. Beim Bau einer Anwendung schreibt es Dateien inkrementell. Nach jedem Schritt zeigt der Rahmen dem Modell, was passiert ist: Hat der Server gestartet? Haben die Tests bestanden? Hat der Linter Fehler gemeldet? Basierend auf diesem Feedback entscheidet das Modell, was als Nächstes zu schreiben oder zu beheben ist.

Das unterscheidet sich grundlegend von der Ein-Schuss-Generierung. In Ein-Schuss-Konfigurationen generiert das Modell eine gesamte Codebasis blind, ohne Möglichkeit zu überprüfen, ob sie funktioniert. In agentischen LLM-Systemen sieht das Modell die Konsequenzen jeder Aktion und korrigiert den Kurs. Diese Fähigkeit allein reicht jedoch nicht aus. Das Modell benötigt weiterhin starke Argumentationsfähigkeiten, um die Geschäftslogik korrekt zu implementieren, und hier zeigen sich die Leistungsunterschiede wirklich.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Methodik des agentischen LLM-Benchmarks

Wir verwendeten Opencode als Agentenrahmen für alle Modelle und verbanden sie über OpenRouter, mit zwei Ausnahmen: Claude Fable 5 lief auf der Claude Code CLI im Rahmen des Claude-Abonnements, und Inkling lief über die OpenAI-kompatible API von Thinking Machines, da das Modell nicht auf OpenRouter verfügbar ist. Jede Zelle wurde 3 Mal ausgeführt, um die Varianz pro Zelle zu messen und die Rangliste zu stabilisieren. Wir bewerteten ihre Fähigkeit, autonom an 10 Softwareentwicklungsaufgaben (T-1 bis T-10) zu arbeiten, die von Reservierungssystemen bis zu interaktiven Dashboards reichen. Diese Aufgaben erfordern, dass Agenten Mehrdateienprojekte verwalten und funktionale Produkte liefern. Die sieben im Juli 2026 hinzugefügten Aliase (Grok 4.5 und die GPT-5.6-Familie: Sol, Terra, Luna, jeweils im Basis- und Pro-Modus) liefen auf Opencode 1.15.13 mit API-Standardeinstellungen, genau wie jedes Modell hier; OpenAIs Einführungszahlen für Sol verwenden höher rechenintensive Modi.¹ Vier Sol Pro-Zellen und eine Terra Pro-Zelle endeten in wiederholten stillen API-Stream-Ausfällen, nicht aufgrund von Modellfehlern, und werden als Fehlversuche gewertet.

Kimi K3 und Inkling wurden am 18. Juli mit API-Standardeinstellungen hinzugefügt; Inkling lief mit seiner standardmäßigen Denkanstrengung von 0.9. Inklings Kostenspalte verwendet die Listenpreise von Thinking Machines von $3,74 pro Million Eingabe-Token und $9,36 pro Million Ausgabe-Token; der Anbieter berechnete etwa die Hälfte davon unter einem zeitlich begrenzten Einführungsrabatt.² Beide Modelle liefen mit einer 150-Minuten-Zellenwand anstelle der früheren 45 Minuten, weil der Token-Stream von Kimi K3 so langsam ist, dass er mitten im Build die kürzere Wand erreichen würde; die Abschlusszeit wird separat im Zeitdiagramm ausgewiesen. Die gemeinsam genutzte Upstream-Kapazität von Kimi K3 lieferte während des Ausführungsfensters häufige Rate-Limit- und Timeout-Fehler; betroffene Zellen wurden einmal gegen dieselbe Wand erneut ausgeführt, dieselbe Richtlinie wie für die oben genannten Stream-Ausfälle von Sol Pro und Terra Pro.

Ausführung und Orchestrierung

Jeder Agent und jede Aufgabe beginnt in einer sauberen Umgebung. Die Anweisungen werden als TASK.md-Datei bereitgestellt, und wir verwenden einen 20-Minuten-Heartbeat-Watchdog für die Startskripte. Während dieser Phase zeichnen wir Exit-Codes, Ausführungszeit und ob die Backend- und Frontend-Dateien erstellt wurden auf. Wir verfolgen auch die Token-Nutzung in Echtzeit über Eingabe-, Ausgabe- und zwischengespeicherte Kategorien.

Backend-Validierung: Wir setzen die generierten Projekte in isolierten Umgebungen ein, um sie gegen einen kanonischen YAML-Vertrag zu testen. Die Validierung umfasst Happy-Path-Szenarien, Fehlerbehandlung (400/403/409) und Datenkonsistenz.

Wir testen die Ergebnisse in zwei Modi:

Der adaptive Modus validiert die Funktionalität auch bei abweichenden Routennamen, während der strenge Modus die genaue Einhaltung des Vertrags erfordert.

Die Gesamtpunktzahl des Backends wird pro Zelle wie folgt berechnet:

backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)

wobei has_backend 1 ist, wenn die Zelle ein Backend-Projekt erzeugt hat, andernfalls 0. Adaptiv wird höher gewichtet, weil es die Verhaltenskorrektheit misst; der strenge Modus fügt eine Strafe für Vertragsabweichungen hinzu (umbenannte Routen, ersetzte Statuscodes, umstrukturierte Antwortfelder).

UI- und Benutzerszenario-Tests

Wir verwenden Browser-Automatisierung, um reale Benutzerabläufe zu simulieren, einschließlich Preflights, Rendering und Authentifizierung. Wir überprüfen funktionale Schritte wie Login-Übermittlung und Verhalten nach dem Login, um sicherzustellen, dass die Anwendung ohne Absturz läuft.

Die UI-Bewertung teilt acht Schritte in zwei Gruppen auf. Infrastrukturschritte (Backend-Preflight, Frontend-Rendering, Login-Formular sichtbar, Login-Übermittlung, Login 2xx, kein Laufzeitabsturz) messen, ob die App überhaupt läuft. Verhaltensschritte (Post-Login-Auth-Signal, Post-Login-Verhaltenssignal) bewerten, ob die App ihre beabsichtigte Funktion ausführt, sobald sie läuft.

ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)

Blockierte Verhaltensschritte werden aus dem Verhaltensnenner ausgeschlossen, so dass eine Zelle nicht doppelt bestraft wird, wenn die App nicht geladen werden kann.

Token-Berechnung

Die Token-Anzahlen werden aus der LLM-API-Antwort extrahiert. Wir ziehen die zwischengespeicherten Eingabe-Token von den Gesamteingabe-Token ab, um die effektive Eingabe zu erhalten, die nur neu verarbeitete Token widerspiegelt. Ausgabe-Token werden nie zwischengespeichert, so dass sie unverändert bleiben.

Endgültige Aggregation

Die endgültige Benchmark-Punktzahl wird durch Kombination der Ergebnisse der vorherigen Phasen berechnet: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Wir weisen dem Backend ein höheres Gewicht zu, weil Logikfehler auf API-Ebene oft jeglichen Erfolg im Frontend zunichte machen.

Aufgabenbeispiel

Aufgabe 6: Helpdesk-Ticketsystem

Aufgabe 6 konzentriert sich auf die Entwicklung eines komplexen Kundensupport-Ökosystems. Das Hauptziel ist der Aufbau einer Plattform, die Kommunikation zwischen Kunden und Support-Mitarbeitern vermittelt, während Geschäftsregeln und Sicherheitsgrenzen strikt durchgesetzt werden. Diese Aufgabe bewertet die Fähigkeit eines Agenten, Multi-User-Zustandsautomaten, Datenisolation und Thread-Kommunikation in einer Full-Stack-Umgebung zu handhaben.

Die Aufgabe erforderte den Aufbau eines Helpdesk-Systems mit folgenden Merkmalen:

• Getrennte Berechtigungen für Kunden (Erstellen/Antworten) und Agenten (Verwaltung/Abwicklung).
• Ein strikter Status-Workflow, der illegale Übergänge verhindert und rollenspezifische Aktionen erzwingt.
• Erweiterte Datenisolation, bei der nicht autorisierte Ressourcenanfragen 404 anstelle von 403 zurückgeben, um die Systemintegrität zu schützen.
• Ein chronologisches Antwort-System für nahtlose Agenten-Kunden-Interaktion.
• Ein FastAPI-Backend kombiniert mit einem responsiven Vite-betriebenen Frontend (React/Vue/Svelte).
• Reproduzierbare Einrichtung über spezifische Shell-Befehle zur sofortigen Systemaktivierung.

Sie können die Dokumentation zu Aufgabe 6 auf GitHub einsehen.

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{kalelioglu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-LLM Bench: Agentischer Coding-Benchmark}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Abgerufen am 23. Juli 2026}
}

Referenzlinks

1.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

2.

Inkling: Our Open-Weights Model - Thinking Machines Lab

Berk Kalelioğlu

KI-Forscher

Folgen auf

Berk ist KI-Forscher bei AIMultiple und konzentriert sich auf agentenbasierte KI-Systeme und Sprachmodelle.

Vollständiges Profil anzeigen

Technisch geprüft von

Cem Dilmegani

Leitender Analyst

Folgen auf

Cem ist seit 2017 leitender Analyst bei AIMultiple. AIMultiple informiert monatlich Hunderttausende von Unternehmen (laut similarWeb), darunter 55 % der Fortune 500. Cems Arbeit wurde von führenden globalen Publikationen wie Business Insider, Forbes und der Washington Post, von globalen Unternehmen wie Deloitte und HPE sowie von NGOs wie dem Weltwirtschaftsforum und supranationalen Organisationen wie der Europäischen Kommission zitiert. Weitere namhafte Unternehmen und Ressourcen, die AIMultiple referenziert haben, finden Sie hier. Im Laufe seiner Karriere war Cem als Technologieberater, Technologieeinkäufer und Technologieunternehmer tätig. Über ein Jahrzehnt lang beriet er Unternehmen bei McKinsey & Company und Altman Solon in ihren Technologieentscheidungen. Er veröffentlichte außerdem einen McKinsey-Bericht zur Digitalisierung. Bei einem Telekommunikationsunternehmen leitete er die Technologiestrategie und -beschaffung und berichtete direkt an den CEO. Darüber hinaus verantwortete er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos, das innerhalb von zwei Jahren von null auf einen siebenstelligen jährlichen wiederkehrenden Umsatz und eine neunstellige Unternehmensbewertung kam. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider gewürdigt. Er ist ein gefragter Redner auf internationalen Technologiekonferenzen. Cem absolvierte sein Studium der Informatik an der Bogazici-Universität und besitzt einen MBA der Columbia Business School.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten