Token Overuse: Wenn Agenten zu viele Tokens verbrauchen

Problem

Die Anfrage wirkt einfach: Incident-Status prüfen und eine kurze Zusammenfassung geben.

In den Traces sieht man etwas anderes: In 8 Minuten hat ein Run über 38k Tokens verbraucht, obwohl ähnliche Aufgaben früher in ~4-6k blieben. Die Hälfte des Budgets ging nicht in die Antwort, sondern in Kontext: history, rohe Logs und große tool outputs.

Für diese Aufgabenklasse kann das etwa ~$2.80 statt der üblichen ~$0.20 kosten. Und die Antwortqualität ist dabei kaum gestiegen.

Das System crasht nicht.

Es bläht einfach langsam Prompt, Latenz und Kosten auf.

Analogie: Stell dir einen Koffer vor, in den vor jeder Reise "noch eine wichtige Sache" gelegt wird, aber nie etwas herausgenommen wird. Anfangs ist das fast unsichtbar. Danach verbringst du mehr Zeit, Geld und Kraft nur damit, Überflüssiges zu tragen. Token Overuse bei Agenten funktioniert genauso.

Warum das passiert

Token Overuse entsteht meist nicht durch das Modell selbst, sondern durch schwache Kontrolle des Kontext-Budgets in der Runtime.

In Production sieht das meist so aus:

1. in den Kontext jedes neuen Schritts kommt alles: history, retrieval, tool output;
2. rohe Payloads (Logs, HTML, JSON) landen ohne Kompression im Prompt;
3. ohne per-source caps und Summarization wächst Kontext mit jedem Turn;
4. Tokens gehen für "Überflüssiges transportieren" drauf, nicht für Fortschritt;
5. lange reasoning loops ohne no-progress-Prüfung blähen history noch stärker auf.

Im Trace zeigt sich das meist als stabiler Anstieg von prompt_tokens, bei dem jeder neue Turn teurer wird als der vorherige, selbst wenn die Aufgabe nicht komplexer wird.

Ohne Kontrolle schadet dieses Wachstum Latenz, Kosten und Qualität.

Welche Ausfälle am häufigsten auftreten

In Production sieht man am häufigsten vier wiederkehrende Token-Overuse-Pattern.

Prompt bloat

In die Modellanfrage kommt zu viel Kontext "für alle Fälle".

Typische Ursache: kein max_prompt_tokens und keine Priorisierung von Chunks.

Token bombs in tool output

Tools liefern große Payloads (HTML, Logs, Stack Traces), die fast ungefiltert in den Prompt gehen.

Typische Ursache: keine caps, und Payload geht nicht durch extraction oder summarization, bevor es in den Prompt kommt.

Memory/history inflation

Der Agent sammelt Turn für Turn History, komprimiert alte Abschnitte aber nicht. Dadurch wird jeder neue Schritt teurer. Wenn der Run zusätzlich lange ohne Fortschritt rotiert, wächst diese Inflation noch schneller.

Typische Ursache: memory wird als "Archiv" genutzt, nicht als budgeted context.

Stille Degradation durch truncation

Wenn der Kontext das reale Window überschreitet, werden wichtige Teile des Prompts abgeschnitten. Oft verschwinden zuerst Policy-Constraints oder kritische Instruktionen.

Typische Ursache: keine explizite Kontrolle, was in welcher Reihenfolge entfernt wird.

Wie man diese Probleme erkennt

Token Overuse ist gut über die Kombination aus Cost-, Latenz- und Kontext-Metriken sichtbar.

Wie man Überverbrauch von wirklich komplexen Aufgaben unterscheidet

Nicht jeder große Prompt ist schlecht. Die Schlüsselfrage: bringen zusätzliche Tokens echten Qualitätsgewinn?

Normal, wenn:

• komplexe Anfrage wirklich mehr Quellen und Prüfungen braucht;
• tokens_per_success zusammen mit Genauigkeit steigt;
• zusätzlicher Kontext neue Fakten liefert statt Bekanntes zu wiederholen.

Gefährlich, wenn:

• Tokens schneller steigen als die Success Rate;
• viel Kontext alte Turns oder rohe technische Dumps dupliziert;
• Latenz und Kosten steigen, Antworten sich aber kaum ändern.

Wie man solche Ausfälle stoppt

Praktisch sieht das so aus:

