KI-Code-Agenten verbrennen Zehntausende von Token, bevor sie überhaupt deinen Prompt lesen

Bevor ein KI-Code-Agent auch nur ein einziges Wort deiner Eingabe liest, hat er bereits Tausende von Token für seine Selbstvorstellung verbraucht: System-Prompts, Tool-Schemas, Scaffolding-Erinnerungen. Ein aktueller unabhängiger Vergleich zweier populärer Agent-Harnesses, Claude Code und OpenCode, hat diesen Overhead direkt gemessen – mit einem Logging-Proxy, der die exakten JSON-Payloads erfasste, die an die Model API gesendet wurden. Die Lücke war groß genug, um die Kostenkalkulation für jeden, der diese Tools im großen Maßstab einsetzt, grundlegend zu verändern.

Bei einer Basisaufgabe im ersten Durchlauf auf Claude Sonnet 4.5 sendete Claude Code etwa 32.800 Token, bevor der eigentliche Prompt des Nutzers verarbeitet wurde. OpenCode sendete für dieselbe Aufgabe rund 6.900 Token – ein 4,7‑facher Unterschied. Bei neueren Modellen verringert sich die Lücke auf das 3,3‑Fache, schließt sich aber nicht. Dieser Overhead bleibt im normalen Gebrauch unsichtbar: Du gibst einen Prompt ein, bekommst eine Antwort und siehst nie die darunter liegende Payload. Aber sie wird wie alles andere abgerechnet, und sie potenziert sich auf eine Weise, die relevant wird, sobald man über Spielzeugbeispiele hinausgeht.

Wohin die Token tatsächlich gehen

Der Overhead teilt sich in drei messbare Komponenten auf. System-Prompts machen den kleinsten, aber dennoch realen Anteil aus: Der System-Prompt von Claude Code hat 27.344 Zeichen (etwa 6.500 Token), der von OpenCode 9.324 Zeichen (~2.000 Token). Tool-Schemas sind der größere Kostenpunkt – Claude Code liefert 27 Tool-Definitionen mit rund 99.778 Zeichen (~24.000 Token), während OpenCodes schlankeres Set von 10 Tools auf 20.856 Zeichen (~4.800 Token) kommt. Der Rest ist Scaffolding: Claude Code fügt Erinnerungsblöcke, Agent-Kataloge und Kontextrahmen ein, bevor die eigentliche Nachricht des Nutzers kommt; OpenCode fügt standardmäßig nichts dergleichen hinzu.

Nichts davon ist im Sinne von Nutzlosigkeit verschwendet – mehr Tools und reichhaltigeres Scaffolding bedeuten in der Regel, dass der Agent mehr erledigen kann, ohne Rückfragen stellen zu müssen. Es ist ein echter Design-Kompromiss zwischen Leistung pro Anfrage und Kosten pro Anfrage, und die meisten Nutzer bekommen ihn nie zu sehen, geschweige denn auszuwählen.

Die Lücke wird bei realistischer Konfiguration größer

Die Basiswerte unterschätzen, was Produktions-Setups tatsächlich kosten. Fügt man eine typische 72KB Projekt-Instruktionsdatei hinzu (die Art von CLAUDE.md oder AGENTS.md, die die meisten ernsthaften Codebasen heute führen), steigen beide Harnesses um etwa 20.000 zusätzliche Token pro Anfrage – dieser Teil wird von der Konfiguration bestimmt, nicht von der Harness, also trifft er beide Tools gleichermaßen. Kommen fünf MCP (Model Context Protocol) Server hinzu – eine übliche Einrichtung für Teams, die Slack, Jira, Datenbanken oder interne APIs anbinden –, dann fügt jeder Server 4.900 bis 6.967 Token pro Anfrage hinzu, nur um seine verfügbaren Tools anzukündigen.

All das zusammengenommen erreicht eine realistische Produktionskonfiguration 75.000 bis 85.000 Token Tiefe, bevor der Nutzer ein einziges Wort seiner eigentlichen Anfrage getippt hat. Bei einem 200.000-Token-Kontextfenster sind das über 40 % des verfügbaren Platzes, der von Scaffolding belegt wird, bevor irgendein Code geschrieben oder gelesen wird.

