A-CODE-CLI Bench: Agentic CLI Benchmark

Agentic CLI-Tools sind KI-Coding-Tools, die Dateien erstellen und löschen, Befehle ausführen, planen und die Codierung des gesamten Projekts durchführen können. Wir haben die führenden Tools in 10 realen Webentwicklungsszenarien einem Benchmark unterzogen, wobei wir ~600 atomare Validierungsprüfungen pro Agent und insgesamt mehr als ~5.000 automatisierte Testausführungen durchgeführt haben – einschließlich Backend-Logik, Frontend-Funktionalität und Konsistenzprüfungen über mehrere Durchläufe.

Ergebnisse des Agentic CLI Benchmarks

Performance-Erkenntnisse zu Agentic CLI-Tools

Die Backend-Korrektheit bestimmt das Ranking; die kombinierte Punktzahl gewichtet sie mit 0,7 gegenüber 0,3 für das Frontend.

• Alle neun sauber laufenden Agenten verwenden denselben Sonnet 4.6, doch die Backend-Ergebnisse reichen von Opencodes 77,3 % bis hinunter zu Gooses 55,4 %. Diese 22-Punkte-Lücke stammt vollständig aus der Orchestrierung.
• Ein starkes Backend garantiert kein starkes Endergebnis: Cline (4. im Backend, 69,5 %) und Forge (5., 67,2 %) rangieren im Backend nahe der Spitze, schneiden aber im Frontend schlecht ab – Clines 52,5 % sind das schwächste im Feld, sodass beide in der kombinierten Tabelle zurückfallen.
• Codex rangiert auf Platz 10 im Backend (52,1 %), trotz perfekter 100 % im Frontend. Es läuft hier über einen Proxy, um das gemeinsame Modell zu erreichen, was seine Fähigkeiten beeinträchtigen kann – dies ist daher wahrscheinlich eine Untergrenze und nicht das tatsächliche Backend des Agenten.¹ Gemini, ebenfalls über einen Proxy ausgeführt, ist auf die gleiche Weise eingeschränkt.
• Der Build-Rang sagt nichts über das Verhalten aus: Der Agent, der hier führt, behält nach der Komprimierung nichts, während ein Agent aus dem Mittelfeld alles behält.

Geschwindigkeit, Token-Nutzung und Kosten vs. Punktzahl

Wir haben die Laufzeiteffizienz anhand der durchschnittlichen Ausführungszeit (Sekunden), der effektiven Token-Nutzung (Input + Output) und der Kosten pro Aufgabe (USD) bewertet – jeweils gegen die kombinierte Genauigkeitspunktzahl aufgetragen:

Wie schnell, günstig oder token-arm ein Agent ist, sagt nicht voraus, wie gut er abschneidet.

• Opencode gewinnt in allen drei Bereichen gleichzeitig: beste kombinierte Punktzahl (81,6 %), die niedrigsten Kosten aller leistungsfähigen Agenten ($1,03 pro Aufgabe), gehört zu den wenigsten Tokens und den schnellsten Durchläufen. Es kehrt den üblichen Kompromiss zwischen Genauigkeit und Kosten um.
• Die Kosten spannen sich um etwa den Faktor 40, von Forge $0,18 bis Junie $7,58, ohne Zusammenhang mit dem Rang. Forge ist am günstigsten, weil es am wenigsten leistet: Sein Backend scheitert an der Ticket-Erstellung. Junies $7,58 erkaufen ein Mittelfeld-Ergebnis von 74,7 % und stellen eine aufgeblähte Obergrenze dar.
• Goose zahlt am meisten für das Wenigste: zweitteuerster mit $3,23, aber die niedrigste saubere Punktzahl des Feldes (62,5 %). Die Top-Drei nach Punktzahl bleiben günstig (Opencode $1,03, Claude Code $1,83, Grok $2,03).
• Weder der schnellste noch der langsamste Agent gewinnt: Kiro (439s) und Gemini (1.158s, Proxy-Overhead) landen beide im Mittelfeld. Zusätzliche Ausgaben erkaufen Wiederholungen und erneute Validierung, nicht mehr Problemlösungstiefe.
• Die Token-Zahlen hängen hauptsächlich mit Caching zusammen. Codex, Claude Code, Cline, Opencode, Gemini und Grok cachen 86–98 % ihres Inputs, sodass Claude Codes 4,18M Brutto-Tokens auf effektive 115k reduziert werden. Junie, Goose, Kiro, Forge und Aider cachen nicht, also zahlen sie für jeden erneut gesendeten Token; deshalb sind Junies 2,36M die höchsten im Feld.
• Drei Vorbehalte zu den Zahlen: Bei den fünf nicht-cachenden Agenten ist der effektive Input alles, was sie gesendet haben – also als Obergrenze zu lesen; Kiros $1,72 sind eine Untergrenze (guthabenbasiert abgerechnet, tatsächlich eher $2,23); Clines 64,4 % umfassen vier Aufgaben, bei denen es sein Fehlerlimit erreichte, bevor ein Frontend bereitgestellt wurde – jede mit 0 bewertet.

Unsere Methodik finden Sie unten.

Wie agentic CLI-Tools funktionieren

