Agentic LLM Benchmark: Die 13 besten LLM-Programme im Vergleich
Wir haben 13 LLMs anhand von 10 Softwareentwicklungsaufgaben mithilfe eines agentenbasierten CLI-Tools verglichen. Wir führten pro Modell ca. 300 automatisierte Validierungsschritte durch, um die Leistung sowohl auf API- als auch auf UI-Ebene zu messen.
Agentic LLM Benchmark-Ergebnisse
Vergleich der Erfolgsraten
Claude 4.5 Sonnet und GPT-5.2 erzielten die höchsten Gesamtpunktzahlen und lieferten die konsistentesten Ergebnisse sowohl in der API-Logik als auch in der UI-Integration. Gemini 3.1 Pro Preview und GPT-5.2 Codex folgten mit funktionaler Backend-Logik, aber schwächerer Frontend-Ausgabe.
Claude Sonnet 4.5
Das Modell Claude Sonnet 4.5 erzielte die höchste UI-Rate aller getesteten Modelle und lieferte durchweg funktionierende Frontends mit funktionaler Backend-Logik. Es implementierte erfolgreich CRUD-Operationen, Eingabevalidierung, Ressourcenerfassung, mehrstufige Workflows und mehrstufige Statuslebenszyklen. Allerdings war bei einigen Aufgaben die Authentifizierung zwar korrekt eingerichtet, es fehlten jedoch die Ressourcenerstellung, die Durchsetzung von Einschränkungen oder die rollenbasierte Zugriffskontrolle in domänenspezifischen Endpunkten.
Gemini 3.1 Pro Vorschau
Technisch präziser Backend-Code, aber fragile Infrastruktur. Die grundlegende Authentifizierung und die Auflistungsschritte wurden in einigen Aufgaben erfolgreich abgeschlossen, scheiterten jedoch im Allgemeinen an Folgendem:
- Frontend-Initialisierung
- Strenge Schema-Validierung
- Zeitbasierte Validierungsbeschränkungen
- Komplexe Zustandsübergänge
- Kaskadierende Ressourcenerstellung
GPT-5.2
Funktionale Backends und funktionierende Frontends kennzeichneten die meisten Aufgaben, die von GPT-5.2 bearbeitet wurden, mit starker Leistung bei CRUD-Operationen, Eingabevalidierung, rollenbasierter Zugriffskontrolle und mehrstufigen Arbeitsabläufen. Wo es Schwächen zeigte:
- Zustandsautomatenlogik: Authentifizierung und Ressourcenauflistung erstellt, aber Administratorstatusübergänge und irreversible Zustandsdurchsetzung übersprungen.
- Rollendurchsetzung oder eingeschränkte Ressourcenerstellung in einigen Aufgaben
GPT-5.2 Codex
Grundlegende Abläufe wie Registrierung, Ressourcenauflistung und Sammlungsverwaltung wurden vom Codex GPT-5.2 gut abgedeckt. Seine Hauptschwächen:
- Endpunkte für den Abruf fehlender Details
- Keine Administratorzustandsübergänge
- Die Hälfte der Frontends stürzte aufgrund von Laufzeitfehlern ab (5 von 10).
Im Vergleich zu GPT-5.2 erzeugte Codex zuverlässigere Backends, aber deutlich weniger stabile Frontends.
Beispielprotokoll:
Gemini 3 Pro
Bei einfacheren Aufgaben mit einer einzigen Rolle implementierte Gemini 3 Pro CRUD, Suche, rollenbasierte Zugriffskontrolle und Datenabfrage korrekt. Anwendungen mit mehreren Rollen stellten seine Schwäche dar:
- Die Systemprüfung und die Authentifizierung wurden bestanden, jedoch traten Fehler bei der Ressourcenerstellung, der Zuordnungsverwaltung, der Rollendurchsetzung und den Administrator-Workflows auf.
- Bei zwei Aufgaben mit mehreren Rollen sind 13 von 16 Schritten fehlgeschlagen.
- Frontends konnten in 4 Aufgaben nicht gerendert werden.
Claude Sonnet 4.6
Mit zwei Backend-Ausfällen und niedrigen API-Werten bei den meisten Aufgaben zeigte Claude Sonnet 4.6 eine inkonsistente Leistung. Eine Ausnahme bildete die Aufgabe mit einem API-Wert von 0,92, die CRUD, Authentifizierung, Rollenverwaltung und Ressourcenmanagement nahezu vollständig abdeckte (nur beim Löschen trat ein Fehler auf). Bei anderen Aufgaben generierte die Aufgabe das Projektgerüst und funktionierende Authentifizierungsschichten, die domänenspezifische Geschäftslogik blieb jedoch unvollständig. Fehlende Implementierungen:
- Ressourcenerstellung, -auflistung und Detailabruf
- Zustandsübergänge, Rollendurchsetzung, Eingabevalidierung
- Domänen-Workflows: Warenkorb/Kasse, Ticketverwaltung, Termine, Umfragen, Veranstaltungs-RSVP, Transaktionsverfolgung
Claude Opus 4.6
Aus Claude Opus 4.6 gingen nahezu vollständige Frontends hervor, allerdings mit minimaler Backend-Logik. Die Integritätsprüfung, Registrierung und Anmeldung wurden erfolgreich abgeschlossen, scheiterten jedoch im Allgemeinen an folgenden Punkten:
- Ressourcenerstellung
- Zustandsübergänge
- Rollenbasierter Zugriff
- Eingabevalidierung
- Admin-Workflows
Beispielprotokoll:
Kimi K2.5
Vollständige Implementierungen für einige Aufgabentypen standen im Gegensatz zu fehlgeschlagenen Backends für andere, was darauf schließen lässt, dass Kimi K2.5 einfachere CRUD-Aufgaben bewältigt, aber mit komplexen Multi-Role- oder Multi-Step-Anwendungen zu kämpfen hat.
GLM 4.7
Die Gesamtleistung von GLM 4.7 war durch begrenzte Ergebnisse gekennzeichnet. Bei den Aufgaben mit den höchsten Punktzahlen wurden die Frontends nur teilweise geladen, die Authentifizierungsendpunkte lieferten jedoch falsche Statuscodes. Die meisten Aufgaben wiesen fehlerhaften Backend- oder Frontend-Code auf.
Grok 4
Grok 4 brachte nur minimalen Backend-Code hervor, der typischerweise nur Health-Check- und Authentifizierungsendpunkte implementierte. Eine Aufgabe wurde vollständig erfüllt, ansonsten scheiterte es an Folgendem:
- Serviceangebote
- Ressourcenerstellung
- Administratorvorgänge
- Zustandsübergänge
Devstral 2 2512
Es wurde zwar teilweise Backend-Logik von Devstral generiert, aber aufgrund fehlender Dateien oder fehlerhafter Modulverweise erschien in keiner Aufgabe gültiger Frontend-Code.
Qwen3 Coder Weiter
Backend-Code, der nicht ausgeführt werden konnte, kennzeichnete die meisten Aufgaben, die von Qwen3 Coder Next ausgeführt wurden. Wo die Backends starteten, scheiterten die Frontends aufgrund fehlender Einstiegspunkte oder defekter Komponenten.
Trinity Große Vorschau
Trinity Large Preview erzielte die insgesamt niedrigsten Werte und generierte Projektstrukturen mit Fehlern, die die Ausführung der Anwendungen verhinderten. Den meisten Backends fehlten funktionierende Routenimplementierungen, und Frontends wiesen fehlende oder fehlerhafte Komponenten auf.
Kosten- und Erfolgsvergleich
Claude Opus 4.6 war pro Durchlauf das teuerste Modell, landete aber im Mittelfeld der Rangliste, während Devstral ähnliche Kosten wie Claude 4.5 Sonnet hatte, aber deutlich schlechter abschnitt. GPT-5.2 und GPT-5.2 Codex erzielten hohe Punktzahlen zu relativ niedrigen Kosten.
Abschluss-Tokens & Aufgabenabschlusszeit
Devstral verbrauchte über alle Modelle hinweg eine hohe Anzahl an Tokens, produzierte aber kein funktionierendes Frontend, was bedeutet, dass ein großer Teil des Outputs aus nicht funktionsfähigem oder redundantem Code bestand.
Kimi K2.5 und GLM 4.7 wiesen die höchsten Latenzzeiten auf und benötigten deutlich mehr Zeit pro Aufgabe, ohne dass sich die Ergebnisse entsprechend verbesserten.
Grok-4 war trotz der relativ geringen Anzahl generierter Token ähnlich langsam, was eher auf lange Pausen zwischen den Generierungen als auf große Ausgabemengen hindeutet. Im schnelleren Bereich erledigten Gemini 3 Pro Preview und GPT-5.2 Codex Aufgaben zügig mit moderatem Tokenverbrauch und erreichten beide eine Platzierung in der oberen Hälfte der Gesamtwertung.
LLM-Leistung bei einer einzelnen erfolgreichen Aufgabe
Nachdem wir unseren Benchmark mit 10 Aufgaben durchgeführt hatten, stellten wir fest, dass keine Aufgabe von allen LLMs korrekt gelöst wurde und dass viele Schritte fehlschlugen. Daher wollten wir untersuchen, wie sich Token und Latenz bei einer Aufgabe verhalten würden, die alle problemlos erfolgreich abschließen konnten.
Zu diesem Zweck haben wir eine minimale Basisaufgabe entwickelt: eine einfache In-Memory-Notes-API mit vier CRUD-Endpunkten, grundlegender Validierung und ohne Authentifizierung oder Datenbank. Alle LLM-Modelle haben diese Aufgabe mit einer Erfolgsquote von 100 % abgeschlossen. Dies bestätigt, dass alle Modelle die Generierung unkomplizierter APIs beherrschen, wenn die Komplexität reduziert wird.
Dies erlaubte es uns, ihren Tokenverbrauch, ihre Kosten und ihre Latenz bei einer einzelnen erfolgreichen Aufgabe zu vergleichen.
Kosten- und Codezeilenvergleich
Im vollständigen Benchmark war Claude 4.5 Sonnet das bestbewertete Modell mit durchschnittlichen Kosten von 0,29 US-Dollar pro Aufgabe; hier absolvierte es die Baseline für nur 0,012 US-Dollar und erreichte damit das Niveau der günstigsten Modelle.
Qwen3 Coder (0,012 $) und Trinity (kostenlos), die im vollständigen Aufgaben-Benchmark die letzten beiden Plätze belegten, boten im Vergleich zu den Spitzenreitern der Sonnet-Modelle wettbewerbsfähige Preise. Das bedeutet, dass bei einer Aufgabe, die alle bewältigen können, der Kostenunterschied zwischen den besten und schlechtesten Modellen weitgehend verschwindet, mit Ausnahme von Opus, das unabhängig vom Schwierigkeitsgrad der Aufgabe teuer bleibt.
Das Gemini 3.1 Pro Preview zum Preis von 0,016 US-Dollar zeigte bei dieser Basisaufgabe ein effizientes Preis-Leistungs-Verhältnis, obwohl es etwas teurer war als die günstigsten Modelle. Damit positionierte es sich wettbewerbsfähig im mittleren Preissegment und bewies ein gutes Preis-Leistungs-Verhältnis bei geringerer Aufgabenkomplexität.
Devstral 2 2512 wies die deutlichste Kostenreduzierung auf, mit einem Rückgang von 0,31 $ pro Aufgabe auf 0,021 $. Da es im Gesamt-Benchmark nur 0,07 Punkte erzielte, verdeutlicht dies einen wichtigen Aspekt der LLM-Preisgestaltung : Hohe Kosten spiegeln nicht immer hohe Token-Preise wider, sondern können eher auf wiederholte fehlgeschlagene Wiederholungsversuche als auf die grundlegende Preisstruktur des Modells zurückzuführen sein.
Claude Opus 4.6 blieb mit 0,086 US-Dollar der teuerste Wert, was dem Durchschnittswert von 1,17 US-Dollar im gesamten Benchmark entspricht und bestätigt, dass die Preisgestaltung pro Token unabhängig vom Schwierigkeitsgrad der Aufgabe kostspielig ist.
Grok-4 erzeugte die wenigsten Codezeilen, was mit dem geringen Tokenverbrauch im Gesamt-Benchmark übereinstimmt. GPT-5.2 Codex und GPT-5.2 wiesen ähnliche Kosten auf, jedoch war GPT-5.2 schneller und effizienter. Dies spiegelt das Ergebnis des Gesamt-Benchmarks wider, in dem GPT-5.2 bei gleichen Kosten höhere Werte erzielte und somit direkter zu Lösungen gelangt.
Vergleich von Abschluss-Tokens und Aufgabenabschluss
Kimi K2.5 benötigte 135 Sekunden für eine Aufgabe, die die meisten Modelle in unter 30 Sekunden erledigten. Dies bestätigt, dass die im vollständigen Benchmark beobachtete hohe Latenz eine Einschränkung auf Modellebene ist und nicht durch die Aufgabenkomplexität bedingt wird.
GLM 4.7, das langsamste Modell im gesamten Benchmark, erledigte diese Aufgabe in 24 Sekunden, eine 25-fache Reduzierung, was darauf schließen lässt, dass seine Latenz mit dem Schwierigkeitsgrad skaliert.
Qwen3 Coder war mit 10 Sekunden am schnellsten, obwohl es im Gesamt-Benchmark den letzten Platz belegte. GPT-5.2 benötigte weniger Token als GPT-5.2 Codex und war schneller, was mit dem Gesamt-Benchmark übereinstimmt, in dem GPT-5.2 bei kürzerer Laufzeit eine höhere Punktzahl erreichte.
Was sind agentenbasierte LLM-Systeme?
Die Softwareentwicklung ist ein iterativer Prozess: Code schreiben, ausführen, Fehler analysieren, beheben, wiederholen. Agentische KI- Systeme ermöglichen es Lernmodellen, diesem Zyklus zu folgen. Das Modell arbeitet in einer Entwicklungsumgebung, in der es Dateien schreiben, Befehle ausführen, Ausgaben analysieren und basierend auf den gewonnenen Erkenntnissen Änderungen vornehmen kann, bis die Aufgabe abgeschlossen ist.
Das ist wichtig, weil reale Anwendungen nicht aus einzelnen Dateien bestehen. Sie haben Backends mit Routen und Datenbankmodellen, Frontends mit Komponenten und API-Aufrufen, Konfigurationsdateien, Abhängigkeiten und Tests. Um diese Komponenten zum Laufen zu bringen, sind iteratives Testen und Optimieren erforderlich – genau das ermöglicht die agentenbasierte Architektur.
So funktioniert es
Das Modell befindet sich in einem Testsystem mit Zugriff auf Shell, Dateisystem und Ausgabedatei. Beim Erstellen einer Anwendung schreibt es die Dateien schrittweise. Nach jedem Schritt zeigt das Testsystem dem Modell die Ergebnisse an: Ist der Server gestartet? Wurden die Tests erfolgreich abgeschlossen? Wurden Fehler vom Linter gemeldet? Basierend auf diesem Feedback entscheidet das Modell, was als Nächstes geschrieben oder korrigiert werden soll.
Dies unterscheidet sich grundlegend von der einmaligen Generierung. Bei einmaligen Generierungen generiert das Modell blind eine gesamte Codebasis, ohne deren Funktionsfähigkeit überprüfen zu können. In agentenbasierten LLM-Systemen erkennt das Modell die Konsequenzen jeder Aktion und korrigiert entsprechend. Diese Fähigkeit allein reicht jedoch nicht aus. Das Modell benötigt weiterhin fundierte Schlussfolgerungen, um die Geschäftslogik korrekt zu implementieren – und genau hier zeigen sich die entscheidenden Leistungsunterschiede.
Agentic LLM Benchmark-Methodik
Wir nutzten Aider für alle Agenten und stellten die Verbindung zu den Modellen über OpenRouter her. Wir evaluierten ihre Fähigkeit, autonom an zehn Softwareentwicklungsaufgaben (T-1 bis T-10) zu arbeiten, von einfachen Reservierungssystemen bis hin zu komplexen interaktiven Dashboards. Diese Aufgaben erfordern von den Agenten die Verwaltung von Projekten mit mehreren Dateien und die Bereitstellung funktionsfähiger Produkte.
Ausführung und Orchestrierung
Jeder Agent und jede Aufgabe startet 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 protokollieren wir Exit-Codes, Ausführungszeit und ob die Backend- und Frontend-Dateien erstellt wurden. Außerdem verfolgen wir die Token-Nutzung in Echtzeit für Eingabe-, Ausgabe- und Cache-Kategorien.
Backend-Validierung : Wir stellen die generierten Projekte in isolierten Umgebungen bereit, um sie anhand eines kanonischen YAML-Vertrags zu testen. Die Validierung umfasst den erfolgreichen Ausführungsablauf, die Fehlerbehandlung (400/403/409) und die Datenkonsistenz.
Wir testen die Ergebnisse in zwei Modi:
Der adaptive Modus prüft die Funktionalität auch bei unterschiedlichen Routennamen, während der strikte Modus die exakte Einhaltung des Vertrags erfordert.
Die Gesamtbewertung des Backends wird wie folgt berechnet: Backend-Gesamtbewertung = (bereite_Aufgaben / Gesamtaufgaben) × Durchschnitt(Erfolgsraten von adaptivem und striktem Modus)
UI- und Benutzerszenariotests
Wir nutzen Browserautomatisierung, um reale Benutzerabläufe zu simulieren, einschließlich Preflight-Tests, Rendering und Authentifizierung. Wir überprüfen Funktionsschritte wie das Absenden der Anmeldedaten und das Verhalten nach der Anmeldung, um sicherzustellen, dass die Anwendung absturzfrei läuft.
Die UI-Performance wird anhand der Schritt-Erfolgsrate gemessen: Schritt-Erfolgsrate = bestanden / (bestanden + fehlgeschlagen + blockiert)
Tokenberechnung
Die Tokenanzahl wird aus der LLM-API-Antwort extrahiert. Wir subtrahieren die zwischengespeicherten Eingabe-Token von der Gesamtzahl der Eingabe-Token, um die effektive Eingabe zu erhalten, die nur neu verarbeitete Token berücksichtigt. Ausgabe-Token werden nie zwischengespeichert und bleiben daher unverändert.
Endgültige Aggregation
Die endgültige Benchmark-Punktzahl wird durch die Kombination der Ergebnisse aus den vorherigen Phasen berechnet: Endergebnis = (0,7 × backend_overall) + (0,3 × ui_overall). Wir gewichten das Backend höher, 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. Hauptziel ist der Aufbau einer Plattform, die die Kommunikation zwischen Kunden und Supportmitarbeitern vermittelt und gleichzeitig Geschäftsregeln und Sicherheitsvorgaben strikt einhält. Diese Aufgabe bewertet die Fähigkeit eines Mitarbeiters, Mehrbenutzer-Zustandsautomaten, Datenisolation und Thread-Kommunikation in einer Full-Stack-Umgebung zu handhaben.
Die Aufgabe bestand darin, ein Helpdesk-System mit folgenden Merkmalen zu entwickeln:
- Unterschiedliche Berechtigungen für Kunden (Ausstellen/Beantworten) und Agenten (Verwaltung/Problemlösung).
- Ein starrer Status-Workflow, der unzulässige Übergänge verhindert und rollenspezifische Aktionen durchsetzt.
- Erweiterte Datenisolierung, bei der nicht autorisierte Ressourcenanfragen den Statuscode 404 anstatt 403 zurückgeben, um die Systemintegrität zu schützen.
- Ein chronologisches Antwortsystem für eine nahtlose Interaktion zwischen Agent und Kunde.
- Ein FastAPI-Backend kombiniert mit einem responsiven, Vite-basierten Frontend (React/Vue/Svelte).
- Reproduzierbare Einrichtung über spezifische Shell-Befehle zur sofortigen Systemaktivierung.
Die Dokumentation zu Aufgabe 6 finden Sie auf GitHub .
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.