1. harte Limits setzen: max_prompt_tokens + caps für history/tool/retrieval;
2. context builder mit Prioritäten ergänzen (policy und neue Fakten über alten Logs);
3. alte oder große Fragmente in eine summarization tier komprimieren;
4. bei Budgetüberschreitung stop reason oder partial zurückgeben, statt "überfüllten" Prompt zu senden.

Minimaler Guard für Token-Budget:

from dataclasses import dataclass


@dataclass(frozen=True)
class TokenLimits:
    max_prompt_tokens: int = 7000
    max_history_tokens: int = 1800
    max_tool_tokens: int = 2500
    max_retrieval_tokens: int = 2200


class TokenBudgetGuard:
    def __init__(self, limits: TokenLimits = TokenLimits()):
        self.limits = limits
        self.total_prompt_tokens = 0
        self.by_source = {
            "history": 0,
            "tool": 0,
            "retrieval": 0,
        }

    def _cap_for(self, source: str) -> int:
        if source == "history":
            return self.limits.max_history_tokens
        if source == "tool":
            return self.limits.max_tool_tokens
        if source == "retrieval":
            return self.limits.max_retrieval_tokens
        return self.limits.max_prompt_tokens

    def add_chunk(self, source: str, tokens: int) -> str | None:
        if self.by_source.get(source, 0) + tokens > self._cap_for(source):
            return f"token_overuse:{source}_cap"

        if self.total_prompt_tokens + tokens > self.limits.max_prompt_tokens:
            return "token_overuse:prompt_budget_exceeded"

        self.by_source[source] = self.by_source.get(source, 0) + tokens
        self.total_prompt_tokens += tokens
        return None

Das ist ein Basis-Guard. In Production ergänzt man ihn meist mit provider-genauem Token-Counting, einer summarization tier für alte Chunks und separaten stop reasons für truncation. add_chunk(...) wird vor dem Einfügen in den Prompt aufgerufen, damit Budget als Gate wirkt und nicht als nachträgliche Prüfung.

Wo das in der Architektur umgesetzt wird

In Production ist Token-Overuse-Kontrolle fast immer auf drei Systemschichten verteilt.

Memory Layer steuert, was langfristig gespeichert wird und was in den aktuellen Prompt geht. Wenn memory = "alles zeigen", steigen Kosten zwangsläufig.

Tool Execution Layer ist verantwortlich für Normalisierung und Kompression großer Payloads, bevor sie in den Modellkontext kommen. Hier setzt man output caps, extrahiert nötige Fakten aus großen Payloads und komprimiert sie vor dem Prompt.

Agent Runtime hält execution budgets: max_prompt_tokens, stop reasons, kontrolliertes Beenden und Fallback bei Limit-Überschreitung. Hier wird Token-Budget zur Production-Regel statt zum Wunsch.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Kann man nicht einfach auf ein Modell mit größerem context window wechseln?
A: Kann man, aber es ist meist teurer und langsamer. Ohne Budget-Kontrolle verschwindet das Problem nicht, sondern wandert nur auf ein höheres Limit.

Q: Womit startet man besser: Tokens oder Zeichen?
A: Am besten mit provider Token-Zähler. Wenn das nicht geht: konservative char caps und dann auf Tokens umstellen.

Q: Was sollte man bei Budgetüberschreitung zuerst komprimieren?
A: Meist alte Turns und große rohe tool outputs. Policy und neueste Fakten sollten bleiben.

Q: Was sollte der User sehen, wenn das Prompt-Budget aufgebraucht ist?
A: Stop Reason, was bereits verarbeitet wurde, und den sicheren nächsten Schritt: partial Ergebnis, engere Anfrage oder neuer Run mit kleinerem Kontext.

Token Overuse sieht fast nie wie ein lauter Ausfall aus. Es ist eine langsame Degradation, die Latenz und Kosten aufbläht, ohne klaren Service-Crash. Darum brauchen Production-Agenten nicht nur bessere Modelle, sondern strenge Kontrolle des Kontext-Budgets.

Verwandte Seiten

Wenn dieses Problem in Production auftritt, hilft auch:

• Warum AI-Agenten scheitern - allgemeine Karte der Production-Ausfälle.
• Budget explosion - wie Token-Überverbrauch zum finanziellen Incident wird.
• Tool spam - wie unnötige Tool-Aufrufe Kontext und Kosten aufblasen.
• Context poisoning - wie schlechter Kontext Agent-Entscheidungen verschlechtert.
• Memory Layer - wo Langzeit-Memory vom Prompt-Kontext getrennt wird.
• Agent Runtime - wo Token-Limits, stop reasons und fallback gesetzt werden.