Agentic CLI-Tools sind autonome Agenten, die innerhalb des Terminals arbeiten. Während die meisten Benutzer sie für Coding-Aufgaben einsetzen, können sie jeden Workflow ausführen, der über Shell-Befehle durchführbar ist.

Diese Agenten arbeiten typischerweise in einer Schleife, die aus drei Phasen besteht:

1. Kontext erfassen
2. Aktion ausführen
3. Ergebnisse überprüfen

Nach der Überprüfung erfasst der Agent den aktualisierten Kontext und wiederholt die Schleife, bis er die Aufgabe abgeschlossen hat oder eine Abbruchbedingung erreicht.

Die Schleife wird von zwei Quellen beeinflusst:

• Dem menschlichen Benutzer, der die anfängliche Aufgabe stellt und die Ausführung unterbrechen kann
• Dem Modell, das Planung, Schlussfolgerung und Aktionsauswahl durchführt

Das Agent-Framework bietet Struktur rund um das Modell. Es definiert, wie das Modell planen soll, wann es Befehle ausführen soll, wie es Ergebnisse validieren soll und welche Tools verfügbar sind. Diese Tools können Shell-Ausführung, Dateisystemzugriff, Browser-Steuerung, Computer-Use, MCP-Integrationen oder wiederverwendbare „Skills“ umfassen.

Unterschiedliche Agent-Architekturen setzen unterschiedliche Planungsstrategien, Wiederholungsrichtlinien und Verifikationslogiken durch. Einige Agenten priorisieren Präzision und tiefere Schlussfolgerung auf Kosten höherer Token-Nutzung und Latenz. Andere priorisieren Geschwindigkeit und niedrigere Kosten mit geringerer Verhaltensrobustheit.

Modellintelligenz vs. Agent-Architektur

Leistungsunterschiede zwischen agentic CLI-Tools stammen nicht aus einer einzigen Quelle. Sie entstehen aus zwei Schichten: dem Foundation-Modell und dem Orchestrierungs-Framework, das es umgibt.

Dieser Benchmark testet beide Agenten auf demselben Foundation-Modell: Claude Sonnet 4.6. Jeder Unterschied in der Punktzahl ist daher ein Unterschied in der Orchestrierung: wie die CLI Kontext erfasst, wann sie Befehle ausführt, wie sie Ausgaben validiert und ob sie nach Fehlern erneut versucht.

Opencode und Claude Code verwenden beide Sonnet 4.6 direkt. Opencode erreicht 77,3 % im Backend; Claude Code erreicht 74,9 %. Zwei Agenten, dasselbe Modell, 2,4 Prozentpunkte Unterschied in der Backend-Korrektheit. Kiro und Opencode verwenden beide Sonnet 4.6. Kiro erreicht 64,2 % im Backend; Opencode erreicht 77,3 %. Die 13-Punkte-Lücke ist der Beitrag der CLI.

Die beiden nachfolgenden Beobachtungs-Benchmarks treiben dies weiter. Sie führen denselben Common-Model-Test zur Web-Recherche und Kontext-Komprimierung durch, bei denen die Lücken nicht 13 Punkte betragen, sondern den Unterschied zwischen dem Finden der richtigen Antwort und dem Erfinden einer falschen.

Web-Recherche-Grounding

Wir haben jeden Agenten gebeten, die Framework-Dokumentation zu prüfen: welche Version ein Feature eingeführt hat, welchen aktuellen Status es hat und was sich kürzlich geändert hat. Jede Antwort musste eine offizielle Quelle zitieren. Wir haben die Prüfung zweimal durchgeführt, einmal zu Unity und einmal zu Next.js/React. Die Fakten wurden so ausgewählt, dass die richtige Antwort nur auf einer aktuellen, veröffentlichten Seite existiert. Eine Antwort aus den Trainingsdaten führt zu einer selbstbewussten, aber falschen Antwort. Wir haben eine Sache geprüft: Hat der Agent die von ihm zitierte Seite tatsächlich abgerufen?

Vier Agenten verfügen über integrierte Websuche. Drei davon (Codex, Gemini, Grok) liefen auf ihren nicht-Sonnet-nativen Modellen; die anderen acht, einschließlich Claude Code, liefen auf Sonnet 4.6.

Vier Muster zeichneten sich ab.

• Echte Live-Suche Codex, Claude Code, Gemini und Grok rufen aktuelle Seiten ab und erfassen kürzliche Änderungen. Codex war der einzige Agent, der das Entwicklerforum erreichte, wo die schwierigsten Fakten liegen.
• Sucht, landet aber auf alten Seiten Cline rief zwei Dutzend echte Dokumentationsseiten ab und meldete dennoch eine Version, die ersetzt worden war. Die Abrufe waren echt; die Seiten waren veraltet.
• Keine Suche, antwortet aus dem Training Aider browsed nicht und sagt dies auch. Dies ist die ehrliche Antwort.
• Erfundene Quellen Forge rief nichts ab, das funktionierte, zitierte aber dennoch 31 Quellen bei der Next.js-Prüfung. Die zitierten Seiten existieren nicht. Seine Abschlusserklärung: „Jede Zelle stammt von einer Seite, die während dieser Sitzung tatsächlich abgerufen wurde.“

