A-CODE-CLI Bench: Agentischer CLI-Benchmark

Agentische CLI-Tools sind KI-Codierungstools, 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 pro Agent etwa 600 atomare Validierungsprüfungen durchgeführt wurden und insgesamt mehr als 5.000 automatisierte Testausführungen stattfanden, einschließlich Backend-Logik, Frontend-Funktionalität und Konsistenzprüfungen über mehrere Durchläufe.

Ergebnisse des agentischen CLI-Benchmarks

Leistungserkenntnisse der agentischen CLI-Tools

Die Backend-Korrektheit bestimmt die Rangfolge; der kombinierte Score gewichtet sie mit 0.7 und das Frontend mit 0.3.

• Alle neun fehlerfrei laufenden Agenten nutzen dasselbe Sonnet 4.6, doch das Backend reicht von Opencodes 77.3% bis zu Gooses 55.4%. Diese 22-Punkte-Differenz stammt vollständig aus der Orchestrierung.
• Ein starkes Backend garantiert keinen starken Abschluss: Cline (4th im Backend, 69.5%) und Forge (5th, 67.2%) rangieren im Backend ganz oben, fallen aber beim Frontend stark ab, Clines 52.5% ist der schwächste Wert im Feld, sodass beide in der kombinierten Tabelle zurückfallen.
• Codex rangiert 10th im Backend (52.1%) trotz eines perfekten 100%-Frontends. Hier läuft es über einen Proxy, um das gemeinsame Modell zu erreichen, was seine Fähigkeiten beeinträchtigen kann, daher ist dies wahrscheinlich eine Untergrenze und nicht das tatsächliche Backend des Agenten.¹ Gemini, ebenfalls über einen Proxy ausgeführt, ist auf dieselbe Weise eingeschränkt.
• Der Build-Rang sagt das Verhalten nicht voraus: Der Agent, der hier führt, behält nach der Kompaktierung nichts, während ein Agent aus dem Mittelfeld alles behält.

Geschwindigkeit, Token-Nutzung und Kosten im Vergleich zum Score

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über dem kombinierten Genauigkeitsscore aufgetragen:

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

• Opencode gewinnt bei allen drei gleichzeitig: höchster kombinierter Score (81.6%), die niedrigsten Kosten aller leistungsfähigen Agenten (1.03 $ pro Aufgabe), unter den wenigsten Token und den schnellsten Durchläufen. Es kehrt den üblichen Zielkonflikt zwischen Genauigkeit und Kosten um.
• Die Kosten erstrecken sich etwa über den Faktor 40, von Forge mit 0.18 $ bis zu Junie mit 7.58 $, ohne Bezug zum Rang. Forge ist am billigsten, weil es am wenigsten tut: sein Backend scheitert an der Ticket-Erstellung. Junies 7.58 $ erkaufen einen Mittelfeldwert von 74.7% und stellen eine überhöhte Obergrenze dar.
• Goose bezahlt am meisten für das Geringste: zweitteuerstes mit 3.23 $, aber der niedrigste saubere Score des Feldes (62.5%). Die ersten drei im Score 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. Mehr Ausgaben kaufen Wiederholungen und erneute Validierung, keine Problemlösungstiefe.
• Die Token-Zahlen drehen sich hauptsächlich um Caching. Codex, Claude Code, Cline, Opencode, Gemini und Grok cachen 86–98% ihres Inputs, daher reduzieren sich die 4.18M Brutto-Token von Claude Code auf effektiv 115k. Junie, Goose, Kiro, Forge und Aider cachen nicht, also bezahlen sie für jeden erneut gesendeten Token; deshalb ist Junies 2.36M der höchste im Feld.
• Drei Vorbehalte zu den Zahlen: Für die fünf nicht-cachenden Agenten ist der effektive Input alles, was sie gesendet haben, also betrachte ihn als Obergrenze; Kiros 1.72 $ ist eine Untergrenze (Kreditabrechnung, eher 2.23 $); Clines 64.4% umfassen vier Aufgaben, bei denen das Fehlerlimit erreicht wurde, bevor ein Frontend geliefert wurde, jede mit 0 bewertet.

