A-CODE-LLM Bench: Agentischer Programmier-Benchmark

Wir haben die besten Large Language Models (LLMs) bei 10 Softwareentwicklungsaufgaben mit einem agentischen CLI-Tool getestet. Wir führten ~3.500 automatisierte Validierungsschritte pro Modell sowohl auf API- als auch auf UI-Ebene durch.

A-CODE-LLM Bench Ergebnisse

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

• Mid-Tier Sonnet schlägt das Flaggschiff Opus. Beide Sonnet-Versionen übertreffen jeden Opus, einschließlich Opus 4.8 (0.702). Die teuerste Stufe von Anthropic ist nicht ihr bester Coder.
• Die Spitze ist nicht mehr nur Anthropic: Grok 4.5 (0.732) schlägt jede Opus-Variante. Das neue Flaggschiff von OpenAI, GPT 5.6 Sol, erreicht das beste Ergebnis des Unternehmens (0.615), liegt aber immer noch 0.157 unter Sonnet 5, und seine Pro-Varianten mit höherem Rechenaufwand landen meist unter ihren eigenen Basisversionen (Sol Pro 0.543, Terra Pro 0.568; nur Luna Pro verbessert sich, 0.603 vs 0.579).
• Code-Spezialisten haben den Programmier-Benchmark nicht gewonnen. GPT 5.3 Codex, die code-optimierte Variante von OpenAI, erreicht 0.572, Mittelfeld und unterhalb des eigenen allgemeinen GPT 5.4 Mini von OpenAI (0.594). Moonshots Kimi K2.7 Code ist der stärkere Spezialist mit 0.611.
• Kimi K3, ein allgemeines Modell, übernimmt die Open-Weights-Führung vom eigenen Code-Spezialisten von Moonshot: 0.725, insgesamt sechster, 0.114 über K2.7 Code. Sein 0.632 Backend rangiert an fünfter Stelle, vor jedem Opus- und GPT-Alias.
• Inkling, das erste Modell von Thinking Machines, debütiert mit 0.575, Dritter unter den Open-Weight-Modellen. Sein 0.747 Frontend schlägt jeden GPT 5.6 Alias; das 0.501 Backend begrenzt seinen Rang.
• Kein Modell ist beim Backend zuverlässig: die Obergrenze liegt bei 0.701 (Sonnet 5), so dass selbst der Gewinner etwa ein Drittel der Geschäftslogik- und Vertragsprüfungen nicht besteht. Grok 4.5 kommt unter den Juli-Ergänzungen mit 0.663 am nächsten heran. Das Frontend ist unter den Spitzenreitern nahezu gelöst (0,79 bis 0,96), so dass das Backend das offene Problem darstellt und die Rangliste bestimmt. Claude Haiku 4.5 rendert gut (0.731), aber ein 0.277 Backend hält es bei 0.413.
• GPTs Schwachstelle ist das Frontend. GPT 5.4 und 5.5 erreichen im Backend Opus 4.8 (etwa 0,6), erzielen 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-Reihe.

Kosten- & Erfolgsvergleich

• Die Modelle mit Flaggschiff-Preisen bieten das schlechteste Preis-Leistungs-Verhältnis. Opus 4.7 ist das teuerste ($3,08/Zelle) und erreicht 0.610, unter Sonnet 4.6 für $1,33.
• Die Spitze verlangt einen hohen Aufpreis für wenig Gewinn: Sonnet 5 liegt 0.024 über Sonnet 4.6 bei 70 % höheren Kosten pro Zelle.
• Grok 4.5 ist das neue beste Preis-Leistungs-Verhältnis: 0.732, innerhalb von 0.040 des Gewinners, bei $0,46 pro Zelle, verglichen mit 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 Ergebnisse zwischen 0.543 und 0.615, wobei der günstigste Alias den teuersten übertrifft.
• Kimi K3 erreicht seinen sechsten Platz zu einem Mittelklasse-Preis: $1,47 pro Zelle, nahe Sonnet 4.6s $1,33, aber 0.007 höher in der Punktzahl und deutlich unter Sonnet 5s $2,23. Inkling kostet $1,64 pro Zelle zum Listenpreis für 0.575, über Sonnet 4.6 bei niedrigerer Punktzahl.

Aufgabenabschlusszeit & Erfolgsvergleich