Bei der Next.js-Prüfung hat jeder andere browsende Agent nahezu alle seine Zitate in Seiten verankert, die er tatsächlich abgerufen hatte. Forge verankerte keine. Das Diagramm stellt die verankerten Zitate jedes Agenten seinen erfundenen gegenüber, sodass die ehrlichen Agenten als volle grüne Balken und Forge als einzelner roter Balken erscheinen. Das Diagramm umfasst die acht Agenten mit einem überprüfbaren URL-Abrufprotokoll. Grok (serverseitige Suche), Gemini (abgebrochener Durchlauf) und Aider (keine Zitate) erscheinen in der obigen Tabelle, sind hier jedoch ausgeschlossen.

Cline und Claude Code liefen beide auf Sonnet 4.6 in diesem Test. Claude Code fand und öffnete die Seite mit der richtigen Antwort. Cline tat dies nicht. Gleiches Modell, unterschiedliches Ergebnis.

Wir haben jede Antwort auf faktische Genauigkeit bewertet, aber diese Punktzahlen hängen von einem Antwortschlüssel ab, der derzeit überprüft wird. Wir halten die Genauigkeitstabellen zurück, bis der Schlüssel finalisiert ist.

Kontext-Komprimierung

Wenn eine Sitzung lang wird, komprimiert der Agent seinen Kontext: Er ersetzt den detaillierten Verlauf durch eine kurze Zusammenfassung und verwirft die Originale. Wir haben getestet, ob die Zusammenfassung das Wesentliche behält.

Wir gaben jedem Agenten ungefähr 112.000 Tokens an Dokumenten mit 13 eingebetteten erfundenen Fakten: eine Bereitschafts-PIN, eine Cloud-Region, ein Build-Tag und zehn weitere. Erfunden bedeutet, dass die Werte eindeutige Zeichenketten sind, die in den Trainingsdaten nicht vorkommen. Der Agent las die Dokumente und komprimierte. Wir löschten dann die Quelldateien und fragten nach allen 13 Fakten. Da die Dateien gelöscht sind, ist die einzige mögliche Quelle die Komprimierungs-Zusammenfassung.

Vier Agenten behielten jeden Fakt. Drei behielten keinen. Die drei, die aus dem Gedächtnis 0 erzielten, hatten 13 von 13 beantwortet, solange sie die Dateien noch erneut lesen konnten. Sie lasen bei jeder Anfrage erneut. Als die Dateien weg waren, schrieben sie „unbekannt“, anstatt zu raten.

Goose, Forge, Opencode und Kiro laufen alle auf Sonnet 4.6. Kiro behielt alle 13. Die anderen drei behielten keine. Gleiches Modell, entgegengesetztes Ergebnis.

Opencode rangiert an erster Stelle im Build-Benchmark und behält nichts bei der Komprimierung. Kiro rangiert an siebter Stelle im Build-Benchmark und behält alles bei der Komprimierung. Starke Build-Leistung und starke Komprimierung sind unabhängige Eigenschaften.

Vier Agenten fielen aus dem Rahmen dieses Tests, jeweils aus einem konkreten Grund. Cline konnte nicht an seine Komprimierungsschwelle gebracht werden. Wir erstellten einen 863.000-Token-Dokumentensatz und ließen ihn jede Datei lesen, aber Cline kürzt jede Tool-Ausgabe auf etwa 2.000 Zeichen, sodass die Dokumente zu kurzen Vorschauen zusammenfielen. Sein Kontext stagnierte bei 214.000 Tokens, 21 % seines Eine-Million-Token-Fensters, und die Komprimierung wurde nie ausgelöst. Wir berichten Cline als unter diesem Protokoll nicht messbar, anstatt eine Zahl zu schätzen. Grok hat einen Komprimierungsbefehl, aber es las unsere Dokumente in Fragmenten, anstatt sie vollständig zu laden, sodass es nie einen vollständigen Kontext zum Komprimieren gab. Aiders Summarizer komprimiert Chat-Runden, nicht die Inhalte der zur Sitzung hinzugefügten Dateien – dort befanden sich die Fakten. Junie hat kein Komprimierungs-Feature.

Agent-Verhalten bei Aufgabe 6

Wir haben Agenten in 10 Aufgaben bewertet. Nachfolgend eine detaillierte Aufschlüsselung von Aufgabe 6, um zu zeigen, wie sich verschiedene CLI-Architekturen unter denselben Bedingungen verhalten, wenn alle auf demselben Modell laufen.

Aufgabe 6: Helpdesk-Ticket-System (Web)

Aufgabe 6 erforderte den Aufbau eines Full-Stack-Helpdesk-Ticket-Systems mit:

• Zwei Benutzerrollen (Kunde und Agent)
• JWT-basierter Authentifizierung
• Strengen Status-Workflow-Übergängen
• Datenisolation (404 statt 403 bei benutzerübergreifendem Zugriff)
• FastAPI-Backend
• React/Vue/Svelte + Vite-Frontend
• Deterministischen Ausführungsbefehlen

Der Smoke-Test validierte:

• Health Check
• Authentifizierung mit zwei Rollen
• Ticket-CRUD-Operationen
• Zuweisung und Antworten
• Status-Übergänge
• Rollendurchsetzung
• Datenisolation
• UI-Login und Verhalten nach dem Login

Diese Aufgabe beansprucht Zustandsmanagement, Auth-Korrektheit, REST-Vertragsdisziplin und Frontend-Backend-Integration. Besuchen Sie GitHub, um die Aufgabendetails einzusehen.

Auf einem Modell teilte sich das Feld in drei Gruppen.

• 60 % Backend, sieben Agenten (Codex, Claude-Code, Cline, Grok, Goose, Junie, Opencode): identische sechs fehlgeschlagene Schritte in allen drei Wiederholungen. Auth, Ticket-CRUD, Antworten und Datenisolation bestanden; beide Fehlschläge betrafen /tickets/{id}/assign und /tickets/{id}/status, wobei sie einen einheitlichen PATCH /tickets/{id} anstelle der separaten Routen der Spezifikation bauten. Geschäftslogik korrekt, REST-Vertrag falsch. Im vorherigen nativen Durchlauf mit Gemini 3 Pro baute Opencode die separaten Endpoints und erzielte 93,3 %; mit Sonnet 4.6 wählte es das einheitliche Design wie die anderen.
• 13,3 %, drei Agenten (Aider, Forge, Gemini-CLI): Authentifizierung funktionierte, aber die Ticket-Erstellung selbst schlug fehl, sodass jeder abhängige Schritt kaskadierte.
• 24,4 %, Kiro: Instabilität, nicht ein Fehlermodus. Es bestand neun Schritte in Durchlauf eins, zwei in Durchlauf zwei, und in Durchlauf drei startete das Backend nie (Health Check fehlgeschlagen). Die anderen zehn Agenten wiederholten sich in jedem Durchlauf identisch.
• UI innerhalb des 60 %-Clusters: Claude-Code und Cline scheiterten beim Login an einem identischen CORS-Bug – das Frontend rief das Backend auf localhost:8000 von einem 127.0.0.1-Ursprung aus auf und der Browser blockierte es, sodass beide 75 % erzielten; die anderen fünf renderten und loggten sauber bei 100 % ein.
• Die Erkenntnis ist Konvergenz: Sieben verschiedene CLIs auf demselben Modell machten denselben REST-Vertragsfehler – hier dominiert also das Modell und die Orchestrierung spielt kaum eine Rolle, das Gegenteil der untenstehenden Beobachtungs-Benchmarks.

Codex

Installation

Global installieren mit:

• npm install -g @openai/codex

Alternativ global mit Homebrew installieren (macOS/Linux)

• brew install –cask codex

Authentifizierung

Nach der Einrichtung von Codex können Sie mit Ihrem ChatGPT-Konto oder mit Ihrem OpenAI-API-Key fortfahren. Keine Provider-Optionen verfügbar.

Aufgabenbericht

Codex baute ein funktionierendes System in 454 Sekunden und landete im 60 %-Cluster. Die Geschäftslogik war korrekt; es verfehlte den REST-Vertrag bei Zuweisung und Status, wie der Rest des Feldes.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die auf `/tickets/{id}/assign` und `/tickets/{id}/status` abzielten. Codex leitete beide über einen einheitlichen Update-Endpoint, sodass diese Aufrufe 404 zurückgaben. Stabil über alle drei Wiederholungen.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. Login und Post-Login-Zustand verhielten sich korrekt. 100 % UI.

Junie

Installation

Junie ist über die JetBrains Toolbox oder als eigenständige CLI verfügbar:

• curl -fsSL https://junie.jetbrains.com/install | bash

Authentifizierung

Fahren Sie mit Ihrem JetBrains-Konto fort oder generieren Sie einen JUNIE_API_KEY auf junie.jetbrains.com/cli, oder exportieren Sie Ihren eigenen API-Key von Anthropic, OpenAI, Google oder anderen unterstützten Providern. Mehrere Provider-Optionen verfügbar.

Aufgabenbericht

Junie produzierte ein vollständiges Full-Stack-System in 444 Sekunden und erzielte 60 % Backend, im Hauptcluster. Sein effektiver Input bei dieser Aufgabe ist mit 1,52M der höchste im Feld, eine ungecachte Obergrenze, die von einem bekannten Caching-Accounting-Bug betroffen ist (siehe Hinweis in der Ergebnistabelle).

Backend-Verhalten

Neun von sechzehn Schritten bestanden: Authentifizierung, Ticket-CRUD, Antworten und Datenisolation. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte. Junie behandelte Status und Zuweisung über einen einheitlichen Update-Endpoint, sodass die `/tickets/{id}/assign`- und `/tickets/{id}/status`-Routen der Spezifikation 404 zurückgaben. Die Übergangslogik selbst war korrekt. Stabil über alle drei Wiederholungen.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. 100 % UI.

Kiro CLI

Installation

Für macOS/Linux/WSL:

• curl -fsSL https://cli.kiro.dev/install | bash

Alternative Linux AppImage (portable Option):

• Download: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage

Dann ausführen:

• chmod +x kiro-cli.appimage && ./kiro-cli.appimage

Authentifizierung