Unsere Methodik finden Sie unten.

Wie agentische CLI-Tools funktionieren

Agentische CLI-Tools sind autonome Agenten, die im Terminal arbeiten. Während die meisten Nutzer sie für Codierungsaufgaben einsetzen, können sie jeden Arbeitsablauf ausführen, der über Shell-Befehle durchgeführt werden kann.

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

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

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

Die Schleife wird von zwei Quellen beeinflusst:

• Der menschliche Benutzer, der die initiale Aufgabe stellt und die Ausführung unterbrechen kann
• Das Modell, das Planung, logisches Denken und Aktionsauswahl durchführt

Das Agenten-Framework strukturiert das Modell. Es legt fest, wie das Modell planen, wann es Befehle ausführen, wie es Ergebnisse validieren soll und welche Werkzeuge verfügbar sind. Diese Werkzeuge können Shell-Ausführung, Dateisystemzugriff, Browser-Steuerung, Computer-Nutzung, MCP-Integrationen oder wiederverwendbare „Skills“ umfassen.

Verschiedene Agentenarchitekturen erzwingen unterschiedliche Planungsstrategien, Wiederholungsrichtlinien und Verifikationslogik. Einige Agenten priorisieren Präzision und tiefgründigeres logisches Denken auf Kosten höherer Token-Nutzung und Latenz. Andere priorisieren Geschwindigkeit und niedrigere Kosten mit reduzierter Verhaltensrobustheit.

Modellintelligenz vs. Agentenarchitektur

Leistungsunterschiede zwischen agentischen CLI-Tools haben keine einzelne Ursache. Sie entstehen aus zwei Schichten: dem Basismodell und dem Orchestrierungs-Framework, das es umgibt.

Dieser Benchmark testet beide Agenten mit demselben Basismodell: Claude Sonnet 4.6. Jeder Unterschied im Score ist daher ein Unterschied in der Orchestrierung: wie das CLI Kontext sammelt, wann es Befehle ausführt, wie es die Ausgabe validiert und ob es nach Fehlern erneut versucht.

Opencode und Claude Code verwenden beide direkt Sonnet 4.6. Opencode erreicht 77.3% im Backend; Claude Code erreicht 74.9%. Zwei Agenten, gleiches Modell, 2.4 Prozentpunkte Unterschied in der Backend-Korrektheit. Kiro und Opencode nutzen beide Sonnet 4.6. Kiro erreicht 64.2% im Backend; Opencode erreicht 77.3%. Die 13-Punkte-Lücke ist der Beitrag des CLI.

Die beiden folgenden Observatoriums-Benchmarks treiben dies weiter. Sie führen denselben Test mit gemeinsamem Modell für Web-Recherche und Kontextkompaktierung durch, bei dem die Lücken nicht 13 Punkte betragen, sondern der Unterschied zwischen der richtigen Antwort und dem Erfinden einer falschen.

Web-Recherche-Grounding

Wir haben jeden Agenten gebeten, die Dokumentation eines Frameworks zu prüfen: welche Version eine Funktion eingeführt hat, welchen aktuellen Status sie hat und was sich kürzlich geändert hat. Jede Antwort musste eine offizielle Quelle zitieren. Wir haben die Untersuchung zweimal durchgeführt, einmal für Unity und einmal für Next.js/React. Die Fakten wurden so ausgewählt, dass die korrekte Antwort nur auf einer aktuellen, veröffentlichten Seite existiert. Antworten aus Trainingsdaten führen zu selbstbewussten, aber falschen Antworten. Wir haben nur eines geprüft: Hat der Agent tatsächlich die von ihm zitierte Seite abgerufen?

Vier Agenten haben integrierte Websuche. Drei von ihnen (Codex, Gemini, Grok) liefen auf ihren nicht-Sonnet nativen Modellen; die anderen acht, einschließlich Claude Code, liefen auf Sonnet 4.6.

