A-CODE-LLM Bench: Agentischer Codierungs-Benchmark
Wir haben die besten Large Language Models (LLMs) in 10 Softwareentwicklungsaufgaben mit einem agentischen CLI-Tool verglichen. Wir führten ~3.500 automatisierte Validierungsschritte pro Modell über API- und UI-Ebenen durch.
A-CODE-LLM Bench Ergebnisse
Jeder Alias wurde 3-mal in 10 Aufgaben ausgeführt (30 Stichproben pro Alias, 380 Zellen pro Iteration über 38 Aliase). Weitere Details zur Methodik.
- Mittelklasse-Sonnet schlägt das Flaggschiff Opus. Beide Sonnet-Versionen übertreffen jeden Opus, inklusive Opus 4.8 (0.702). Anthropics teuerste Stufe ist nicht ihr bester Coder.
- Die Spitze ist nicht mehr nur Anthropic: 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), noch 0.157 unter Sonnet 5, und seine rechenintensiveren Pro-Varianten liegen meist unter ihren eigenen Basen (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-abgestimmte Variante, erzielt 0.572, im Mittelfeld und unter OpenAIs eigenem allgemeinen GPT 5.4 Mini (0.594). Moonshots Kimi K2.7 Code ist der stärkere Spezialist mit 0.611.
- Kein Modell ist im Backend zuverlässig: die Obergrenze liegt bei 0.701 (Sonnet 5), also scheitert selbst der Gewinner bei etwa einem Drittel der Geschäftslogik- und Vertragsprüfungen. Grok 4.5 kommt unter den Juli-Neuzugängen mit 0.663 am nächsten. Das Frontend ist bei den Führenden nahezu gelöst (0.79 bis 0.96), also ist das Backend das offene Problem und bestimmt die Rangfolge. Claude Haiku 4.5 rendert gut (0.731), aber ein Backend von 0.277 hält es bei 0.413.
- GPTs Schwachstelle ist das Frontend. GPT 5.4 und 5.5 entsprechen Opus 4.8 im Backend (etwa 0.6), erreichen aber 0.53 bis 0.55 im Frontend; die GPT 5.6-Familie hebt das auf 0.63 bis 0.71 an, immer noch weit unter den 0.91 plus der Sonnet-Linie.
Kosten & Erfolgsvergleich
- Die zu Flaggschiff-Preisen angebotenen Modelle bieten das schlechteste Preis-Leistungs-Verhältnis. Opus 4.7 ist das teuerste ($3,08/Zelle) und erreicht 0.610, unter Sonnet 4.6 bei $1,33.
- Der Spitzenreiter verlangt einen hohen Aufpreis für wenig Gewinn: Sonnet 5 erzielt 0.024 mehr als Sonnet 4.6 für 70 % höhere Kosten pro Zelle.
- Grok 4.5 ist das neue beste Preis-Leistungs-Verhältnis: 0.732, nur 0.040 vom Gewinner entfernt, bei $0,46 pro Zelle, verglichen mit Sonnet 5s $2,23. Innerhalb der GPT 5.6-Familie kauft der Preis nichts: $0,18 (Luna) bis $2,76 (Sol Pro) pro Zelle für Bewertungen zwischen 0.543 und 0.615, wobei der günstigste Alias den teuersten übertrifft.
Aufgabenabschlusszeit & Erfolgsvergleich
- Die höchste Punktzahl gehört zu den langsamsten. Sonnet 5 benötigt etwa 30 Minuten pro Aufgabe, das 3-fache von Sonnet 4.6 für 0.024 mehr; Sonnet 4.6 liefert fast die gleiche Punktzahl in einem Drittel der Zeit.
- Eine lange Laufzeit deutet meist auf ein festgefahrenes und nicht auf ein gründliches Modell hin: die schlechtesten, beide Qwen-Varianten, GLM 5.1 Basis und Deepseek V4 Pro, liefen jeweils über 1.700 Sekunden aufgrund von Überiteration für Bewertungen unter 0.45.
- Grok 4.3 war schnell, weil es früh aufgab: 142 Sekunden und 18 Werkzeugaufrufe für 0.431. Grok 4.5 behält die Geschwindigkeit und gibt das Aufgeben auf: etwa 9 Minuten pro Aufgabe, unter einem Drittel von Sonnet 5s Zeit, für 0.732.
Werkzeugaufrufe pro Aufgabe
- Die Anzahl der Werkzeugaufrufe misst weder Fähigkeit noch vergleichbaren Aufwand. Sonnet 5 machte die meisten Aufrufe (125) und erreichte die höchste Punktzahl; MiniMax M3 machte 108 für eine mittlere 0.583; Grok 4.5 erreichte 0.732 bei 40; OpenAIs niedrige 16 bis 36 stammen von apply_patch, das eine ganze Datei in einem Aufruf bündelt. Sol Pro und Terra Pro rufen ein Viertel bis ein Drittel weniger Werkzeuge auf als ihre Basen und erreichen weniger: mehr Überlegung, weniger Ausführung. Agenten sollten nicht nach Werkzeugvolumen eingestuft werden.
- Zwei Wege erreichen die gleiche 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 vollständigen Benchmarks oben bestanden. Um Kosten und Geschwindigkeit unter gleichen Bedingungen zu vergleichen, führten wir eine einfache Grundaufgabe aus, die jedes Modell bewältigen kann: vier CRUD-Endpunkte, grundlegende Validierung, keine Authentifizierung und keine Datenbank.
Kosten & Codezeilen-Vergleich
- Einfache Aufgaben können Modelle nicht einstufen, daher führen Spielzeugbewertungen in die Irre. Bei der Grundaufgabe, die jedes Modell besteht, konvergiert der Code auf 40 bis 64 Zeilen, und die Kosten fallen auf Cent-Beträge; Unterschiede zeigen sich nur bei langen, mehrdateibasierten Arbeiten.
- Die “schnell und leicht”-Stufe war hier die teuerste: Gemini 3.5 Flash Basis schrieb 131 Zeilen für die triviale Aufgabe, das Zwei- bis Dreifache des Feldes, und war damit die teuerste Grundlinie, 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.
Fertigstellungszeit & Token-Nutzung
- Die Kosten-Vorhersagbarkeit teilt Modelle in zwei Gruppen. Adaptive Modelle geben nur bei Bedarf aus (Opus 4.8: 34s Grundlinie, 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 ein festes Modellmerkmal, das für dieselbe Aufgabe fast um den Faktor 10 variiert (787 bis 7.508 Tokens), was direkt in die Kosten einfließt.
Was sind agentische LLM-Systeme?
Softwareentwicklung ist iterativ: Code schreiben, ausführen, Fehler lesen, beheben, wiederholen. Agentische KI-Systeme ermöglichen es LLMs, denselben Zyklus zu durchlaufen. Das Modell agiert in einer Entwicklungsumgebung, in der es Dateien schreiben, Befehle ausführen, Ausgaben lesen und basierend auf dem Gesehenen Änderungen vornehmen kann, bis die Aufgabe erledigt ist.
Das ist wichtig, weil echte Anwendungen keine einzelnen Dateien sind. Sie haben Backends mit Routen und Datenbankmodellen, Frontends mit Komponenten und API-Aufrufen, Konfigurationsdateien, Abhängigkeiten und Tests. Diese zusammen zum Laufen zu bringen, erfordert iteratives Testen und Verfeinern, genau das, was die agentische Architektur ermöglicht.
Wie es funktioniert
Das Modell befindet sich in einem Gerüst mit Zugriff auf eine Shell, das Dateisystem und die Ausführungsergebnisse. Wenn es eine Anwendung erstellen soll, schreibt es Dateien schrittweise. Nach jedem Schritt zeigt das Gerüst 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. Bei Ein-Schuss-Konfigurationen generiert das Modell blind eine gesamte Codebasis, ohne Möglichkeit zu prü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 immer noch starke logische Fähigkeiten, um die Geschäftslogik korrekt umzusetzen, und hier zeigen sich die Leistungsunterschiede wirklich.
Als bevorzugte Quelle hinzufügenMethodik des agentischen LLM-Benchmarks
Wir verwendeten Opencode als Agentengerüst für alle Modelle und verbanden sie über OpenRouter, mit einer Ausnahme: Claude Fable 5 lief auf der Claude Code CLI mit dem Claude-Abo. 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 reichten. Diese Aufgaben erfordern, dass die 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, genauso wie jedes Modell hier; OpenAIs Startwerte für Sol verwenden rechenintensivere Modi.1 Vier Sol Pro-Zellen und eine Terra Pro-Zelle endeten in wiederholten stillen API-Stream-Fehlern statt in Modellfehlern und werden als Fehlschläge gewertet.
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-minütigen 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 Echtzeit-Token-Nutzung über Eingabe-, Ausgabe- und zwischengespeicherte Kategorien hinweg.
Backend-Validierung: Wir stellen die generierten Projekte in isolierten Umgebungen bereit, 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 strikte Modus die exakte Einhaltung des Vertrags erfordert.
Die Gesamtpunktzahl für das Backend 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, sonst 0. Adaptiv wird höher gewichtet, weil es die Verhaltenskorrektheit misst; strikt fügt eine Strafe für Vertragsabweichungen hinzu (umbenannte Routen, ersetzte Statuscodes, umstrukturierte Antwortfelder).
UI- und Benutzerszenario-Tests
Wir verwenden Browser-Automatisierung, um echte Benutzerabläufe zu simulieren, einschließlich Preflights, Rendering und Authentifizierung. Wir überprüfen funktionale Schritte wie die Login-Übermittlung und das Verhalten nach dem Login, um sicherzustellen, dass die Anwendung ohne Absturz läuft.
Die UI-Bewertung teilt acht Schritte in zwei Gruppen. Infrastrukturschritte (Backend-Preflight, Frontend-Rendering, Login-Formular sichtbar, Login-Übermittlung, Login 2xx, kein Laufzeitabsturz) messen, ob die App überhaupt läuft. Verhaltensschritte (Auth-Signal nach dem Login, Verhaltenssignal nach dem Login) 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 vom Verhaltensnenner ausgeschlossen, sodass eine Zelle nicht doppelt bestraft wird, wenn die App nicht geladen werden kann.
Token-Berechnung
Token-Zahlen werden aus der LLM-API-Antwort extrahiert. Wir ziehen die zwischengespeicherten Eingabetoken von den gesamten Eingabetoken ab, um die effektive Eingabe zu erhalten, die nur neu verarbeitete Token widerspiegelt. Ausgabetoken werden nie zwischengespeichert, daher bleiben sie unverändert.
Endgültige Aggregation
Die endgültige Benchmark-Bewertung wird berechnet, indem die Ergebnisse der vorherigen Phasen kombiniert werden: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Wir weisen dem Backend eine höhere Gewichtung zu, da Logikfehler auf API-Ebene oft jeden Erfolg im Frontend zunichtemachen.
Aufgabenbeispiel
Aufgabe 6: Helpdesk-Ticketsystem
Aufgabe 6 konzentriert sich auf die Entwicklung eines komplexen Kundensupport-Ökosystems. Das Hauptziel ist der Aufbau einer Plattform, die die Kommunikation zwischen Kunden und Support-Mitarbeitern vermittelt und gleichzeitig Geschäftsregeln und Sicherheitsgrenzen strikt durchsetzt. Diese Aufgabe bewertet die Fähigkeit eines Agenten, Mehrbenutzer-Zustandsautomaten, Datenisolierung und Thread-basierte Kommunikation in einer Full-Stack-Umgebung zu handhaben.
Die Aufgabe erforderte den Aufbau eines Helpdesk-Systems mit folgenden Merkmalen:
- Unterschiedliche Berechtigungen für Kunden (Erstellen/Antworten) und Agenten (Verwaltung/Lösung).
- Ein starrer Status-Workflow, der unzulässige Übergänge verhindert und rollenspezifische Aktionen erzwingt.
- Fortschrittliche Datenisolierung, bei der nicht autorisierte Ressourcenanfragen 404 anstelle von 403 zurückgeben, um die Systemintegrität zu schützen.
- Ein chronologisches Antwortsystem für nahtlose Agenten-Kunden-Interaktion.
- Ein FastAPI-Backend in Kombination mit einem responsiven, von 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{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Agentischer Codierungs-Benchmark}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Abgerufen am 10. Juli 2026}
}Ergebnisse und Zeitstempel von 418 Datenpunkten. Laden Sie die in diesem Artikel verwendeten Daten als ZIP-Datei herunter, die 2 CSV-Dateien und eine README enthält.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.