Sie können mit Ihrem Kiro-Code-Plan fortfahren. Keine Provider-Optionen verfügbar.

Aufgabenbericht

Kiro ist der einzige Agent, dessen Punktzahl Instabilität und nicht eine einzelne Designentscheidung widerspiegelt. Seine 24,4 % Backend sind ein Durchschnitt über drei Wiederholungen, die drei verschiedene Ergebnisse hervorbrachten. Der Build selbst war solide, wenn er lief; das Problem war, dass er nicht zweimal gleich lief.

Backend-Verhalten

Im ersten Durchlauf bestand Kiro neun von sechzehn Schritten, das gleiche Profil wie der 60 %-Cluster, und scheiterte nur an den Zuweisungs- und Statusrouten. Im zweiten Durchlauf bestand es zwei. Im dritten kam das Backend nie hoch und selbst der Health Check schlug fehl. Im Durchschnitt ergibt dies 24,4 %. Die Instabilität, nicht das Endpoint-Design, unterscheidet Kiro hier vom Cluster.

UI-Verhalten

Wenn das Backend lief, bestand das Frontend alle acht Validierungsschritte. 100 % UI. Dies ist eine Änderung gegenüber dem vorherigen Durchlauf, bei dem das Login-Formular bei einem 422 beim Mount nicht gerendert wurde.

Claude Code

Installation

Für macOS/Linux/WSL können Sie Claude Code je nach bevorzugtem Paketmanager entweder installieren mit:

• curl -fsSL https://claude.ai/install.sh | bash
• npm install -g @anthropic-ai/claude-code

Authentifizierung

Nach der Einrichtung von Claude Code können Sie mit Ihrem Claude-Konto fortfahren. Keine Provider-Optionen verfügbar.

Aufgabenbericht

Claude Code erzielte 60 % Backend in 379 Sekunden, im Hauptcluster. Dies ist eine deutliche Verbesserung gegenüber dem vorherigen Durchlauf, bei dem ein JWT-Validierungsfehler bei jeder authentifizierten Route 401 zurückgab und 13 von 16 Schritten fehlschlugen. In diesem Durchlauf funktionierte das Backend; der Verlust lag bei der UI.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die über einen einheitlichen Update-Endpoint anstelle der separaten Pfade der Spezifikation geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

Der Login-Schritt schlug fehl. Das Frontend rief das Backend auf localhost:8000 auf, während die Seite von einem 127.0.0.1-Ursprung ausgeliefert wurde, und der Browser blockierte die Login-Anfrage aufgrund der CORS-Richtlinie. Fünf Schritte bestanden, einer schlug fehl, zwei wurden blockiert. 75 % UI. Cline scheiterte auf die gleiche Weise.

Aider

Installation

Wenn Sie bereits Python 3.8-3.13 installiert haben, installieren Sie zunächst Aider:

• python -m pip install aider-install
• aider-install

Authentifizierung

Melden Sie sich bei Ihrem OpenRouter-Konto an und autorisieren Sie, oder exportieren Sie Ihren API-Key in Ihrer Umgebung mit:

• export OPENROUTER_API_KEY=“sk-or-v1-…”

Aufgabenbericht

Aider war der schnellste Agent mit 236 Sekunden und der leichteste, mit 1,3k Input- und 18k Output-Tokens. Es erzielte auch 13,3 % Backend. Authentifizierung funktionierte, aber die Ticket-Erstellung schlug fehl, und jeder Schritt, der ein bestehendes Ticket benötigte, scheiterte mit.

Backend-Verhalten

Zwei Schritte bestanden. Der Build brach bei der Ticket-Erstellung ab, sodass die Kunden- und Agenten-Ticketlisten, Antworten, Zuweisung, Status-Übergänge und Rollenprüfungen alle kaskadierend fehlschlugen. Stabil über alle drei Wiederholungen. Dies ist eine andere Fehlerklasse als der 60 %-Cluster, der Tickets korrekt erstellte und nur die Zuweisungs- und Statusrouten verfehlte.

UI-Verhalten

Der Login-Schritt schlug aufgrund derselben CORS-Ursprungsinkongruenz fehl, die bei Claude-Code und Cline zu sehen war. Fünf Schritte bestanden, einer schlug fehl, zwei blockiert. 75 % UI.

OpenCode

Installation

Für macOS/Linux/WSL:

• curl -fsSL https://opencode.ai/install | bash

Global installieren mit:

• npm i -g opencode-ai

Für macOS/Linux, je nach bevorzugtem Paketmanager:

• bun add -g opencode-ai
• brew install anomalyco/tap/opencode
• paru -S opencode

Authentifizierung

Es gibt viele Provider-Optionen – wählen Sie Ihren gewünschten Provider und authentifizieren Sie sich mit /connect

Aufgabenbericht

Opencode führt den Gesamt-Benchmark an, aber bei Aufgabe 6 erzielte es 60 % Backend, im Hauptcluster, in 542 Sekunden. Dies ist der klarste einzelne Modellbeleg im Artikel. Im vorherigen nativen Modell-Durchlauf mit Gemini 3 Pro Preview baute Opencode die separaten Endpoints der Spezifikation und erzielte hier 93,3 %. Dieselbe CLI mit Sonnet 4.6 wählte den einheitlichen Endpoint und fiel auf 60 %. Das Tool änderte sich nicht; das Modell schon.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die über einen einheitlichen Update-Endpoint geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. 100 % UI.