• Das beste Ergebnis 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 nahezu das gleiche Ergebnis in einem Drittel der Zeit.
• Eine lange Laufzeit signalisiert normalerweise ein feststeckendes, kein gründliches Modell: die Schlusslichter, beide Qwen-Varianten, GLM 5.1 Basis und Deepseek V4 Pro, liefen jeweils über 1.700 Sekunden durch Überiteration für Ergebnisse unter 0,45.
• Grok 4.3 war schnell, weil es früh aufgab: 142 Sekunden und 18 Tool-Aufrufe für 0.431. Grok 4.5 behält die Geschwindigkeit bei und lässt das Aufgeben: etwa 9 Minuten pro Aufgabe, unter einem Drittel der Zeit von Sonnet 5, für 0.732.
• Kimi K3 sitzt in der gegenüberliegenden Ecke: Top-Ergebnis, schlechteste Geschwindigkeit. Es benötigt durchschnittlich etwa 55 Minuten pro Aufgabe, das langsamste im Feld und etwa doppelt so lange wie Sonnet 5, für einen sechsten Platz mit 0.725. Seine Genauigkeit ist real, aber es ist der unpraktischste Weg in die Spitzenklasse.

Tool-Aufrufe pro Aufgabe

• Die Anzahl der Tool-Aufrufe misst weder Fähigkeit noch vergleichbaren Aufwand. Sonnet 5 machte die meisten Aufrufe (125) und erzielte das beste Ergebnis; MiniMax M3 machte 108 für ein mittelmäßiges 0.583; Grok 4.5 erreichte 0.732 mit 40; die niedrigen 16 bis 36 von OpenAI kommen von apply_patch, das eine ganze Datei in einen Aufruf bündelt. Sol Pro und Terra Pro rufen ein Viertel bis ein Drittel weniger Tools auf als ihre Basisversionen und erzielen weniger: mehr Nachdenken, weniger Ausführung. Bewerten Sie Agenten 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 vollständigen Benchmarks oben bestanden. Um Kosten und Geschwindigkeit unter gleichen Bedingungen zu vergleichen, haben wir eine einfache Basisaufgabe ausgeführt, die jedes Modell bewältigen kann: vier CRUD-Endpunkte, einfache Validierung, keine Authentifizierung und keine Datenbank.

Kosten- & Codezeilen-Vergleich

• Einfache Aufgaben können Modelle nicht bewerten, daher führen Spielzeug-Evaluierungen in die Irre. Bei der Basisaufgabe, 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 langer, dateiübergreifender Arbeit.
• Die "schnell und leicht"-Klasse war hier die teuerste: Gemini 3.5 Flash Basis schrieb 131 Zeilen für die triviale Aufgabe, das Zwei- bis Dreifache des Feldes, was es zur teuersten Basis machte, entgegen seiner eigenen Positionierung.
• Sonnet 5s starke Iteration ist aufgabenbedingt, keine Gewohnheit: 9 Aufrufe und $0,09 hier gegenüber 125 Aufrufen im Benchmark.

Weitere Details finden Sie im Artikel LLM Pricing.

Abschlusszeit & Token-Nutzung

• Kostenvorhersagbarkeit 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 trivialer Arbeit langsam und teuer (MiniMax M3: 475 vs 1.684s).
• Ausgabelänge ist eine feste Modelleigenschaft, die fast um das 10-fache variiert für die gleiche 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. Agentische KI-Systeme ermöglichen es LLMs, denselben Zyklus zu durchlaufen. 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 keine einzelnen Dateien sind. Sie haben Backends mit Routen und Datenbankmodellen, Frontends mit Komponenten und API-Aufrufen, Konfigurationsdateien, Abhängigkeiten und Tests. Um diese zum Zusammenspiel zu bringen, sind iterative Tests und Verfeinerungen erforderlich, genau das, was agentische Architektur ermöglicht.

Wie es funktioniert

Das Modell sitzt in einem Harness mit Zugriff auf eine Shell, das Dateisystem und die Ausführungsergebnisse. Wenn es aufgefordert wird, eine Anwendung zu erstellen, schreibt es Dateien inkrementell. Nach jedem Schritt zeigt der Harness dem Modell, was passiert ist: Startete der Server, bestanden Tests, meldete der Linter Fehler? Basierend auf diesem Feedback entscheidet das Modell, was es als nächstes schreiben oder beheben soll.

Dies unterscheidet sich grundlegend von der Single-Shot-Generierung. In One-Shot-Setups 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 immer noch starke Argumentationsfähigkeiten, um Geschäftslogik korrekt zu implementieren, und genau 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 Agenten-Harness für alle Modelle und verbanden sie über OpenRouter, mit zwei Ausnahmen: Claude Fable 5 lief auf der Claude Code CLI mit dem Claude-Abonnement, und Inkling lief über Thinking Machines' eigene OpenAI-kompatible API, 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 zu arbeiten (T-1 bis T-10), von Reservierungssystemen bis hin zu interaktiven Dashboards. Diese Aufgaben erfordern von Agenten die Verwaltung von Multi-File-Projekten und die Lieferung funktionaler Produkte. 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 Launch-Zahlen für Sol verwenden Modi mit höherem Rechenaufwand.¹ Vier Sol Pro-Zellen und eine Terra Pro-Zelle endeten in wiederholten stillen API-Stream-Fehlern und nicht in Modellfehlern und werden als Fehlschläge gewertet.

