Token-Overuse-Incidents (Prompt-Bloat) + Fixes + Code

  • Erkenne den Fehler früh, bevor die Rechnung steigt.
  • Verstehe, was in Prod bricht – und warum.
  • Guardrails kopieren: Budgets, Stop-Reasons, Validation.
  • Wissen, wann das nicht die Root Cause ist.
Erkennungs-Signale
  • Tool-Calls pro Run steigen (oder wiederholen sich mit args-hash).
  • Kosten/Tokens pro Request steigen ohne bessere Ergebnisse.
  • Retries kippen von selten zu konstant (429/5xx).
Prompt Bloat ist ein Production-Incident: Latenz hoch, Cost hoch, Truncation droppt Policy. So entsteht Token Overuse — und so budgetest du Kontext.
Auf dieser Seite
  1. Problem (aus der Praxis)
  2. Warum das in Production bricht
  3. 1) Kontext wächst per Default
  4. 2) Prompt Bloat → Truncation
  5. 3) Tool Outputs sind Token Bomben
  6. 4) Memory macht’s schlimmer
  7. 5) “Nimm einfach ein bigger context Modell” fix’t es nicht
  8. Implementierungsbeispiel (echter Code)
  9. Echter Incident (mit Zahlen)
  10. Abwägungen
  11. Wann du es NICHT nutzen solltest
  12. Checkliste (Copy/Paste)
  13. Sicheres Default-Config-Snippet (JSON/YAML)
  14. FAQ (3–5)
  15. Verwandte Seiten (3–6 Links)
Interaktiver Ablauf
Szenario:
Schritt 1/2: Execution

Normal path: execute → tool → observe.

Problem (aus der Praxis)

Alles ist gut.

Dann wird dein Agent “smarter”.

Er packt rein:

  • mehr History
  • mehr Tool Output
  • mehr “helpful context”

Latenz driftet hoch. Cost driftet hoch. Und irgendwann wird Policy truncat’t und der Agent verhält sich seltsam.

Token Overuse ist kein Theorieproblem. Es ist ein Incident, den du grafen kannst.

Warum das in Production bricht

1) Kontext wächst per Default

Ohne Cap wächst:

  • Chat History
  • Memory
  • Tool Outputs (HTML ist besonders böse)

Das Modell kennt deine Budgets nicht. Es frisst alles.

2) Prompt Bloat → Truncation

Große Prompts erhöhen die Chance, dass:

  • der Anfang droppt
  • und dort steht meist deine Policy

Ohne Policy ist das Modell nicht “evil”. Es ist unconstrained.

3) Tool Outputs sind Token Bomben

Raw HTML/Logs/Stack Traces sind riesig. Wenn du sie 1:1 pastest:

  • Tokens explodieren
  • das Modell kann’s oft nicht gut nutzen

Extract → summarize → kleine Slice.

4) Memory macht’s schlimmer

“Store everything” Memory wird oft zu “show everything”. Das ist prompt inflation.

5) “Nimm einfach ein bigger context Modell” fix’t es nicht

Größere Context Windows:

  • kosten mehr
  • sind langsamer
  • truncaten trotzdem (später)

Fix: Context Budget + Context Builder.

Implementierungsbeispiel (echter Code)

Cheap Prompt Budgeter:

  • cap total context
  • keep newest
  • summarise oldest when over budget (placeholder)

Chars hier; Tokens in real systems.

PYTHON
from dataclasses import dataclass
from typing import Iterable


@dataclass(frozen=True)
class ContextBudget:
  max_chars: int = 12_000


def summarize(text: str) -> str:
  return text[:2000] + "…"


def build_context(chunks: Iterable[str], *, budget: ContextBudget) -> str:
  parts: list[str] = []
  for c in chunks:
      parts.append(c)

  ctx = "\n\n".join(parts)
  if len(ctx) <= budget.max_chars:
      return ctx

  over = len(ctx) - budget.max_chars
  head = ctx[: over + 1000]
  tail = ctx[over + 1000 :]
  return summarize(head) + "\n\n" + tail
JAVASCRIPT
export function summarize(text) {
return text.slice(0, 2000) + "…";
}

export function buildContext(chunks, { maxChars = 12_000 } = {}) {
const ctx = chunks.join("\\n\\n");
if (ctx.length <= maxChars) return ctx;

const over = ctx.length - maxChars;
const head = ctx.slice(0, over + 1000);
const tail = ctx.slice(over + 1000);
return summarize(head) + "\\n\\n" + tail;
}

Das gibt dir nicht perfekte “Memory”. Es gibt dir den ersten Win: ein Budget gegen runaway prompts.

Echter Incident (mit Zahlen)

Agent beantwortete “warum ist der Job gefailt?” und packte full Logs in den Prompt.

Dann paste ein Kunde 2MB Log Blob.

Impact:

  • tokens/request: 4k → 45k
  • p95 Latenz: 3.2s → 19s
  • spend: ~$520 an einem Tag
  • worst: Policy truncat’t → unsichere Tool Vorschläge