Vier Muster zeigten sich.

• 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, in dem die schwierigsten Fakten liegen.
• Sucht, landet aber auf alten Seiten Cline hat zwei Dutzend echte Dokumentationsseiten abgerufen und meldete dennoch eine Version, die ersetzt worden war. Die Abrufe waren echt; die Seiten waren veraltet.
• Keine Suche, Antworten aus dem Training Aider surft nicht und sagt das auch. Das ist die ehrliche Antwort.
• Fabricierte Quellen Forge hat nichts Funktionierendes abgerufen, zitierte jedoch 31 Quellen bei der Next.js-Untersuchung. Die zitierten Seiten existieren nicht. Seine Schlussbemerkung: „jede Zelle stammt von einer während dieser Sitzung tatsächlich abgerufenen Seite.“

Bei der Next.js-Untersuchung haben alle anderen surfenden Agenten fast alle ihre Zitate auf tatsächlich abgerufene Seiten gestützt. Forge stützte keine. Das Diagramm stapelt die belegten Zitate jedes Agenten gegen seine fabricierten, sodass die ehrlichen Agenten als vollständig grüne Balken und Forge als einzelner roter erscheinen. Das Diagramm umfasst die acht Agenten mit einem überprüfbaren Abruf-Protokoll pro URL. Grok (serverseitige Suche), Gemini (abgebrochener Lauf) und Aider (keine Zitate) erscheinen in der obigen Tabelle, sind aber hier 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 nicht. Gleiches Modell, unterschiedliches Ergebnis.

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

Kontextkompaktierung

Wenn eine Sitzung lang wird, kompaktiert 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 haben jedem Agenten etwa 112.000 Token an Dokumenten mit 13 eingebetteten erfundenen Fakten gegeben: eine Bereitschafts-PIN, eine Cloud-Region, ein Build-Tag und zehn weitere. Erfunden bedeutet, dass die Werte eindeutige Zeichenfolgen sind, die in den Trainingsdaten nicht vorkommen. Der Agent las die Dokumente und kompaktierte. Anschließend haben wir die Quelldateien gelöscht und nach allen 13 Fakten gefragt. Da die Dateien gelöscht sind, ist die einzige mögliche Quelle die Kompaktierungszusammenfassung.

Vier Agenten behielten alle Fakten. Drei behielten keine. Die drei, die aus dem Gedächtnis 0 erzielten, hatten noch alle 13 von 13 beantwortet, als sie die Dateien noch erneut lesen konnten. Sie lasen bei jeder Abfrage 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, gegensätzliches Ergebnis.

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

Vier Agenten fielen aus dem Rahmen dieses Tests, jeder aus einem konkreten Grund. Cline konnte nicht an seine Kompaktierungsschwelle herangeführt werden. Wir erstellten einen 863.000-Token-Dokumentensatz und ließen es jede Datei lesen, aber Cline kürzt jede Tool-Ausgabe auf etwa 2.000 Zeichen, sodass die Dokumente zu kurzen Vorschauen schrumpften. Sein Kontext erreichte ein Plateau bei 214.000 Token, 21% seines Eine-Million-Token-Fensters, und die Kompaktierung wurde nie ausgelöst. Wir berichten Cline als unter diesem Protokoll nicht messbar, anstatt eine Zahl zu schätzen. Grok hat einen Kompaktierungsbefehl, aber es las unsere Dokumente in Fragmenten statt sie vollständig zu laden, sodass nie ein vollständiger Kontext zum Kompaktieren vorhanden war. Aiders Zusammenfasser komprimiert Chat-Züge, nicht den Inhalt der zur Sitzung hinzugefügten Dateien, wo die Fakten lebten. Junie hat keine Kompaktierungsfunktion.

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

Agentenverhalten bei Aufgabe 6

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

Aufgabe 6: Helpdesk-Ticketsystem (Web)