Kimi K3 und Inkling wurden am 18. Juli mit API-Standardeinstellungen hinzugefügt; Inkling lief mit seinem standardmäßigen Denkaufwand von 0,9. Inklings Kostenspalte verwendet die Listenpreise von Thinking Machines von $3,74 pro Million Input-Tokens und $9,36 pro Million Output-Tokens; der Anbieter berechnete etwa die Hälfte davon im Rahmen eines zeitlich begrenzten Einführungsrabatts.² Beide Modelle liefen mit einem 150-Minuten-Limit pro Zelle anstelle der früheren 45 Minuten, da Kimi K3s Token-Stream langsam genug ist, um das kürzere Limit mitten im Build zu erreichen; die Abschlusszeit wird separat im Zeitdiagramm ausgewiesen. Kimi K3s gemeinsam genutzte Upstream-Kapazität lieferte während des Ausführungsfensters häufige Rate-Limit- und Timeout-Fehler; betroffene Zellen wurden einmal gegen dasselbe Limit wiederholt, dieselbe Richtlinie wie bei den oben genannten Sol Pro- und Terra Pro-Stream-Fehlern.

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 Echtzeit-Token-Nutzung über Eingabe-, Ausgabe- und zwischengespeicherte Kategorien hinweg.

Backend-Validierung: Wir deployen die generierten Projekte in isolierten Umgebungen, 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 Backend-Gesamtpunktzahl 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, da 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 verifizieren funktionale Schritte wie Login-Übermittlung und Post-Login-Verhalten, 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 (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 vom Verhaltensnenner ausgeschlossen, so dass eine Zelle nicht doppelt bestraft wird, wenn die App nicht geladen werden kann.

Token-Berechnung

Token-Anzahlen werden aus der LLM-API-Antwort extrahiert. Wir subtrahieren zwischengespeicherte Input-Tokens von den gesamten Input-Tokens, um den effektiven Input zu erhalten, der nur neu verarbeitete Tokens widerspiegelt. Output-Tokens werden nie zwischengespeichert, bleiben also unverändert.

Endgültige Aggregation

Die endgültige Benchmark-Punktzahl wird durch Kombination der Ergebnisse aus den vorherigen Phasen berechnet: 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 zunichte machen.

Aufgabenbeispiel

Aufgabe 6: Helpdesk-Ticket-System

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 und gleichzeitig Geschäftsregeln und Sicherheitsgrenzen strikt durchsetzt. Diese Aufgabe bewertet die Fähigkeit eines Agenten, Multi-User-Zustandsautomaten, Datenisolation und thread-basierte Kommunikation in einer Full-Stack-Umgebung zu handhaben.

Die Aufgabe erforderte den Aufbau eines Helpdesk-Systems mit:

• Unterschiedlichen Berechtigungen für Kunden (Erstellen/Antworten) und Agenten (Verwaltung/Lösung).
• Einem strikten Status-Workflow, der illegale Übergänge verhindert und rollenspezifische Aktionen durchsetzt.
• Fortgeschrittener Datenisolation, bei der nicht autorisierte Ressourcenanfragen 404 statt 403 zurückgeben, um die Systemintegrität zu schützen.
• Einem chronologischen Antwortsystem für nahtlose Agent-Kunden-Interaktion.
• Einem FastAPI-Backend kombiniert mit einem responsiven, Vite-betriebenen Frontend (React/Vue/Svelte).
• Reproduzierbarem Setup ü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 Programmier-Benchmark}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Abgerufen am 12. August 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 befasst sich mit agentischen KI-Systemen und Language Models.

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 60% der Fortune 500.

Cems Arbeit wurde von führenden globalen Publikationen zitiert, darunter Business Insider, Forbes, Washington Post, globalen Unternehmen wie Deloitte, HPE und NGOs wie dem World Economic Forum sowie supranationalen Organisationen wie der European Commission.

Während seiner Karriere war Cem als Tech-Berater, Tech-Einkäufer und Tech-Unternehmer tätig. Er beriet Unternehmen über ein Jahrzehnt lang bei McKinsey & Company und Altman Solon in Technologieentscheidungen. Er veröffentlichte auch einen McKinsey-Bericht zur Digitalisierung.

Er leitete die Technologiestrategie und Beschaffung eines Telekommunikationsunternehmens und berichtete dabei direkt an den CEO. Zudem führte er das kommerzielle Wachstum des Deep-Tech-Unternehmens Hypatos an, das innerhalb von 2 Jahren von null auf einen siebenstelligen jährlich wiederkehrenden Umsatz und eine neunstellige Bewertung anwuchs. Cems Arbeit bei Hypatos wurde von führenden Technologiepublikationen wie TechCrunch und Business Insider aufgegriffen.

Cem spricht regelmäßig auf internationalen Technologiekonferenzen. Er schloss sein Studium an der Bogazici University als Computer-Ingenieur ab und hat einen MBA von 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