Stellen Sie sich folgendes Szenario vor: Sie öffnen einen KI-Programmierassistenten und geben die beiden Worte „Okay“ ein, um eine Bestätigung zu erteilen. Schon bevor das System diese beiden Worte überhaupt „sieht“, hat es im Hintergrund still und heimlich ein Rechenkontingent von etwa 33.000 Token verbraucht. Ein ähnliches Werkzeug hingegen kam in derselben Situation mit rund 7.000 Token aus.
Das ist kein Bild, keine Schätzung. Es ist das gemessene Ergebnis des Teams von Systima, das eine Logging-Proxy-Schicht vor die API von Anthropic geschaltet und jeden einzelnen Request im Rohdatenformat protokolliert hat. Die vollständige Methodik und die Originalzahlen sind im Blog veröffentlicht; der Beitrag erreichte auf Hacker News über 400 Upvotes und mehr als 200 Kommentare.
Der vorliegende Artikel möchte mit verständlicher Sprache drei Dinge hinter dieser Zahl beleuchten: Was genau treibt ein KI-Programmierwerkzeug „vor dem Lesen Ihrer Worte“? Warum sind Subagenten das eigentliche Token-Schwarzloch? Und welche Rolle spielt das nutzungsbasierte Geschäftsmodell dabei?
Was ist ein Token? Warum es wie „Benzin“ so schnell verbraucht wird
Vor den konkreten Zahlen ein zentrales Konzept. Ein Token ist die kleinste Abrechnungseinheit, mit der KI Text verarbeitet – kein „Zeichen“, sondern etwa 0,75 englische Wörter oder ein bis zwei chinesische Schriftzeichen. Bei nutzungsbasiert abgerechneten KI-Diensten entsteht mit jedem verarbeiteten Token eine Rechnung.
Ein KI-Programmierwerkzeug unterscheidet sich von gewöhnlichem KI-Chat. Im Web-Chat mit Claude erhält das Modell im Wesentlichen Ihre Frage. Ein KI-Programmierwerkzeug muss der Frage jedoch eine große Menge „Vorbereitung“ hinzufügen: wer die KI ist, welche Werkzeuge sie aufrufen darf, welche Regeln Ihr Projekt hat, in welchem Arbeitsverzeichnis sie sich befindet, Umgebungsinformationen des Betriebssystems und mehr.
Diese Zusatzinhalte nennt man „Gerüst“ (harness overhead). Das Problem: Die Größe des Gerüsts variiert enorm.
33.000 gegen 7.000: Die Rechnung für eine Antwort mit „OK“
Das Experiment von Systima war denkbar einfach: Zwei KI-Programmierwerkzeuge – das offizielle Claude Code von Anthropic und das Open-Source-Tool OpenCode – sollten dieselbe minimale Aufgabe ausführen: mit „OK“ antworten.
Bevor Claude Code die beiden Zeichen „OK“ las, sandte es etwa 33.000 Token an die API. Diese setzten sich zusammen aus rund 6.500 Token System-Prompt (der der KI sagt, „wer sie ist und wie sie vorgehen soll“), etwa 24.000 Token für die Definitionen von 27 Werkzeugen (Datei lesen, Datei schreiben, Befehl ausführen, Subagenten verwalten, Zeitplanaufgaben …) sowie etwa 2.000 Token für injizierte Erinnerungsblöcke (Aufgabenstatus, verfügbare Fähigkeiten, aktuelle Umgebungsdaten).
OpenCode kam mit etwa 7.000 Token aus: rund 2.000 Token System-Prompt und etwa 4.800 Token für zehn Werkzeugdefinitionen. Keine zusätzlichen Erinnerungsblöcke, sehr schlanke Struktur.
Ein leicht zu übersehendes Detail: Diese 33.000 Token sind nicht „einmalig verbraucht“. Im Arbeitsmodus eines KI-Programmierwerkzeugs wird das Gerüst in jeder Dialogrunde – bei jedem Hin-und-Her mit dem Modell – erneut gesendet. Benötigt eine Aufgabe zehn Runden, verschlingt allein das Gerüst 330.000 Token, ohne Ihren eigentlichen Code und Dialog.
Caching sollte sparen – doch Claude Code verpfuscht es
KI-Anbieter bieten meist einen Mechanismus namens „Prompt Caching“: Bleibt der Großteil eines Requests über mehrere Anfragen unverändert, kann er günstig aus dem Cache gelesen statt neu berechnet werden. Das ist das zentrale Mittel zur Kostenkontrolle.
Systima entdeckte jedoch einen entscheidenden Unterschied: Die Request-Präfixe von OpenCode waren stets bytegenau identisch – es musste den Cache also nur einmal schreiben, danach wurde jeder Lesevorgang zum Zehntelpreis abgerechnet. Claude Code hingegen überschrieb im Verlauf eines einzelnen Tasks wiederholt Zehntausende gecachte Token; die Schreibvorgänge in den Cache waren bei derselben Aufgabe das 54-Fache von OpenCode.
Cache-Schreiben ist deutlich teurer als Cache-Lesen. Mit anderen Worten: Der Anstieg auf der Rechnung resultiert zum großen Teil daraus, dass das Werkzeug den Cache ineffizient nutzt.
Die Rechnung in Produktion: von 33K auf 85K
Die 33.000 oben sind der „nackte“ Zustand – ohne Projektkonfiguration, ohne Plugins, ohne Zusatzwerkzeuge. Wie sieht die echte Produktionsumgebung aus?
Systima führte ein „Stapel-Experiment“ durch. Zunächst ein leeres Projekt, dann schrittweise die Konfiguration realer Entwicklungsszenarien:
Schritt eins: Eine 72-KB-Projektanweisungsdatei (AGENTS.md oder CLAUDE.md, die der KI die Code-Konventionen vorgibt). Allein dieser Schritt erhöhte jeden Request um etwa 20.000 Token.
Schritt zwei: Fünf leichtgewichtige MCP-Server (damit die KI E-Mails lesen/schreiben, Aufgaben verwalten, Datenbanken abfragen kann). Weitere etwa 5.000 bis 7.000 Token.
Kumuliert verbraucht Claude Code in einer echten Entwicklungsumgebung bereits 75.000 bis 85.000 Token, bevor es die Nutzerfrage liest. OpenCode bläht sich unter ähnlichem Stapel ebenfalls auf, bleibt aber wegen des niedrigen Ausgangswerts absolut kontrollierbar.
Subagenten: das wahre Token-Schwarzloch
Wenn der Gerüstverbrauch ein „erhöhter Kraftstoffverbrauch“ ist, dann ist der Subagent ein „undichter Tank“.
Subagenten sind eine wichtige Funktion von Claude Code: Bei komplexen Aufgaben kann der Hauptagent mehrere „Klon“ parallel arbeiten lassen; jeder Subagent liest eigenständig Code, analysiert Probleme und liefert Ergebnisse zurück. Das klingt effizient, ist aber von erschreckenden Kosten begleitet.
Systima verglich dieselbe Aufgabe: Direktausführung verbrauchte 121.000 Token; mit zwei parallel arbeitenden Subagenten schoss der Verbrauch auf 513.000 Token hoch – das 4,2-Fache.
Warum diese Differenz? Jeder Subagent ist eine eigenständige Arbeitseinheit. Er hat einen eigenen System-Prompt (wenn auch schlanker als der Hauptagent), einen eigenen Werkzeugsatz und muss Projektdateien neu einlesen, um den Kontext zu verstehen. Nach Erledigung der Aufgabe wird der gesamte Dialog des Subagenten vom Hauptagenten „verschluckt“ und als Referenz verwendet. Das gleicht zwei Leuten, die recherchieren: Jeder kehrt nicht nur mit der Antwort zurück, sondern schleppt eine ganze Kiste all jener Originaldokumente mit, die er durchgesehen hat.
Ein HN-Nutzer schilderte ein noch extremeres Erlebnis. Er schrieb: „Ich gab Claude Code eine recht große Aufgabe, woraufhin es sofort sieben Subagenten startete – und keiner hatte die Aufgabe vollendet, bevor mein Budget aufgebraucht war. Ein erneuter Versuch fünf Stunden später brachte dasselbe Ergebnis.“ Dieselbe Aufgabe, vom Hauptagenten der Reihe nach ausgeführt, funktionierte einwandfrei.
Anthropics Geschäftsmodell-Dilemma
An diesem Punkt drängt sich eine Frage auf: Designfehler oder Geschäftsmodell?
Anthropics API rechnet nach Token ab. Da Claude Code ein offizielles Werkzeug ist, steigen Anthropics Einnahmen mit dessen Token-Verbrauch. Das bedeutet nicht zwingend „absichtliches Design“ – wahrscheinlicher ist ein struktureller Anreiz: Wenn Ihre Einnahmen davon abhängen, wie viele Token Nutzer verbrauchen, haben Sie nicht denselben starken Antrieb wie die Open-Source-Gemeinschaft, das Gerüst zu verschlanken.
Dass OpenCode das 7.000-Token-„Fundament“ erreicht, liegt großteils daran, dass es ein Open-Source-Projekt ist – sein Designziel umfasst nicht die Maximierung von API-Einnahmen. Die 27 Werkzeuge von Claude Code, die mehrschichtigen Erinnerungsblöcke, der vollständige Steuerungsmechanismus der Subagenten: Jede Designentscheidung hat einen legitimen Grund („mehr Funktionen“). Werden diese „mehr Funktionen“ jedoch addiert, wird die Nutzerrechnung zum Nebenprodukt.
Doch Claude Code gewinnt auch manchmal
Fair bleibt: Systimas Test fand auch ein Szenario, das für Claude Code spricht.
Bei einer Aufgabe mit mehreren Schritten (Code schreiben, Tests ausführen, anhand von Fehlern korrigieren, erneut testen) war der Gesamtverbrauch von Claude Code sogar niedriger als jener von OpenCode. Der Grund: Claude Code bündelt mehrere Werkzeugaufrufe in einem einzigen Request, während OpenCode pro Werkzeugaufruf eine neue Runde startet. Zwar ist die Basislast von Claude Code pro Runde schwerer, doch OpenCode zahlt wegen fehlender Bündelung neunmal die Basislast erneut und landet am Ende bei der höheren Summe.
Dieser Befund enthüllt eine feine Wahrheit: Die Token-Effizienz eines Werkzeugs hängt nicht nur davon ab, wie leicht seine Basislast ist, sondern auch davon, wie es den Arbeitsablauf organisiert. Schwere Basis bei Bündelungsfähigkeit gegen leichte Basis bei wiederholtem Durchlauf – was überwiegt, hängt von der konkreten Aufgabe ab.
Was bedeutet das für normale Nutzer?
Wer nicht programmiert, mag das für ein „Programmierer-Problem“ halten. Tatsächlich betrifft dieses nutzungsbasierte Abrechnungsmodell jeden, sobald KI-Werkzeuge vom „Chatten“ zum „Arbeiten“ übergehen.
Wenn Sie in Cursor eine Codezeile ändern oder in Claude Code einen Bug beheben lassen, spielt sich hinter jeder Aktion eine ähnliche Geschichte ab: riesige Systemanweisungen werden wiederholt gesendet, Subagenten entstehen und vergehen im Hintergrund, Caches werden wiederholt überschrieben – und die Rechnung wächst leise in diesen unsichtbaren Bewegungen.
Systimas Experiment holte die zuvor im Schwarzen Kasten verborgenen Zahlen ans Licht. Als Nutzer ist allein das Wissen um diese Zahlen bereits eine Form von informativem Empowerment.
Oder direkter formuliert: Beim nächsten Blick auf die API-Rechnung wissen Sie, dass vermutlich nur ein kleiner Teil davon tatsächlich von Ihnen genutzt wurde.
Referenzen:
- Systima: Claude Code vs OpenCode Token Overhead
- HN-Diskussion (item?id=48883275)