Aufgabe 6 erforderte den Bau eines Full-Stack-Helpdesk-Ticketsystems mit:

• Zwei Benutzerrollen (Kunde und Agent)
• JWT-basierter Authentifizierung
• Strikte Status-Workflow-Übergänge
• Datenisolation (404 statt 403 bei zugriffsübergreifendem Zugriff)
• FastAPI-Backend
• React/Vue/Svelte + Vite-Frontend
• Deterministische Ausführungsbefehle

Der Smoke-Test validierte:

• Health Check
• Dual-Role-Authentifizierung
• Ticket-CRUD-Operationen
• Zuweisung und Antworten
• Statusübergänge
• Rollenerzwingung
• Datenisolation
• UI-Login und Verhalten nach dem Login

Diese Aufgabe beansprucht Zustandsverwaltung, Auth-Korrektheit, REST-Contract-Disziplin und Frontend-Backend-Integration. Besuchen Sie GitHub, um die Aufgabendetails zu sehen.

Auf einem Modell spaltete sich das Feld in drei Gruppen.

• 60% Backend, sieben Agenten (codex, claude-code, cline, grok, goose, junie, opencode): identische sechs fehlgeschlagene Schritte über alle drei Wiederholungen. Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden; beide Fehlschläge lagen bei /tickets/{id}/assign und /tickets/{id}/status, wo sie ein einheitliches PATCH /tickets/{id} anstelle der separaten Routen der Spezifikation bauten. Geschäftslogik korrekt, REST-Contract falsch. Im vorherigen nativen Lauf auf Gemini 3 Pro baute Opencode die separaten Endpunkte und erreichte 93.3%; auf 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, kein einzelner Fehlermodus. Es bestand neun Schritte in Lauf eins, zwei in Lauf zwei, und in Lauf drei startete das Backend nie (Health Check fehlgeschlagen). Die anderen zehn Agenten wiederholten sich identisch bei jeder Wiederholung.
• UI innerhalb des 60%-Clusters: claude-code und cline scheiterten am Login mit einem identischen CORS-Bug, das Frontend rief das Backend auf localhost:8000 von einem 127.0.0.1-Origin aus auf, und der Browser blockierte es, daher erzielten beide 75%; die anderen fünf renderten und loggten sich sauber ein mit 100%.
• Das Fazit ist Konvergenz: sieben verschiedene CLIs auf demselben Modell machten denselben REST-Contract-Fehler, also dominiert hier das Modell und die Orchestrierung spielt kaum eine Rolle, das Gegenteil der Observatoriums-Benchmarks unten.

Codex

Installation

Global installieren mit:

• npm install -g @openai/codex

Alternativ global mit Homebrew (macOS/Linux) installieren

• brew install –cask codex

Authentifizierung

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

Task-Bericht

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

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge, die auf `/tickets/{id}/assign` und `/tickets/{id}/status` abzielten. Codex leitete beide über einen einheitlichen Update-Endpunkt, 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 JetBrains Toolbox oder als eigenständiges 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 unter junie.jetbrains.com/cli, oder exportieren Sie Ihren eigenen API-Schlüssel von Anthropic, OpenAI, Google oder anderen unterstützten Providern. Mehrere Provider-Optionen verfügbar.

Task-Bericht

Junie erstellte in 444 Sekunden ein vollständiges Full-Stack-System und erreichte 60% Backend, im Hauptcluster. Sein effektiver Input bei dieser Aufgabe ist mit 1.52M der höchste im Feld, eine ungecachte Obergrenze, die durch einen bekannten Caching-Abrechnungsfehler beeinflusst wird (siehe Anmerkung in der Ergebnistabelle).

Backend-Verhalten

Neun von sechzehn Schritten bestanden: Authentifizierung, Ticket-CRUD, Antworten und Datenisolation. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge. Junie behandelte Status und Zuweisung über einen einheitlichen Update-Endpunkt, sodass die Routen `/tickets/{id}/assign` und `/tickets/{id}/status` 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.

Task-Bericht

