Die Token-Illusion: Warum dein KI-Assistent mehr schleppt als denkt

Da taucht er immer wieder auf — dieser Moment in Produktions-Sessions mit KI-Agenten: Du gibst dem Tool eine kleine Aufgabe, es liefert saubere Arbeit ab, und dann wirfst du einen Blick auf den Token-Verbrauch. Schwindelgefühl garantiert.

Neulich hat ein Entwickler eine Session instrumentiert, in der ein Agent ein GitHub-Issue abgeschlossen hat. Issue gelesen, Datei bearbeitet, Tests ausgeführt, Commit erstellt, Pull Request geöffnet. Saubere, vollständige, nützliche Arbeit.

Das Ergebnis? Rund 10.300 Tokens für eigentliche reasoning und Generierung.

Die gesamte verarbeitete Kontextmenge? Knapp 1,55 Millionen Tokens.

Lass das kurz sacken. Das ist ein Arbeits-zu-Overhead-Verhältnis von ungefähr 1:150. Der Agent hat nicht mit 1,5 Millionen Tokens gedacht. Er hat sie mitgeschleppt wie Möbel in einem Umzugswagen, den er nicht auspacken konnte.

Wenn du Coding-Agents in deinem Workflow einsetzt — ob für Startup-Entwicklung, DevOps-Automatisierung oder einfach beschleunigte Code-Reviews — knabbert dieses Verhältnis still und leise an deinem Budget, bläht deine Latenz auf und erhöht das Risiko für Context Rot. Dabei verliert das Modell irgendwann den Faden, weil das Kontextfenster zu voll zum sauberen Parsen ist.

Also schauen wir uns an, wo diese Tokens eigentlich hingehen.

Anatomie einer aufgeblähten Session

Wenn man Session-Daten aus verschiedenen Agent-Runs durchforstet, wird das Muster schnell klar. Der meiste Token-Verbrauch kommt nicht vom Reasoning des Modells. Er kommt vom Kontext-Scaffolding — der Infrastruktur, die der Agent einfach braucht, um zu funktionieren.

Die Tool-Katalog-Explosion. Das ist der große Brocken, und er schleicht sich oft unbemerkt an. Je mehr MCP-Server (Model Context Protocol) du verbindest, desto mehr Tool-Definitionen werden in das Kontextfenster injiziert. In einer Session waren neun MCP-Server verbunden, die rund 260 Tools bereitstellten. Als zwei davon mitten in der Session hinzukamen, listete ein einzelner Server allein etwa 180 Tool-Namen. Das passiert einmal pro Verbindung — aber es verlässt nie die Konversationshistorie. Es bleibt einfach sitzen, akkumuliert, belastet jeden folgenden Turn.

Die Skills-Katalog-Steuer. Anders als Tool-Dumps, die Einmalzahlungen sind, sind Skills-Kataloge ein wiederkehrender Kostenpunkt pro Turn. Dutzende Skills, jeder mit mehreren Satzbeschreibungen, bei jeder einzelnen Interaktion geladen. Das treibt den Token-Count nicht dramatisch nach oben — es hebt einfach den Boden an. Session für Session bläht es leise deine Basis auf.

System-Prompt und Infrastruktur-Overhead. Bevor dein Agent überhaupt irgendetwas tut, bist du bei vielen Setups bereits jenseits der 100k Tokens. System-Prompt, Safety-Policies, Tool-Schemas, Formatierungsanweisungen — alles wird jeden Turn geladen. Nötig, aber nicht die Arbeit.

Die eigentliche Aufgabe. Hier wird es unangenehm: der Issue-Text, die Dateiänderungen, die Test-Ausgabe, die Commit-Message — alles zusammen vielleicht ein paar tausend Tokens. Die Aufgabe ist winzig neben der Werkstatt.

Warum das wichtiger ist, als du denkst

Vielleicht bist du versucht, das abzuschütteln. „Tokens sind doch billig, oder?"

Sind sie — bis du zwanzig Agent-Sessions am Tag laufen lässt, jede aufgebläht durch Faktoren, von denen du nicht wusstest, dass du sie kontrollieren kannst. Die Mathematik summiert sich schnell. Und es geht nicht nur um Kosten.

Hohes Kontextvolumen bedeutet höhere Latenz. Das Modell muss bei jedem Turn mehr verarbeiten, was Antwortzeiten verlangsamt — genau dann, wenn du Geschwindigkeit brauchst.