Grok Build

Installation

Für macOS/Linux:

• curl -fsSL https://x.ai/cli/install.sh | bash

Authentifizierung

Melden Sie sich beim ersten Start mit Ihrem xAI-Konto an oder setzen Sie einen API-Key für die headless-Nutzung:

• export XAI_API_KEY=“xai-…”

Aufgabenbericht

Grok belegte im Build-Benchmark insgesamt den zweiten Platz mit 75,4 % Backend. Bei Aufgabe 6 erzielte es 60 % Backend in 433 Sekunden, im Hauptcluster. In diesem Durchlauf erreichte Grok Sonnet 4.6 über OpenRouter.

Backend-Verhalten

Neun von sechzehn Schritten bestanden: Authentifizierung, Ticket-CRUD, Antworten und Datenisolation. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die auf /tickets/{id}/assign und /tickets/{id}/status abzielten. Grok leitete beide über einen einheitlichen Update-Endpoint, sodass diese Aufrufe und die davon abhängigen Rollenprüfungen 404 zurückgaben. Stabil über alle drei Wiederholungen.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. Login und Post-Login-Zustand verhielten sich korrekt. 100 % UI.

Forge

Installation

Für macOS/Linux/WSL:

• curl -fsSL https://forgecode.dev/cli | sh

Authentifizierung

Konfigurieren Sie Ihre Provider-Anmeldedaten interaktiv mit:

• forge provider login

Und wählen Sie Ihren Provider.

Aufgabenbericht

Forge erzielte 13,3 % Backend in 844 Sekunden. Seine Output-Token-Zahl ist mit 1,6k die niedrigste im Feld, was auf eine oberflächliche Implementierung hinweist. Wie im vorherigen Durchlauf brach der Build bei der Ticket-Erstellung ab und kaskadierte.

Backend-Verhalten

Zwei Schritte bestanden. Die Ticket-Erstellung schlug fehl, sodass die Ticketlisten, Antworten, Zuweisung, Status-Übergänge und Rollenprüfungen alle mit fehlschlugen. Stabil über alle drei Wiederholungen, das gleiche 13,3 %-Profil wie Aider und Gemini-CLI.

UI-Verhalten

Der Login-Schritt schlug aufgrund derselben CORS-Ursprungsinkongruenz fehl, die bei Claude-Code, Cline und Aider zu sehen war. Fünf Schritte bestanden, einer schlug fehl, zwei blockiert. 75 % UI.

Gemini CLI

Installation

Sofort ausführen:

• npx @google/gemini-cli

Oder global installieren:

• npm install -g @google/gemini-cli
• brew install gemini-cli

Authentifizierung

Option 1 (Google OAuth): export GOOGLE_CLOUD_PROJECT=“YOUR_PROJECT_ID” dann gemini starten.
Option 2 (API-Key): export GEMINI_API_KEY=“YOUR_API_KEY” dann gemini starten.
Option 3 (Vertex KI): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Aufgabenbericht

Gemini CLI erzielte 13,3 % Backend in 926 Sekunden, einer der beiden langsamsten Agenten im Feld. Authentifizierung funktionierte, aber die Ticket-Erstellung schlug fehl und kaskadierte. Das Frontend, das im vorherigen Durchlauf aufgrund einer Inkompatibilität von Node 18 mit Vite 7 vollständig ausgefallen war, bestand diesmal jeden Schritt.

Backend-Verhalten

Zwei Schritte bestanden. Die Ticket-Erstellung schlug fehl, sodass alle abhängigen Schritte fehlschlugen. Stabil über alle drei Wiederholungen, das gleiche 13,3 %-Profil wie Aider und Forge.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. 100 % UI, gegenüber 0 % im vorherigen Durchlauf. Ein 401 erschien in der Konsole bei einem authentifizierten Aufruf, blockierte aber nicht den gerenderten Ablauf.

Cline

Installation

Global installieren mit:

• npm install -g cline

Authentifizierung

Durch Eingabe von `cline auth` können Sie Ihr Cline-Konto auswählen oder mit Ihrem gewünschten Provider fortfahren.

Aufgabenbericht

Cline erzielte 60 % Backend in 648 Sekunden, im Hauptcluster. Dies ist eine große Änderung gegenüber dem vorherigen Durchlauf, bei dem das Acht-Fehler-Limit den Build vorzeitig beendete und ein leeres Frontend hinterließ. Hier wurde der gesamte Stack fertiggestellt.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die über einen einheitlichen Update-Endpoint geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

Der Login-Schritt schlug aufgrund derselben CORS-Ursprungsinkongruenz fehl, die bei Claude-Code zu sehen war, bei einer 127.0.0.1-Seite, die ein localhost-Backend aufrief. Fünf Schritte bestanden, einer schlug fehl, zwei blockiert. 75 % UI.

Goose

Installation

Für macOS/Linux/WSL:

• curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

Aufgabenbericht