Kiro ist der eine Agent, dessen Score eher Instabilität als eine einzelne Designentscheidung widerspiegelt. Sein 24.4% Backend ist ein Durchschnitt über drei Wiederholungen, die drei unterschiedliche Ergebnisse lieferten. Der Build selbst war solide, wenn er lief; das Problem war, dass er nicht zweimal gleich lief.

Backend-Verhalten

Im ersten Lauf bestand Kiro neun von sechzehn Schritten, dasselbe Profil wie der 60%-Cluster, und scheiterte nur an den Zuweisungs- und Statusrouten. Im zweiten Lauf bestand es zwei. Im dritten kam das Backend nie hoch und selbst der Health Check schlug fehl. Gemittelt ergibt dies 24.4%. Die Instabilität, nicht das Endpunkt-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 Lauf, bei dem das Login-Formular nicht gerendert wurde aufgrund eines 422 beim Mounten.

Claude Code

Installation

Für macOS/Linux/WSL, je nach bevorzugtem Paketmanager, können Sie Claude Code 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.

Task-Bericht

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

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge, die über einen einheitlichen Update-Endpunkt statt 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-Origin ausgeliefert wurde, und der Browser blockierte die Login-Anfrage aufgrund der CORS-Policy. 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 aider zuerst:

• 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-Schlüssel in Ihrer Umgebung mit:

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

Task-Bericht

Aider war mit 236 Sekunden der schnellste Agent und der sparsamste, mit 1.3k Input- und 18k Output-Token. Es erreichte außerdem 13.3% Backend. Die 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 Ticket-Listen für Kunde und Agent, Antworten, Zuweisung, Statusübergänge und Rollenprüfungen alle kaskadierten Ausfälle waren. 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 fehl mit derselben CORS-Origin-Mismatch wie bei claude-code und cline. 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

Task-Bericht

Opencode führt den Gesamt-Benchmark an, aber in Aufgabe 6 erreichte es 60% Backend, im Hauptcluster, in 542 Sekunden. Dies ist der klarste einzelne Modellbeweis im Artikel. Im vorherigen nativen Modelllauf auf Gemini 3 Pro Preview baute Opencode die separaten Endpunkte der Spezifikation und erreichte hier 93.3%. Dasselbe CLI auf Sonnet 4.6 wählte den einheitlichen Endpunkt 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 waren die Schritte für Zuweisung und Statusübergänge, die über einen einheitlichen Update-Endpunkt 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-Schlüssel für die headless-Nutzung:

• export XAI_API_KEY=”xai-…”

Task-Bericht

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

Backend-Verhalten

Neun von sechzehn Schritten bestanden: Authentifizierung, Ticket-CRUD, Antworten und Datenisolation. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge, die auf /tickets/{id}/assign und /tickets/{id}/status abzielten. Grok leitete beide über einen einheitlichen Update-Endpunkt, 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-Anmeldeinformationen interaktiv mit:

• forge provider login

Und wählen Sie Ihren Provider.

Task-Bericht

Forge erreichte 13.3% Backend in 844 Sekunden. Seine Output-Token-Zahl ist mit 1.6k die niedrigste im Feld, was auf eine oberflächliche Implementierung hindeutet. Wie im vorherigen Lauf brach der Build bei der Ticket-Erstellung ab und kaskadierte.

Backend-Verhalten

Zwei Schritte bestanden. Die Ticket-Erstellung schlug fehl, sodass Ticket-Listen, Antworten, Zuweisung, Statusübergänge und Rollenprüfungen alle mit scheiterten. Stabil über alle drei Wiederholungen, dasselbe 13.3%-Profil wie aider und gemini-cli.

UI-Verhalten

Der Login-Schritt schlug fehl mit derselben CORS-Origin-Mismatch wie bei claude-code, cline und aider. 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-Schlüssel): export GEMINI_API_KEY=”YOUR_API_KEY” dann gemini starten.
Option 3 (Vertex KI): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Task-Bericht

