Terminal-Agenten im Test: Grok CLI verbrennt 90.000 Tokens, bevor ein Fehler zugibt wird
Wer einem Terminal-Agenten die Aufgabe gibt, einen Test zu reparieren, stapelt bei jedem Schritt Suchergebnisse, Dateiausschnitte und stdout im Kontext. Schnell kommen so 90.000 Tokens zusammen, bevor das Modell überhaupt einen Fehler korrekt einräumt.
Veröffentlicht am 26. Okt. • Zuerst erschienen auf commoditech.pl
Gibt man einem Terminal-Agenten ein Repository und die Anweisung "behebe diesen Test", endet die Schleife nicht nach einem einzigen Modellaufruf. Jeder Schritt fügt ein Suchergebnis, ein Dateifenster und etwas stdout zum Kontext hinzu.
Man nehme ein Präfix von 2.000 Tokens (Anweisung, AGENTS.md, die Aufgabe), 1.000 Tokens neuer Beobachtung pro Schritt und keinen Präfix-Cache. Zwölf Schritte ergeben 90.000 Input-Tokens. Ein einziger Aufruf mit demselben Präfix und einer Beobachtung kostet 3.000. Das ist ein Verhältnis von 30. Die letzten drei Schritte kosten 36.000 Tokens, also 40 % der Rechnung; die ersten drei kosten 9.000, also 10 %.
Diese Rechnung kann man sich auf Papier noch einmal vorführen. Es handelt sich nicht um eine Rechnung aus einem konkreten Durchlauf. Aber genau so sieht die Rechnung aus, wenn niemand ein Schrittlimit gesetzt hat und die Schleife erst endet, wenn das Modell "fertig" sagt, statt wenn ein Test grün wird.
Das zweite Risiko wiegt schwerer als die Tokens. Ein Agent, der ein Issue, ein README oder ein Tool-Ergebnis liest, handelt auch mit allem, was dort von Dritten hinterlassen wurde, und hat eine Shell darunter. AgentDojo (Debenedetti et al., arXiv:2406.13352) umfasst 97 Aufgaben und 629 Sicherheitstestfälle. Modelle scheitern an einigen Aufgaben sogar, wenn nichts angreift, und eine in Tool-Ausgaben versteckte Prompt Injection verletzt bestimmte Sicherheitseigenschaften, während andere unangetastet bleiben.
Eine Leaderboard-Punktzahl mischt also drei Dinge: das Modell, das Scaffold und die Sauberkeit des Testsets. Die API-Rechnung ist die Summe eines wachsenden Kontexts. Kontrollieren kann man eine Stoppbedingung, die an einen Test gekoppelt ist, sowie eine Liste der Tools, die der Agent aufrufen darf. Der Name der Binärdatei auf dem $PATH gehört zu keinem davon.
Ein Terminal-Agent ist eine Schleife, kein Chat. Der Host verwaltet die Historie, ruft das Modell auf, führt eine Aktion aus und hängt die Beobachtung an. Grok CLI ist ein solcher Host. xAI dokumentiert es als Grok Build, der Befehl lautet grok (Dokumentation, Produktseite). Die Dokumentation beschreibt:
Die offizielle Installation ist ein curl … | bash Einzeiler; daneben gibt es ein npm-Paket, @xai-official/grok.
Die Flags, die für den Rest dieses Artikels am wichtigsten sind, sind die Steuerungsflags aus der CLI-Referenz:
# cap the loop, pick a sandbox profile, restrict tools, set permission rules grok -p "make tests/test_parser.py::test_dates pass" \ --max-turns 8 \ --sandbox <profile> \ --tools <allowed-tools> \ --deny <rule> Enter fullscreen mode Exit fullscreen mode --max-turns ist das eingebaute Schrittlimit aus der Rechnung oben. --sandbox, --tools / --disallowed-tools sowie --allow / --deny sind die Stellen, an denen entschieden wird, welches Tool schreiben darf. Das Flag, das man auf jedem Rechner vermeiden sollte, der Produktivumgebungen erreichen kann, ist --always-approve, Alias --yolo. (Die Platzhalter oben sind bewusst gewählt; die tatsächliche Syntax für Profile und Regeln findet sich auf den Seiten zu Sandbox und Permissions.)
Keines davon ist eine Resolve Rate. Stand Oktober 2026 verknüpft xAIs öffentliche Dokumentation keinen SWE-bench-Score mit der grok-Binärdatei. Wird eine gemessen, gehört sie zu einem konkreten Modell, Schrittlimit und Harness.
MCP trennt den Host von seinen Tools. Die Spezifikation (Revision 2025-11-25) baut auf JSON-RPC 2.0 auf. Der Host (Grok CLI oder ein anderer Client) hält die Clientseite. Ein Server stellt Tools (Funktionen, die das Modell aufrufen darf), Ressourcen (lesbare Daten) und Prompts (Vorlagen) bereit. Der Lebenszyklus sieht so aus: initialize verhandelt die Fähigkeiten, tools/list liefert die Schemas, und tools/call führt ein Tool aus. Auf der Clientseite definiert die Spezifikation zudem sampling (der Server bittet den Host, ein Modell aufzurufen) und roots (die Verzeichnisse, die der Server sehen darf).
Der lokale Transport ist stdio: ein Prozess auf derselben Maschine ohne Port. Der entfernte Transport, eingeführt in Revision 2025-03-26 und beibehalten in 2025-11-25, ist Streamable HTTP; das ältere HTTP+SSE-Verfahren ist nicht mehr die bevorzugte Remote-Option. Ein MCP-Server kann mehrere Hosts bedienen, aber das klärt nicht, welches Tool schreiben darf. In Grok CLI werden Server mit grok mcp list|add|remove|doctor verwaltet.
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_issue", "arguments": { "key": "PAY-1842" } } } Enter fullscreen mode Exit fullscreen mode Die Nachrichtenform stammt aus der MCP-Tools-Spezifikation. get_issue ist ein fiktives, nur lesendes Tool, kein eingebautes Grok-CLI-Tool.
step = 0 context = [ system, AGENTS_md, task ] while step < LIMIT and not target_test_green (): action = model ( context ) if action. kind == " mcp ": result = server. tools_call ( action. name, action. arguments ) elif action. kind == " shell ": result = sandbox ( action. command ) # network,.env and git push live here context. append ( truncate ( action, result )) step += 1 Enter fullscreen mode Exit fullscreen mode Die Schnittstelle hat Gewicht, selbst wenn das Modell gleich bleibt. SWE-agent (Yang et al., arXiv:2405.15793, NeurIPS 2024) lieferte GPT-4 Turbo auf SWE-bench Lite:
Ein cat über eine ganze Datei flutet den Kontext mit Text, den das Modell für den Patch nie verwendet.
Auf dem vollen SWE-bench löste derselbe Aufbau 12,47 % (286 von 2.294) bei durchschnittlich 1,59 $ pro Instanz zu den Preisen des Papiers. Die 87,7 % im Abstract des Papiers stammen aus HumanEvalFix, einem Satz kurzer Funktionsreparaturen, nicht aus den 2.294 GitHub-Issues.
SWE-bench (Jimenez et al., arXiv:2310.06770, ICLR 2024) umfasst 2.294 Probleme aus 12 Python-Repositories. Das beste Modell jenes Papiers, Claude 2, löste 1,96 % ohne Tool-Schleife. Wer 1,96 % neben 12,47 % stellt, vermischt Modell, Jahr und Scaffold. Die Ablation, die das Modell festhält und nur die Schnittstelle ändert, liegt bei 11,00 % gegen 18,00 % auf Lite: sieben Punkte auf 300 Aufgaben. Das genügt, um rohes bash nicht länger als neutrale API für ein Modell zu behandeln. Es genügt nicht, um "der Agent löst Issues" in einen Vorschlag zu schreiben.
SWE-bench Verified (OpenAI, 13. Aug. 2024): Annotatoren prüften 1.699 Aufgaben, 500 blieben erhalten. 196 davon sind "einfach" (unter 15 Minuten) und 45 "schwer" (über eine Stunde). GPT-4o löste 33,2 %. In der Annotation hatten 38,3 % der Samples eine unzureichend spezifizierte Aufgabenstellung, 61,1 % Tests, die eine gültige Lösung durchfallen lassen konnten, und insgesamt wurden 68,3 % aussortiert.
Verified im Ruhestand (OpenAI, 23. Feb. 2026): Die Frontier bewegte sich in sechs Monaten von 74,9 % auf 80,9 %. OpenAI auditierte 27,6 % des Sets und konzentrierte sich dabei auf Aufgaben, die Modelle häufig scheitern lassen. In mindestens 59,4 % der auditierten Probleme fanden sie wesentliche Mängel im Testdesign und/oder in der Problembeschreibung; Tests, die einen korrekten Patch ablehnen, bilden die größte Gruppe, sind aber nicht die einzige. Kontamination ist ein eigenes Problem. OpenAI stellte die Berichterstattung zu Verified ein und verwies auf SWE-bench Pro.
Pro ebenfalls infrage gestellt (OpenAI, 8. Jul. 2026): Auf dem öffentlichen Split von SWE-bench Pro (731 Aufgaben) stieg die Frontier-Passrate in acht Monaten von 23,3 % auf 80,3 %. Ein automatisierter Durchlauf markierte 200 Aufgaben (27,4 %) als fehlerhaft, eine manuelle Kampagne 249 (34,1 %). Im selben Beitrag schätzt OpenAI, dass rund 30 % von Pro fehlerhaft sind, und nimmt seine frühere Empfehlung zurück, auf Pro zu wechseln. Den Sprung und die Quote fehlerhafter Aufgaben sollte man zusammen lesen.
Herstellertabellen. In der GPT-5.2-Ankündigung erreicht GPT-5.2 Thinking 80,0 % auf Verified und 55,6 % auf Pro public. Diese Lücke von 24,4 Punkten zwischen zwei Sets für dasselbe Modell ist größer als die gesamte Shell-gegen-ACI-Ablation von 2024. Die GPT-5.4-Ankündigung berichtet 57,7 % auf Pro public und 75,1 % auf Terminal-Bench 2.0. Das sind drei Prozentpunkte und drei Definitionen von "kann programmieren". Dies sind Herstellerangaben, keine unabhängigen Messungen.
Entwicklerproduktivität. METRs randomisierte Studie (Becker et al., arXiv:2507.09089) begleitete 16 erfahrene Open-Source-Entwickler bei 246 Aufgaben von Februar bis Juni 2025:
In einem Update vom Februar 2026 teilt METR mit, dass eine Folgestudie mit neueren Tools ebenfalls keinen verlässlichen Befund in irgendeine Richtung lieferte. Die +19 % beschreiben das frühe Jahr 2025, nicht das Q4 2026.
Die Erkenntnis ist, dass die Schnittstelle die Punktzahl bewegt, selbst bei festen Modellgewichten. Die Wahrnehmung eines Teams kann das entgegengesetzte Vorzeichen zur Stoppuhr haben. Und eine Verified- oder Pro-Prozentzahl ohne Scaffold und ohne Test-Audit sagt nichts über den eigenen Sprint voraus.
Die Annahmen sind explizit gemacht, damit man seinen eigenen Token-Counter einsetzen kann:
Eine Kürzung, die trotzdem eine Prüfung an ihrem Platz lässt, sieht so aus:
Schlägt der Test bei Schritt 8 immer noch fehl, stoppt die Schleife. Man bekommt keinen Patch, aber eine begrenzte Rechnung und ein Diff zur Durchsicht.
METRs Ergebnis erklärt, warum Teams weiterhin sagen "es fühlt sich schneller an". Die Schranke ist daher keine Befragung nach der Sitzung. Es ist ein Test, den man kannte, bevor der Agent startete, dazu ein Token-Counter über die Sitzung.
Bedeutet 80 % auf SWE-bench Verified, dass der Agent 80 % der Tickets eines Senior Engineers abschließt? Nein. Die Punktzahl hängt vom Modell, dem Scaffold und der Sauberkeit des Benchmarks ab, und sowohl Verified als auch Pro wurden öffentlich von dem Hersteller infrage gestellt, der sie beworben hat. Gemessen wird der eigene Sprint durch die eigenen Tests.
Soll ein MCP-Server über stdio oder remote im Firmennetz laufen? Stdio startet einen Prozess neben dem Host und öffnet keinen Port, passt also zu einem Tool, das ohnehin nur dieses Verzeichnis lesen darf. Streamable HTTP gibt dem Server eine Adresse, was Authentifizierung und eine separate Liste schreibberechtigter Tools nötig macht. Lesezugriffe auf Issues und CI können remote laufen; eine vernetzte Shell und Produktiv-Schreibzugriffe erben diese Berechtigung nicht.
Kann ein Terminal-Agent in einem Repository unter Geheimhaltungspflicht arbeiten? Ja, wenn der API-Schlüssel, das Transkript und die Shell innerhalb deiner Vertrauensgrenze bleiben. Beim Exportieren einer Sitzung ( grok export ) werden die Diffs sowie alles, was die Schleife in den Kontext gezogen hat, kopiert, was auch ein Secret aus der.env-Datei enthalten kann.
Konrad Wojtasik ist der CEO von Commoditech, einem IT-Personaldienstleistungsunternehmen aus Warschau, das Software-, Daten- und AI-Ingenieure in Kundenteams vermittelt. Verwandt: LLM-Orchestrierung und Inferenzkosten.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 26 • Originally published at commoditech.pl
Give a terminal agent a repository and the instruction "fix this test", and the loop does not end after one model call. Every step appends a search result, a file window and some stdout to the context.
Take a 2,000-token prefix (instruction, AGENTS.md, the task), 1,000 tokens of new observation per step, and no prefix cache. Twelve steps send 90,000 input tokens. One call with the same prefix and one observation sends 3,000. That is a ratio of 30. The last three steps cost 36,000 tokens, 40% of the bill; the first three cost 9,000, or 10%.
You can redo that sum on paper. It is not an invoice from a named rollout. But it is what the invoice looks like when nobody set a step cap and the loop stops when the model says "done" instead of when a test goes green.
The second risk matters more than the tokens. An agent that reads an issue, a README or a tool result also acts on whatever a third party wrote there, and it has a shell underneath. AgentDojo (Debenedetti et al., arXiv:2406.13352 ) has 97 tasks and 629 security test cases. Models fail some tasks even when nothing is attacking them, and a prompt injection hidden in tool output breaks some security properties and leaves others intact.
So a leaderboard score combines three things: the model, the scaffold, and how clean the test set is. The API bill is the sum of a growing context. What you can control is a stop condition tied to a test, plus a list of tools the agent may call. The name of the binary on your $PATH is none of these.
A terminal agent is a loop, not a chat. The host keeps the history, calls the model, runs an action and appends the observation. Grok CLI is one such host. xAI documents it as Grok Build, and the command is grok ( docs, product page ). The docs describe:
The official install is a curl … | bash one-liner; there is also an npm package, @xai-official/grok.
The flags that matter most for the rest of this article are the control flags in the CLI reference:
# cap the loop, pick a sandbox profile, restrict tools, set permission rules grok -p "make tests/test_parser.py::test_dates pass" \ --max-turns 8 \ --sandbox <profile> \ --tools <allowed-tools> \ --deny <rule> Enter fullscreen mode Exit fullscreen mode --max-turns is the step cap from the arithmetic above, built in. --sandbox, --tools / --disallowed-tools and --allow / --deny are where "which tool may write" gets decided. The flag to avoid on any machine that can reach production is --always-approve, alias --yolo. (Placeholders above are deliberate; see the Sandbox and Permissions pages for the actual profile and rule syntax.)
None of this is a resolve rate. As of October 2026, xAI's public docs do not attach a SWE-bench score to the grok binary. If someone measures one, it belongs to a specific model, step cap and harness.
MCP separates the host from its tools. The specification (revision 2025-11-25) is built on JSON-RPC 2.0. The host (Grok CLI or another client) holds the client side. A server exposes tools (functions the model may call), resources (data to read) and prompts (templates). The lifecycle is: initialize negotiates capabilities, tools/list returns schemas, and tools/call runs one tool. On the client side, the spec also defines sampling (the server asks the host to call a model) and roots (the directories the server may see).
The local transport is stdio: a process on the same machine with no port. The remote transport, introduced in revision 2025-03-26 and kept in 2025-11-25, is Streamable HTTP; the older HTTP+SSE setup is no longer the main remote option. One MCP server can serve several hosts, but that does not settle which tool is allowed to write. In Grok CLI, servers are managed with grok mcp list|add|remove|doctor.
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_issue", "arguments": { "key": "PAY-1842" } } } Enter fullscreen mode Exit fullscreen mode The message shape comes from the MCP tools spec. get_issue is a made-up read-only tool, not a built-in Grok CLI tool.
step = 0 context = [ system, AGENTS_md, task ] while step < LIMIT and not target_test_green (): action = model ( context ) if action. kind == " mcp ": result = server. tools_call ( action. name, action. arguments ) elif action. kind == " shell ": result = sandbox ( action. command ) # network,.env and git push live here context. append ( truncate ( action, result )) step += 1 Enter fullscreen mode Exit fullscreen mode The interface matters even when the model stays the same. SWE-agent (Yang et al., arXiv:2405.15793, NeurIPS 2024) ran GPT-4 Turbo on SWE-bench Lite:
Running cat on a whole file floods the context with text the model never uses in the patch.
On the full SWE-bench, the same setup resolved 12.47% (286 of 2,294) at an average of $1.59 per instance at the paper's prices. The 87.7% in the paper's abstract is HumanEvalFix, a set of short function repairs, not the 2,294 GitHub issues.
SWE-bench (Jimenez et al., arXiv:2310.06770, ICLR 2024) has 2,294 problems from 12 Python repositories. The best model in that paper, Claude 2, resolved 1.96% with no tool loop. Putting 1.96% next to 12.47% mixes up the model, the year and the scaffold. The ablation that holds the model fixed and changes only the interface is 11.00% against 18.00% on Lite: seven points on 300 tasks. That is enough to stop treating raw bash as a neutral API for a model. It is not enough to write "the agent resolves issues" into a proposal.
SWE-bench Verified ( OpenAI, 13 Aug 2024 ): annotators reviewed 1,699 tasks and 500 were kept. 196 of them are "easy" (under 15 minutes) and 45 are "hard" (over an hour). GPT-4o resolved 33.2%. In the annotation, 38.3% of samples had an underspecified problem statement, 61.1% had tests that could fail a valid solution, and 68.3% were filtered out overall.
Verified retired ( OpenAI, 23 Feb 2026 ): the frontier moved from 74.9% to 80.9% in six months. OpenAI audited 27.6% of the set, focusing on tasks that models often fail. In at least 59.4% of the audited problems they found material issues in the test design and/or the problem description; tests that reject a correct patch are the biggest group, but not the only one. Contamination is a separate problem. OpenAI stopped reporting Verified and pointed to SWE-bench Pro.
Pro questioned too ( OpenAI, 8 Jul 2026 ): on the public split of SWE-bench Pro (731 tasks), the frontier pass rate rose from 23.3% to 80.3% in eight months. An automated pass flagged 200 tasks (27.4%) as broken, and a human campaign flagged 249 (34.1%). In the same post, OpenAI estimates that roughly 30% of Pro is broken and walks back its earlier advice to switch to Pro. Read the jump and the broken-task rate together.
Vendor tables. In the GPT-5.2 announcement, GPT-5.2 Thinking scores 80.0% on Verified and 55.6% on Pro public. That 24.4-point gap between two sets for the same model is larger than the whole 2024 shell-versus-ACI ablation. The GPT-5.4 announcement reports 57.7% on Pro public and 75.1% on Terminal-Bench 2.0. That is three percentages and three definitions of "can program". These are vendor figures, not independent measurements.
Developer productivity. METR's randomized trial (Becker et al., arXiv:2507.09089 ) followed 16 experienced open-source developers on 246 tasks from February to June 2025:
In a February 2026 update, METR says a follow-up with newer tools gave no reliable signal either way. The +19% describes early 2025, not Q4 2026.
The takeaway is that the interface moves the score even with fixed weights. A team's perception can have the opposite sign from the stopwatch. And a Verified or Pro percentage with no scaffold and no test audit attached does not predict your sprint.
The assumptions are explicit so you can swap in your own token counter:
A cut that still keeps a check in place looks like this:
If the test still fails at step 8, the loop stops. You don't get a patch, but you do get a bounded bill and a diff to review.
METR's result explains why teams still say "it feels faster". The gate therefore isn't a survey after the session. It is a test you knew before the agent started, plus a token counter on the session.
Does 80% on SWE-bench Verified mean the agent closes 80% of a senior engineer's tickets? No. The score depends on the model, the scaffold and how clean the benchmark is, and both Verified and Pro have been publicly questioned by the vendor that promoted them. Your sprint is measured by your own tests.
Should an MCP server run over stdio or remotely on the company network? Stdio runs a process next to the host and opens no port, so it suits a tool that may only read that directory anyway. Streamable HTTP gives the server an address, which means it also needs authentication and a separate list of tools that may write. Reads of issues and CI can go remote; a networked shell and production writes don't inherit that grant.
Can a terminal agent work in a repository under NDA? Yes, if the API key, the transcript and the shell stay inside your boundary. Exporting a session ( grok export ) copies the diffs and anything the loop pulled into context, which can include a secret from.env.
Konrad Wojtasik is the CEO of Commoditech, a Warsaw IT staff-augmentation company that places software, data and AI engineers into client teams. Related: LLM orchestration and inference cost.