Goose erzielte 60 % Backend in 553 Sekunden, im Hauptcluster, verbrauchte aber 1,06M Input-Tokens, um dorthin zu gelangen. Es stellte diesmal den gesamten Stack fertig – eine Änderung gegenüber dem vorherigen Durchlauf, bei dem das Frontend-Verzeichnis leer blieb.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge betrafen die Zuweisungs- und Status-Übergangsschritte, die über einen einheitlichen Update-Endpoint geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. 100 % UI, gegenüber 0 % im vorherigen Durchlauf.

Entdecken Sie weitere unserer Benchmarks und datengestützten Erkenntnisse in der Google-Suche.

Als bevorzugte Quelle hinzufügen

KI-Coding-Tools

KI-Coding-Tools lassen sich in drei Kategorien einteilen:

• Agentic CLI: Tools für terminalbasierte Entwicklungsworkflows – generieren, bearbeiten und refaktorisieren Code durch Prompts und Kommandozeilen-Interaktionen.
  • Beispiele: Aider, Junie, Opencode, Claude Code, Codex

• KI-Code-Editoren: Auch als agentic IDEs bekannt – diese Tools bieten eine GUI ähnlich wie VS Code (die meisten basieren auf VS Code).
  • Beispiele: Antigravity, Cursor, Kiro Code, Windsurf

• Prompt-to-App-Builder: Low-Code/No-Code-Plattformen zum Erstellen von Apps mit natürlichen Sprach-Prompts und visuellen Workflows.
  • Beispiele: Bolt, Lovable, v0.dev, Firebase Studio, Dazl

KI-Code-Review-Tools

Da KI-generierter Code immer häufiger wird, sind Code-Review-Tools unerlässlich, um Bugs und Schwachstellen zu erkennen. Wir haben die besten Tools anhand von 309 PRs in unserem RevEval-Benchmark bewertet.

Was können agentic CLI-Tools?

Über Tools wie Codex, Junie, Kiro und Claude Code hinweg gehören zu den gemeinsamen Fähigkeiten:

• End-to-End-Code-Arbeit: Dateien erstellen und ändern, Bugs beheben, Code refaktorisieren und Tests oder Linter direkt vom Terminal aus ausführen.
• Agentic Workflows: Mehrschrittige Aufgaben wie Task-Chaining, Fehlerbehebung, Suche und iteratives Debugging ausführen.
• Git & Projektmanagement: Verlauf überprüfen, Merges auflösen, Branches verwalten und Commits oder Pull Requests erstellen.
• Command-Ausführung & Automatisierung: Shell-Befehle ausführen, Analysen automatisieren und natürliche Sprache in komplexe CLI-Operationen übersetzen.
• Tiefe Kontextverarbeitung: Auf vollständigen Repositories mit Kenntnis von Abhängigkeiten und Projektstruktur arbeiten.
• Modellflexibilität: Mehrere Cloud- und in einigen Fällen lokale Modelle unterstützen; einige Tools erlauben die Verwendung eines eigenen API-Keys oder die Wahl zwischen Tarifen.
• Sandboxed oder kontrollierter Zugriff: Modi von schreibgeschützt bis vollautomatisch anbieten, oft mit isolierten Umgebungen zur Sicherheit.

Methodik

A-CODE-CLI Benchmark

Wir haben Agenten in einem One-Shot-Ausführungs-Setup bewertet, um die autonome Fähigkeit ohne menschliches Eingreifen zu messen. Die Agenten wurden dann mithilfe von Backend- und Frontend-Smoke-Tests bewertet, um die Infrastrukturbereitschaft und Verhaltenskorrektheit zu messen.

Modellkonfiguration. Alle 11 Agenten liefen auf Claude Sonnet 4.6 (nicht-reasoning). Zwei Agenten benötigten einen Proxy, um dieses Modell zu erreichen:

• Codex (OpenAI CLI) kann nativ nicht auf Anthropic-Modelle verweisen. Es wurde über ein LiteLLM-Gateway zu OpenRouter/Anthropic geleitet, mit einem Cache-Shim, der Prompt-Caching wiederherstellt. Der Proxy entfernt Reasoning-Tokens (Fähigkeitskosten) und fügt Latenz hinzu.
• Gemini CLI kann nativ keine Anthropic-Modelle aufrufen. Es wurde über einen SSE-Shim und ein LiteLLM-Gateway geleitet. Seine Hilfsmodell-Aufrufe (Schleifenerkennung, Reparatur fehlerhafter Tools, Kontextkomprimierung) schlagen fehl oder geben über den Proxy ungültigen Inhalt zurück, sodass es ohne seine eigenen Sicherheitsnetze lief.

Forge benötigte einen separaten Proxy, um erweiterte Denkblöcke aus den Antworten zu entfernen, die Forge zwangsweise aktiviert und die 400-Fehler verursachen, wenn sie zurückgesendet werden. Alle anderen Agenten verwendeten Sonnet 4.6 direkt über ihre native Provider-Konfiguration oder OpenRouter.

Der Proxy kann Codex und Gemini-CLI nur behindern, niemals aufblähen. Ihre Punktzahlen sind konservativ.