Fix:

  1. input caps (max chars) auf user logs
  2. structured extraction statt raw dumps
  3. context budgeter + summarization tier
  4. metrics/alerts auf tokens/request

Logs sind nützlich. Raw logs sind kein Prompt-Format.

Abwägungen

  • Summaries verlieren Details (die raw dumps eh nicht geholfen haben).
  • Strikte Caps können Power User nerven; biete async upload an.
  • Token Counting ist extra Arbeit. Es zahlt sich schnell aus.

Wann du es NICHT nutzen solltest

  • Wenn du exaktes Reasoning über lange Docs brauchst: eher targeted retrieval + workflows.
  • Wenn du untrusted Text nicht safe summarizen kannst: nicht wholesale reinpasten.
  • Wenn du Tokens nicht messen kannst: starte mit chars, fix tokens danach.

Checkliste (Copy/Paste)

  • [ ] Cap user text size (logs/HTML/PDF)
  • [ ] Cap tool output size vor Kontext
  • [ ] Context builder mit hard budget (tokens/chars)
  • [ ] Summarization tier mit eigenem Budget
  • [ ] Policy Constraints jeden Turn wiederholen
  • [ ] Metrics: tokens/request, latency, spend/run
  • [ ] Alerts auf spikes und drift

Sicheres Default-Config-Snippet (JSON/YAML)

YAML
context:
  max_prompt_tokens: 2500
  max_untrusted_chars: 8000
  summarize_when_over_budget: true
policy:
  repeat_critical_constraints_every_turn: true
metrics:
  track: ["tokens_per_request", "latency_p95", "spend_per_run"]

FAQ (3–5)

Kann ich nicht einfach ein bigger context Modell kaufen?
Kannst du, aber du zahlst Latenz+Cost und truncat’t trotzdem irgendwann. Budgeting ist billiger.
Wie zähle ich Tokens korrekt?
Provider Tokenizer. Wenn du’s nicht kannst: char caps jetzt, token counting als follow-up.
Soll ich alles in Memory speichern?
Events speichern: ja. Alles dem Modell zeigen: nein. Memory ≠ Prompt Size.
Warum Policy Constraints wiederholen?
Truncation killt den Anfang. Repetition hält Constraints am Leben.

Q: Kann ich nicht einfach ein bigger context Modell kaufen?
A: Kannst du, aber du zahlst Latenz+Cost und truncat’t trotzdem irgendwann. Budgeting ist billiger.

Q: Wie zähle ich Tokens korrekt?
A: Provider Tokenizer. Wenn du’s nicht kannst: char caps jetzt, token counting als follow-up.

Q: Soll ich alles in Memory speichern?
A: Events speichern: ja. Alles dem Modell zeigen: nein. Memory ≠ Prompt Size.

Q: Warum Policy Constraints wiederholen?
A: Truncation killt den Anfang. Repetition hält Constraints am Leben.

Nicht sicher, ob das dein Fall ist?

Agent gestalten ->
⏱️ 5 Min. LesezeitAktualisiert Mär, 2026Schwierigkeit: ★★☆
In OnceOnly umsetzen
Guardrails for loops, retries, and spend escalation.
In OnceOnly nutzen
# onceonly guardrails (concept)
version: 1
budgets:
  max_steps: 25
  max_tool_calls: 12
  max_seconds: 60
  max_usd: 1.00
policy:
  tool_allowlist:
    - search.read
    - http.get
controls:
  loop_detection:
    enabled: true
    dedupe_by: [tool, args_hash]
  retries:
    max: 2
    backoff_ms: [200, 800]
stop_reasons:
  enabled: true
logging:
  tool_calls: { enabled: true, store_args: false, store_args_hash: true }
Integriert: Production ControlOnceOnly
Guardrails für Tool-Calling-Agents
Shippe dieses Pattern mit Governance:
  • Budgets (Steps / Spend Caps)
  • Kill switch & Incident Stop
  • Audit logs & Nachvollziehbarkeit
  • Idempotenz & Dedupe
  • Tool-Permissions (Allowlist / Blocklist)
Integrierter Hinweis: OnceOnly ist eine Control-Layer für Production-Agent-Systeme.
Beispiel-Policy (Konzept)
# Example (Python — conceptual)
policy = {
  "budgets": {"steps": 20, "seconds": 60, "usd": 1.0},
  "controls": {"kill_switch": True, "audit": True},
}
Autor

Diese Dokumentation wird von Engineers kuratiert und gepflegt, die AI-Agenten in der Produktion betreiben.

Die Inhalte sind KI-gestützt, mit menschlicher redaktioneller Verantwortung für Genauigkeit, Klarheit und Produktionsrelevanz.

Patterns und Empfehlungen basieren auf Post-Mortems, Failure-Modes und operativen Incidents in produktiven Systemen, auch bei der Entwicklung und dem Betrieb von Governance-Infrastruktur für Agenten bei OnceOnly.