Gemini CLI erreichte 13.3% Backend in 926 Sekunden, einer der beiden langsamsten Agenten im Feld. Die Authentifizierung funktionierte, aber die Ticket-Erstellung schlug fehl und kaskadierte. Sein Frontend, das im vorherigen Lauf aufgrund einer Inkompatibilität von Node 18 mit Vite 7 vollständig versagte, bestand diesmal jeden Schritt.

Backend-Verhalten

Zwei Schritte bestanden. Die Ticket-Erstellung schlug fehl, sodass alle abhängigen Schritte scheiterten. Stabil über alle drei Wiederholungen, dasselbe 13.3%-Profil wie aider und forge.

UI-Verhalten

Frontend bestand alle acht Validierungsschritte. 100% UI, gegenüber 0% im vorherigen Lauf. 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

Indem Sie `cline auth` ausführen, können Sie Ihr Cline-Konto auswählen oder mit Ihrem gewünschten Provider fortfahren.

Task-Bericht

Cline erreichte 60% Backend in 648 Sekunden, im Hauptcluster. Dies ist eine große Veränderung gegenüber dem vorherigen Lauf, bei dem sein Acht-Fehler-Limit den Build vorzeitig beendete und ein leeres Frontend hinterließ. Hier stellte es den gesamten Stack fertig.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge, die über einen einheitlichen Update-Endpunkt geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

Der Login-Schritt schlug fehl mit derselben CORS-Origin-Mismatch wie bei claude-code, auf 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

Task-Bericht

Goose erreichte 60% Backend in 553 Sekunden, im Hauptcluster, verbrauchte jedoch 1.06M Input-Token, um dorthin zu gelangen. Es stellte diesmal den gesamten Stack fertig, eine Änderung gegenüber dem vorherigen Lauf, bei dem das Frontend-Verzeichnis leer blieb.

Backend-Verhalten

Authentifizierung, Ticket-CRUD, Antworten und Datenisolation bestanden. Die sechs Fehlschläge waren die Schritte für Zuweisung und Statusübergänge, die über einen einheitlichen Update-Endpunkt geleitet wurden. Stabil über alle drei Wiederholungen.

UI-Verhalten

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

KI-Codierungstools

KI-Codierungstools lassen sich in drei Kategorien einteilen:

• Agentische CLI: Tools für terminalbasierte Entwicklungsworkflows, die Code durch Prompts und Befehlszeileninteraktionen generieren, bearbeiten und refaktorisieren.
  • Beispiele: Aider, Junie, Opencode, Claude Code, Codex

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

• Prompt-to-App-Builder: Low-Code/No-Code-Plattformen, um Apps mit natürlichsprachlichen Prompts und visuellen Workflows zu erstellen.
  • 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 Fehler und Schwachstellen zu erkennen. Wir haben die führenden Tools anhand von 309 PRs in unserem RevEval-Benchmark bewertet.

Was können agentische CLI-Tools leisten?

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

• End-to-End-Codearbeit: Dateien erstellen und ändern, Fehler beheben, Code refaktorisieren und Tests oder Linter direkt vom Terminal aus ausführen.
• Agentische Workflows: Mehrschrittige Aufgaben wie Task-Verkettung, Fehlerbehebung, Suche und iterative Debugging durchfü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.
• Tiefes Kontexthandling: Mit Bewusstsein für Abhängigkeiten und Projektstruktur auf ganzen Repositories operieren.
• Modellflexibilität: Unterstützung mehrerer Cloud- und in einigen Fällen lokaler Modelle; einige Tools erlauben die Verwendung eines eigenen API-Schlüssels oder die Wahl zwischen Plänen.
• Sandbox- oder kontrollierter Zugriff: Bieten Modi von schreibgeschützt bis hin zur vollständigen Automatisierung, oft mit isolierten Umgebungen zur Sicherheit.

Methodik

A-CODE-CLI-Benchmark