Junie betreibt parallel einen nicht überschreibbaren GPT-4.1-Mini-Helfer neben dem primären Sonnet 4.6. Es ist der einzige Agent mit einem zweiten aktiven Modell während des Builds. Seine Punktzahlen tragen ein Multi-Modell-Sternchen.

Claude Code lief über ein Benutzer-Abonnement (OAuth). Kiro lief auf Kiro-gehosteten Credits (Bedrock-unterstützt, 1,3x-Multiplikator).

Bei keinem Agenten wurden Temperatur-, Wiederholungs- oder Reasoning-Parameter angepasst. Jeder lief mit seiner Standardkonfiguration.

Bewertung. Backend: funktionaler Smoke (adaptive_avg_step_pass_rate). Frontend: UI-Smoke via Playwright. Kombiniert: 0,7 × Backend + 0,3 × Frontend (für Agenten mit vollständigen UI-Daten). Die Backend-Punktzahl ist die primäre Ranking-Achse. Die Frontend-Leistung sättigt sich im gesamten Feld.

Aider t-3 und t-4. Beide Aufgaben produzierten Backends, die beim Start abstürzten. Bestätigt über zwei frische Builds (gleiche Fehler: TypeError bei class Card in t-3, AmbiguousForeignKeysError bei User.auctions in t-4). Mit 0 bewertet und einer backend_never_ready-Kennzeichnung, nicht ausgeschlossen.

Zur Evaluierungsmethodik besuchen Sie: KI-Coding-Benchmark-Methodik

CLI-Versionen (Benchmark-Durchlauf Juni 2026)

Versionen, ausgelesen von den Benchmark-VPS-Boxen. Der Build-Durchlauf wurde vom 5. bis 8. Juni 2026 ausgeführt.

• Claude Code: 2.1.165
• Cline: 3.0.27
• Codex: 0.140.0
• Aider: 0.86.2
• Gemini CLI: 0.26.0
• Forge: 2.13.11
• Goose: 1.37.0
• Grok: 0.2.54
• Junie: 26.06.01 (Build 1831.35)
• Kiro CLI: 2.6.1
• Opencode: 1.17.7

Methodik der Web-Recherche-Grounding

Zwei Prüfungen: ein Unity-Migrations-Audit (Prüfung 2) und ein Next.js/React-Versions-Audit (Prüfung 3). Jede forderte den Agenten auf, Version, Status und Zeitplan für bestimmte Framework-Features zu berichten und eine offizielle URL pro Behauptung zu zitieren.

Die Bewertung verwendete zwei parallele Methoden. Ground-Truth-Gating: Eine Behauptung zählt nur, wenn die zitierte URL im echten Abrufprotokoll des Agenten erscheint UND die abgerufene Seite den Fakt enthält, gemessen an einem verifizierten Antwortschlüssel. Verhaltensklassifikation: Ein LLM-Richter las das vollständige Transkript jedes Agenten und ordnete ihn einer der vier Verhaltenskategorien zu. Die Verhaltensklassifikation ist das primäre Ergebnis; die bewerteten Genauigkeitstabellen werden veröffentlicht, sobald der Antwortschlüssel seine menschliche Ankerprüfung abgeschlossen hat.

Agenten mit integrierter Suche (Codex, Gemini, Grok) liefen auf ihren nativen Modellen, da die Aufgabe ihre integrierte Suchfunktion erfordert. Die übrigen acht liefen auf Claude Sonnet 4.6. N=1.

Methodik der Kontext-Komprimierung

Agenten erhielten ungefähr 112.000 Tokens an Fülldokumenten, die 13 erfundene Infrastruktur-Fakten enthielten. Nachdem der Agent die Dokumente gelesen und seinen Kontext komprimiert hatte, löschten wir die Quelldateien, bevor wir Fragen stellten. Bewertung: exakte Übereinstimmung mit 13 erfundenen Werten, automatisiert durch ein Bewertungsskript mit einem Regex pro Fakt. N=3.

Agenten, die 13/13 mit vorhandenen Dateien und 0/13 mit gelöschten Dateien erzielten, werden als Wiederleser klassifiziert. Agenten, die 13/13 mit gelöschten Dateien erzielten, werden als echte Behalter klassifiziert. Die Dateilöschung schließt Wiederlesen aus; erfundene Fakten schließen Trainingsdaten-Erinnerung aus.

Alle Agenten außer Codex (GPT-5.5) und Gemini (Gemini 2.5 Pro) liefen auf Sonnet 4.6. Das verwendete Modell pro Agent ist in der Ergebnistabelle aufgeführt.

Weiterlesen

Für diejenigen, die das breitere Ökosystem agentic Entwickler-Tools erkunden, hier unsere aktuellsten Benchmarks:

• MCP-Benchmark: Ein Vergleich der besten MCP-Server für Webzugriff.
• Remote-Browser: Wie aufstrebende Browser-Infrastruktur KI-Agenten ermöglicht, sicher mit dem Web zu interagieren.

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-CLI Bench: Agentic CLI Benchmark}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/agentic-cli}},
  note   = {AIMultiple. Abgerufen am 29. Juni 2026}
}

Referenzlinks

1.

Integration with Codex CLI | OpenRouter | OpenRouter | Documentation

OpenRouter | Documentation

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