Caching-Verhalten – wo die tatsächliche Kostenabweichung auftritt

Der folgenreichere Unterschied ist nicht die Basis-Tokenanzahl – es ist das, was mit diesem Overhead im Laufe einer Session passiert. OpenCode behält ein byte-identisches Anfragepräfix über die Runden hinweg bei, was bedeutet, dass Prompt-Caching nahezu ideal funktioniert: Dieselben Token werden Runde für Runde aus dem Cache wiederverwendet, mit minimalen Neuschreibungen.

Das Scaffolding von Claude Code hingegen wird während der Session immer wieder neu geschrieben – neue Erinnerungsblöcke, aktualisierter Kontext, aufgefrischter Tool-Status – was den Cache zwingt, ungültig gemacht und wiederholt neu aufgebaut zu werden. Das gemessene Cache-Schreibvolumen für Claude Code lag zwischen dem 5,9‑Fachen und dem 54‑Fachen von OpenCode, je nachdem, wie “warm” der Cache zum Zeitpunkt der Messung war. Cache-Schreibvorgänge sind nicht kostenlos: Sie werden zu einem Aufpreis von 1,25 gegenüber dem Basiseingabesatz für eine standardmäßige 5-Minuten-TTL abgerechnet. Eine Harness, die ständig ihren eigenen Cache neu schreibt, zahlt diesen Aufpreis weitaus häufiger als eine, die das nicht tut.

Subagenten vervielfachen das Problem – nicht nur additiv

Die krasseste Zahl im Vergleich betrifft die Delegation. Eine Aufgabe, die bei direkter Ausführung 121.000 kumulative Token kostete, verbrauchte 513.000 Token, als dieselbe Arbeit auf zwei Subagenten aufgeteilt wurde – eine 4,2‑fache Steigerung für das, was im Prinzip die gleiche Gesamtarbeit sein sollte. Jeder Subagent zahlt den vollen Basis-Overhead (System-Prompt, Tool-Schemas, Scaffolding) unabhängig; Delegation teilt diese Kosten nicht, sondern multipliziert sie mit der Anzahl der erzeugten Agenten.

Das ist direkt relevant dafür, wie Teams agentische Workflows architekten sollten. Die Aufteilung einer Aufgabe auf Subagenten wird oft als reiner Parallelitätsgewinn dargestellt – mehr Agenten, weniger Wandzeit. Die Token-Abrechnung erzählt eine andere Geschichte: Es ist ein echter Kostenkompromiss, und bei kleinen oder mittleren Aufgaben kann die Overhead-Multiplikation die Zeitersparnis mehr als aufwiegen.

Was man daraus machen sollte

Interessanterweise nähern sich die Harnesses bei komplexen mehrstufigen Aufgaben an: Claude Code verbrauchte 121.000 kumulative Token über 3 Anfragen (aggressives Tool-Call-Batching), während OpenCode 132.000 Token über 9 serialisierte Anfragen benötigte. Bei wirklich komplexer Arbeit spielt der basisbedingte Overhead-Unterschied eine geringere Rolle, weil er über mehr tatsächliche Arbeit pro Anfrage amortisiert wird.

Die praktischen Erkenntnisse: Prüfe die Größe deiner CLAUDE.md/AGENTS.md-Datei – diese 20.000-Token-Steuer trifft jede einzelne Anfrage unabhängig von der Harness. Gehe bewusst damit um, wie viele MCP-Server du aktiv hältst; jeder ist ein fixer Kostenpunkt pro Anfrage, ob du ihn in einer bestimmten Runde nutzt oder nicht. Und betrachte Subagenten-Fan-Out als Kostenentscheidung, nicht nur als Geschwindigkeitsentscheidung – hebe es für Aufgaben auf, die groß genug sind, dass der 4‑fache Overhead-Multiplikator für den Parallelitätsgewinn zu zahlen sich lohnt.