Noch kritischer: Context Rot wird zum echten Problem. Wenn der Arbeitskontext deines Agents vollgepackt ist mit Tool-Definitionen, Skill-Beschreibungen und Konversationshistorie, die er für die unmittelbare Aufgabe gar nicht braucht, fängt er an, Signal-rauschen zu verlieren. Er kann relevanten Kontext aus früheren Teilen der Session vergessen, deine Frage falsch interpretieren oder Entscheidungen auf Basis veralteter Informationen treffen, die tief in der Konversation vergraben liegen.

Für Startups, die schnell unterwegs sind, ist das kein kleines Ärgernis — das ist ein Zuverlässigkeitsproblem.

So misst du wirklich, was du ausgibst

Der Instinkt sagt: schätzen. „Diese Session ist vielleicht groß, weil die Aufgabe komplex ist." Meistens stimmt das nicht. Meistens ist es die Infrastruktur.

Drei Ansätze, die tatsächlich funktionieren:

1. Lies den Usage-Block in deiner finalen API-Antwort. Jede Antwort deines Modells enthält Nutzungsstatistiken: output tokens (was das Modell generiert hat), input tokens (was du geschickt hast) und cache_read_input_tokens (was aus der Konversationshistorie gezogen wurde). Diese cache_read-Zahl ist dein smoking gun. Wenn dort 1,5 Millionen Tokens stehen und dein Output war 10k, hast du ein klares Bild des Overhead-Verhältnisses.

2. Prüfe deinen Session-Kontext-Status mitten im Run. Die meisten modernen Agent-Frameworks haben einen Befehl wie /context, der dir zeigt, was genau dein Fenster gerade belegt — kategorisiert. So erwischst du die per-Turn-Kosten — den Skills-Katalog und Schemas — die ein finaler Usage-Block nicht sauber vom eigentlichen Task trennen kann.

3. Audite deine Tool-Verbindungen, bevor du neue hinzufügst. Bevor du einen weiteren MCP-Server verbindest oder eine weitere Capability zu deinem Agenten hinzufügst, frag dich: Was wird mich das pro Turn kosten? Eine einzelne Tool-Definition ist vielleicht okay. Hundert Tool-Definitionen über Dutzende Server hinweg sind ein stiller Budget-Killer.

Praktische Wege, das Verhältnis zu shrinken

Jetzt wird es nützlich. Wenn du erkannt hast, dass deine Agent-Sessions token-schwer sind, hier die Stellschrauben:

Schlanke deine Tool-Verbindungen. Audite jeden MCP-Server und frag, ob er sein Gewicht wert ist. Wenn ein Server 50 Tools bereitstellt und dein Agent drei genutzt hat, ist das eine Diskrepanz. Überlege, ob du all diese Tools dauerhaft verbunden brauchst — oder ob du sie nach Task-Phase scopen könntest.

Nutze fokussierte Kontexte statt globaler. Statt deinen kompletten Tool-Katalog und deine Skills-Bibliothek in jede Session zu laden, setz auf aufgabenspezifische Konfigurationen. Ein Agent für Code-Review braucht nicht denselben Kontext wie einer, der Infrastructure-Code schreibt.

Überwache pro Session, nicht nur pro Monat. Aggregierte Kosten checken versteckt die Ausreißer. Schau dir individuelle Session-Token-Counts an, und du erkennst Muster — welche Tasks spiken, welche Verbindungen aufblähen, welche Skills nie genutzt aber immer geladen werden.

Ziehe effiziente Modelle und Frameworks in Betracht. Manche Agent-Frameworks sind von Grund auf token-effizienter als andere. Vibe Hosting etwa baut seine KI-gestützte Entwicklungsumgebung genau mit diesem Fokus — die Power agentischer Workflows, ohne den versteckten Overhead, der deine Margen frisst.

Das Fazit

Das nächste Mal, wenn du einen Coding-Agent laufen lässt und das Gefühl hast, dass das Intelligence-zu-Kosten-Verhältnis nicht stimmt, hast du wahrscheinlich recht. Die Tokens gehen nicht dorthin, wo du denkst. Die meisten schleppen die Werkstatt — die Tools, Skills, Schemas und Konversations-Scaffolding — und erledigen nicht die eigentliche Arbeit.

Miss zuerst. Der Usage-Block und die Kontext-Befehle lügen nicht. Sobald du sehen kannst, wohin die Tokens fließen, kannst du informierte Entscheidungen treffen, was du trimmen kannst. In den meisten Fällen findest du erheblichen Optimierungsspielraum, ohne an Capability einzubüßen.

Dein Agent muss nicht die ganze Werkstatt mitschleppen. Er braucht nur die richtigen Tools für den Job. Stell sicher, dass du ihm genau das gibst.