Wir haben Agenten unter einem One-Shot-Ausführungs-Setup evaluiert, um die autonome Fähigkeit ohne menschliches Eingreifen zu messen. Anschließend wurden die Agenten mit Backend- und Frontend-Smoke-Tests auf Infrastrukturbereitschaft und Verhaltenskorrektheit geprüft.

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 nicht nativ auf Anthropic-Modelle verweisen. Es wurde über ein LiteLLM-Gateway zu OpenRouter/Anthropic geleitet, mit einem Cache-Shim, der das Prompt-Caching wiederherstellt. Der Proxy entfernt Reasoning-Token (Fähigkeitseinbuße) und fügt Latenz hinzu.
• Gemini CLI kann Anthropic-Modelle nicht nativ aufrufen. Es wurde über einen SSE-Shim und ein LiteLLM-Gateway geleitet. Seine Hilfsmodellaufrufe (Schleifenerkennung, Reparatur fehlerhafter Werkzeuge, Kontextkomprimierung) schlagen über den Proxy fehl oder geben ungültigen Inhalt zurück, sodass es ohne eigene Sicherheitsnetze lief.

Forge benötigte einen separaten Proxy, um erweiterte Thinking-Blöcke aus den Antworten zu entfernen, die Forge zwangsweise aktiviert und die beim Zurücksenden 400-Fehler verursachen. Alle anderen Agenten nutzten Sonnet 4.6 direkt über ihre native Provider-Konfiguration oder OpenRouter.

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

Junie betreibt neben Sonnet 4.6 als primärem Modell einen nicht überschreibbaren GPT-4.1-mini-Helfer. Es ist der einzige Agent mit einem zweiten Modell, das während des Builds aktiv ist. Seine Scores tragen einen Multimodell-Vermerk.

Claude Code lief über ein Nutzerabonnement (OAuth). Kiro lief auf von Kiro gehosteten Credits (Bedrock-unterstützt, 1.3x-Multiplikator).

Kein Agent hatte optimierte Temperatur-, Wiederholungs- oder Reasoning-Parameter. 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). Der Backend-Score ist die primäre Rangachse. Die Frontend-Leistung sättigt sich im Feld.

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

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

CLI-Versionen (Benchmark-Durchlauf Juni 2026)

Versionen von den Benchmark-VPS-Boxen ausgelesen. Der Build-Lauf wurde vom 5. bis 8. Juni 2026 durchgefü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 des Web-Recherche-Groundings

Zwei Untersuchungen: ein Unity-Migration-Audit (Untersuchung 2) und ein Next.js/React-Version-Audit (Untersuchung 3). Jede bat den Agenten, Version, Status und Zeitrahmen für bestimmte Framework-Funktionen zu melden 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 Abruf-Protokoll des Agenten erscheint UND die abgerufene Seite die Tatsache enthält, gemessen an einem verifizierten Antwortschlüssel. Verhaltensklassifizierung: Ein LLM-Judge las das gesamte Transkript jedes Agenten und ordnete ihn einer der vier Verhaltenskategorien zu. Die Verhaltensklassifizierung ist das primäre Ergebnis; die bewerteten Genauigkeitstabellen werden veröffentlicht, nachdem 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 Kontextkompaktierung

Die Agenten erhielten etwa 112.000 Token Fülldokumente, die 13 erfundene Infrastruktur-Fakten enthielten. Nachdem der Agent die Dokumente gelesen und seinen Kontext kompaktiert 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. Das Löschen der Dateien schließt Wiederlesen aus; erfundene Fakten schließen Abruf aus Trainingsdaten aus.

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

Weiterlesen

Für diejenigen, die das breitere Ökosystem agentischer Entwicklertools erkunden, hier unsere neuesten Benchmarks:

• MCP-Benchmark: Ein Vergleich der führenden MCP-Server für Webzugriff.
• Remote-Browser: Wie aufkommende Browser-Infrastruktur es 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{kaleliolu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-CLI Bench: Agentischer 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

Berk Kalelioğlu

KI-Forscher

Folgen aufVollstä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