TL;DR
Die Token-Kosten von KI-Agenten steigen, wenn bei jedem Schritt Anweisungen, Verlauf, Tool-Ergebnisse und Zwischenzustände erneut verarbeitet werden.
Reduzieren Sie das Token-Volumen mit Budgets auf Run-Ebene, Filterung von Tool-Ergebnissen, Kontextverdichtung, Retry-Grenzen und kontrolliertem Reasoning. Nutzen Sie Prompt-Caching für stabil wiederholte Eingaben, optimieren Sie jedoch zuerst die Agentenschleife, bevor Sie auf ein günstigeres Modell wechseln.
Die nützlichste Kennzahl im Betrieb ist die Kennzahl Kosten pro erfolgreicher Aufgabe, gemessen über den gesamten Run – nicht der Preis pro Anfrage oder die Kontextgröße des letzten Aufrufs.
Dieser Leitfaden konzentriert sich explizit auf mehrschrittige KI-Agenten. Er erklärt, wie sich wiederholter Kontext über einen Run kumuliert, wie Sie die größte Verschwendungsquelle identifizieren und welche Maßnahmen zuerst zu implementieren sind.
Introduction
Ein Chatbot sendet pro Nutzer-Nachricht möglicherweise eine einzige Modellanfrage. Ein KI-Agent kann 10, 20 oder mehr Aufrufe durchführen, bevor er eine Aufgabe abschließt.
In jedem Schritt können Anweisungen, Gesprächsverlauf, Tool-Ergebnisse und Zwischenzustände erneut gesendet werden. Retries, Reasoning und Subagenten erhöhen die Nutzung weiter, sodass eine kurze finale Antwort dennoch eine große Anzahl von Token verbrauchen kann.
Mit wachsender Nutzung werden diese Kosten schwerer vorhersehbar und können die Produktmargen schnell verringern. Ihre Senkung erfordert die Optimierung der gesamten Agentenschleife – nicht nur den Wechsel auf ein günstigeres Modell.
Dieser Artikel konzentriert sich auf agentenspezifische Kosten. Für einen breiteren Leitfaden zu Prompt-Caching, exaktem Antwort-Caching, semantischem Caching, Modell-Routing und allgemeinem API-Kostenmanagement siehe How to Reduce AI API Costs.
Why Do AI Agent Token Costs Compound?
Bei einem mehrschrittigen Agenten sind die Kosten einer Aufgabe die Summe aller Modellaufrufe – nicht nur der finalen Antwort.
Die Hauptquellen des Token-Verbrauchs von Agenten sind:
| Cost source | What causes it | First control to test |
|---|---|---|
| Repeated instructions | System prompts, tool schemas, policies, examples | Stabilize the reusable prefix |
| Growing history | Earlier turns are resent at each step | Compact or selectively retrieve state |
| Tool results | Search pages, files, logs, and database records | Filter before adding them to context |
| Intermediate output | Plans, status messages, and verbose tool decisions | Use compact structured outputs |
| Reasoning tokens | High reasoning effort on routine steps | Match effort to task complexity |
| Retries | Invalid output, timeouts, tool errors, and rate limits | Classify failures and cap retries |
| Subagents | Workers duplicate context, tools, and analysis | Send each worker a narrow context slice |
Es gibt zwei unterschiedliche Wege, die Rechnung zu reduzieren:
- Weniger Token verarbeiten durch Filterung, Verdichtung, Ausgabelimits und Loop-Kontrollen.
- Den effektiven Preis notwendiger Token durch Prompt-Caching oder Modellauswahl senken.
Wichtige Unterscheidung: Prompt-Caching senkt die Kosten wiederholter Eingaben. Kontextverdichtung reduziert die wiederholte Eingabe selbst.
How Can a 12-Step Agent Process 147,000 Tokens?
Betrachten wir einen hypothetischen Support-Agenten mit:
- einem stabilen Präfix von 4.000 Token
- 1.500 neuen Token nach jedem Schritt
- dem komplett kumulierten Verlauf, der bei jeder Anfrage erneut gesendet wird
- insgesamt 12 Modellaufrufen
Die Eingabe in Schritt n ist:
Input at step n = 4,000 + 1,500 × (n - 1)
Die kumulierte Eingabe über 12 Aufrufe ist:
Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens
Der letzte Aufruf enthält nur 20.500 Eingabetoken, aber der gesamte Run verarbeitet 147.000 kumulierte Eingabetoken.
Wenden wir nun zwei Maßnahmen an:
- Das stabile Präfix mit 4.000 Token nach dem ersten Aufruf cachen.
- Den Verlauf nach Schritt sechs in einen 2.500-Token-Zustand verdichten.
| Scenario | Uncached input | Cached input | Total processed input | Change |
|---|---|---|---|---|
| Full history on every step | 147,000 | 0 | 147,000 | Baseline |
| Stable prefix cached | 103,000 | 44,000 | 147,000 | Same volume, cheaper mix |
| Cache plus compaction | 64,000 | 44,000 | 108,000 | 26.5% fewer processed tokens |
Dies ist eine Planungsrechnung, kein Anbieter-Benchmark.
Es wird angenommen, dass jede Anfrage den komplett kumulierten Verlauf enthält. Agenten, die Zustand selektiv konstruieren, alte Nachrichten zusammenfassen oder nur relevante Informationen abrufen, können einer anderen Kostenkurve folgen.
Kostenwachstums-Regel: Messen Sie die kumulierte Eingabe über den gesamten Run. Die finale Kontextgröße repräsentiert nicht die insgesamt verarbeiteten Token.

Which Metrics Reveal Agent Token Waste?
Beginnen Sie nicht mit dem Modellwechsel. Identifizieren Sie zuerst, wo der Workflow Token verbraucht, ohne das Ergebnis zu verbessern.
Protokollieren Sie diese Felder für jeden Agenten-Schritt:
| Field | Why it matters |
|---|---|
run_id, step_id, parent_step_id | Rekonstruiert den Agenten- und Subagenten-Baum |
| Rendered input tokens | Zeigt, wie der Kontext zwischen Aufrufen wächst |
| Cached and uncached input | Trennt Wiederverwendung von neuem Kontext |
| Output and reasoning tokens | Identifiziert teure Generierungsschritte |
| Tool result size and retained tokens | Zeigt, wie viel Roh-Evidenz in spätere Prompts gelangt |
| Retry reason and attempt number | Identifiziert wiederholte Fehler |
| Compaction tokens before and after | Misst die tatsächliche Kontextreduktion |
| Worker ID and returned tokens | Deckt doppelte Subagenten-Arbeit auf |
| Accepted, rejected, or escalated result | Verknüpft Kosten mit der Aufgabenqualität |
Die primäre Kennzahl sollte sein:
cost per successful task
= total workflow cost
/ accepted tasks
Ein günstigerer Run ist keine Verbesserung, wenn er mehr Fehlversuche, wiederholte Tools oder menschliche Nacharbeit erzeugt.
Vier agentenspezifische Metriken helfen, das Problem zu lokalisieren.
Context Amplification
context amplification
= cumulative input tokens
/ final-step input tokens
Ein hoher Wert zeigt an, dass früherer Kontext wiederholt verarbeitet wird.
Tool Retention Ratio
tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools
Eine hohe Quote kann darauf hindeuten, dass der Agent zu viel Roh-Evidenz zwischen Schritten mitschleppt.
Retry Tax
retry tax
= retry and repair cost
/ total workflow cost
Reasoning Share
reasoning share
= reasoning-token cost
/ total model cost
Messen Sie jede Arbeitslast separat. Forschungs-, Coding-, Browser- und Customer-Support-Agenten sollten keinen globalen gemeinsamen Basiswert haben.
Six Ways to Reduce AI Agent Token Costs
1. Set a Budget for the Complete Run
Eine Ausgabelimitierung pro Anfrage steuert einen mehrschrittigen Agenten nicht.
Setzen Sie Limits auf Run-Ebene für:
- Gesamtzahl der Modellschritte
- Kumulative Ein- und Ausgaben
- Tool-Aufrufe und Größe der Tool-Ergebnisse
- Retries nach Fehlertyp
- Subagenten
- Gesamte verstrichene Zeit oder geschätzte Kosten
Das folgende anbieterneutrale Python-Beispiel bewertet den Run vor jedem Modellaufruf:
from dataclasses import dataclass
from enum import Enum
class Action(str, Enum):
CONTINUE = "continue"
COMPACT = "compact"
STOP = "stop"
@dataclass(frozen=True)
class Budget:
max_steps: int = 12
max_input_tokens: int = 120_000
max_output_tokens: int = 18_000
compact_at: float = 0.80
@dataclass
class Usage:
steps: int = 0
input_tokens: int = 0
output_tokens: int = 0
def evaluate_budget(usage: Usage, budget: Budget) -> Action:
if (
usage.steps >= budget.max_steps
or usage.input_tokens >= budget.max_input_tokens
or usage.output_tokens >= budget.max_output_tokens
):
return Action.STOP
input_ratio = usage.input_tokens / budget.max_input_tokens
if input_ratio >= budget.compact_at:
return Action.COMPACT
return Action.CONTINUE
Führen Sie die Prüfung vor jeder Modellanfrage aus und aktualisieren Sie Usage mit den vom Anbieter gemeldeten Token-Daten.
Bei 80% des Eingabebudgets verdichten Sie den Zustand oder verengen die nächste Tool-Abfrage. Bei 100% stoppen Sie mit einer strukturierten Begründung.
Häufiger Fehler: Jede Antwort begrenzen, aber unbegrenzte Schritte, Tools und Retries zulassen.
2. Filter Tool Results Before They Enter the Transcript
Geben Sie nur die Belege zurück, die der Agent für die nächste Entscheidung benötigt.
Hängen Sie nicht eine ganze
- Webseite
- Logdatei
- Repository-Struktur
- Datenbankantwort
- Terminalsitzung
- API-Nutzlast
an, wenn der nächste Schritt nur wenige Felder braucht.
Ein Such-Tool könnte Folgendes zurückgeben:
{
"source_id": "search_17",
"title": "Relevant page title",
"url": "https://example.com/page",
"relevant_passage": "A short evidence block"
}
Speichern Sie das vollständige Artefakt außerhalb des Prompts und rufen Sie später einen engeren Abschnitt ab.
Regel zur Tool-Filterung: Geben Sie die Felder zurück, die für die nächste Entscheidung nötig sind – nicht jedes Feld, das später nützlich sein könnte.
Häufiger Fehler: Die ersten 1.000 Zeichen einer JSON-Nutzlast abzuschneiden. Dies kann die Struktur zerstören oder die tatsächlich benötigten Datensätze entfernen.
Parsen Sie die Nutzlast zuerst, wählen Sie Felder strukturell aus, begrenzen Sie Arrays und serialisieren Sie anschließend gültiges JSON.
3. Compact Operational State, Not Just Conversation Text
Verdichtung soll die Informationen bewahren, die zum Fortsetzen der Aufgabe erforderlich sind, während Historie entfernt wird, die die nächsten Aktionen nicht mehr beeinflusst.
Ein nützlicher verdichteter Zustand enthält:
- Nutzerziel und Erfolgskriterien
- Bereits getroffene Entscheidungen
- Verifizierte Fakten und Quell-IDs
- Geänderte Dateien oder Datensätze
- Gescheiterte Ansätze
- Offene Fragen
- Die nächste Aktion
- Sicherheits- und Ausgabebeschränkungen
Er sollte nicht die komplette Unterhaltung nacherzählen.
OpenAI dokumentiert Verdichtung für lang laufende Interaktionen der Responses API. Anthropic bietet Kontext-Management-Kontrollen zum Löschen oder Zusammenfassen älterer Inhalte. Diese Implementierungen unterscheiden sich, prüfen Sie daher vor der Integration die aktuellen Felder des Anbieters.
Regel zur Verdichtung: Entscheidungen und unerledigte Arbeit bewahren. Erzählung und Belege entfernen, die erneut abrufbar sind.
Häufiger Fehler: Quell-IDs, geänderte Dateinamen, verworfene Ansätze oder ungelöste Constraints zu löschen.
Messen Sie nach der Einführung der Verdichtung, ob der Agent Suchen oder Tool-Aufrufe wiederholt. Ein kürzerer Prompt ist nicht günstiger, wenn der Agent verlorenen Zustand neu aufbauen muss.
4. Keep the Reusable Prefix Stable
Agenten-Prompts enthalten oft große wiederverwendbare Blöcke:
- Systemanweisungen
- Tool-Schemata
- Sicherheitsrichtlinien
- Ausgabeformate
- Gemeinsames Referenzmaterial
- Repository- oder Produkthinweise
Platzieren Sie diese stabilen Elemente vor den anfrage-spezifischen Daten:
1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data
Vermeiden Sie es, Zeitstempel, Request-IDs, Sitzungsdaten oder häufig wechselnde Werte nahe dem Anfang zu platzieren.
Caching ist am nützlichsten, wenn das Präfix lang, stabil und wiederverwendet ist. Für kurze Sitzungen oder häufig wechselnde Prompts bringt es möglicherweise keine Einsparungen.
Häufiger Fehler: Auf Cache-Trefferquote optimieren, ohne die Kosten für Cache-Schreiben, -Lesen oder -Speicherung zu messen.
Für einen breiteren Vergleich von Anbieter-Prompt-Caching, exaktem Antwort-Caching und semantischem Caching siehe How to Reduce AI API Costs.
5. Prevent Retries From Replaying the Same Context
Ein Retry ist ein weiterer Agenten-Schritt – oft mit demselben großen Prompt.
Wiederholen Sie eine fehlgeschlagene Anfrage nicht, ohne die Ursache zu ändern.
| Failure | Better response |
|---|---|
| Invalid structured output | Validierungsfehler zurückgeben und einmal erneut versuchen |
| Tool timeout | Eine idempotente Operation einmal wiederholen, dann stoppen oder Fallback nutzen |
| Context overflow | Zustand verdichten oder weniger Evidenz abrufen |
| Repeated tool call | Mit einem Operations-Hash deduplizieren |
| Rate limit | Backoff oder getestete Fallback-Route nutzen |
| Low-confidence result | Fehlende Informationen anfordern oder eskalieren |
Verwenden Sie Idempotenzschlüssel für Operationen mit Nebenwirkungen wie Zahlungen, E-Mails, Deployments und Datenbankschreibvorgänge.
Häufiger Fehler: Ein rate-limitiertes Modell mehrfach erneut aufrufen und dabei jedes Mal den gesamten Agenten-Kontext erneut senden.
Verfolgen Sie die Retry-Steuer nach Fehlertyp, damit das Team die größte Schleife zuerst beheben kann.
6. Limit Reasoning and Subagents to Steps That Need Them
Nicht jeder Agenten-Schritt benötigt tiefes Reasoning.
Extraktion, Formatierung, Klassifikation, Validierung und routinemäßige Tool-Auswahl können oft mit geringerem Reasoning-Aufwand und kompakten strukturierten Ausgaben erfolgen.
Reservieren Sie höheren Reasoning-Aufwand für Aufgaben wie:
- Komplexe Planung
- Anspruchsvolles Coding
- Synthese über mehrere Dokumente
- Mehrdeutige Entscheidungen
- Wiederherstellung nach fehlgeschlagener Ausführung
Regel zum Reasoning: Verwenden Sie den geringsten Reasoning-Aufwand, der die Akzeptanzrate der Aufgaben erhält.
Auch Subagenten benötigen eine klare Abgrenzung. Geben Sie jedem Worker:
- Eine enge Aufgabe
- Einen aufgabenspezifischen Kontextausschnitt
- Eine Tool-Allowlist
- Ein Token-Budget
- Ein kompaktes Ausgabeschema
Der Root-Agent braucht in der Regel Ergebnisse, Evidenz-IDs, Vertrauen und ungelöste Punkte – nicht das vollständige Transkript des Workers.
Subagenten-Regel: Parallelisieren Sie unabhängige Arbeit, nicht duplizierten Kontext.
Häufiger Fehler: Dem vollständigen Root-Agenten-Verlauf an jeden Worker zu senden, bevor eine enge Aufgabe zugewiesen wird.
Which Optimization Should You Apply First?
Nutzen Sie Agenten-Telemetrie, um die erste Maßnahme auszuwählen.
Die folgenden Schwellen sind Auslöser für Untersuchungen, keine universellen Standards.
| Observed signal | Start here |
|---|---|
| Context amplification is high | Verlauf verdichten und Zustand selektiv abrufen |
| Tool output dominates the prompt | Felder filtern und vollständige Artefakte extern speichern |
| Retry tax is high | Validierung, Timeouts und wiederholte Tool-Aufrufe beheben |
| Reasoning share is high | Aufwand bei Routine-Schritten senken |
| Subagents repeat the same evidence | Worker-Scopes und Kontextausschnitte verengen |
| Cached input remains low | Wiederverwendbares Präfix stabilisieren |
| Costs remain high after loop cleanup | Günstigere Modellrouten vergleichen |
Eine sichere Implementierungsreihenfolge ist:
- Kumulative Eingabe, Tool-Beibehaltung, Retries und Reasoning messen.
- Harte Limits für Schritte, Tools, Retries und Gesamt-Token hinzufügen.
- Große Tool-Ergebnisse filtern.
- Älteren Zustand ab einem gemessenen Schwellwert verdichten.
- Das wiederverwendbare Prompt-Präfix stabilisieren.
- Modellrouten erst vergleichen, nachdem die Agentenschleife bereinigt ist.
Ändern Sie jeweils nur eine große Variable und spielen Sie denselben Evaluationssatz erneut ab.
Vergleichen Sie:
- Aufgaben-Akzeptanzrate
- Kosten pro erfolgreicher Aufgabe
- Kumulative Eingabe
- Anzahl der Tool-Aufrufe
- Retry-Steuer
- Reasoning-Anteil
- p50- und p95-Latenz
- Zeit für menschliche Überprüfung
Setzen Sie Änderungen zurück, die Token sparen, indem sie die Aufgabenqualität senken oder notwendige Evidenz entfernen.
Test Agent Workflows With CometAPI
Bevor Sie eine Multi-Modell-Evaluation starten, verwenden Sie die CometAPI pricing page und den cost estimation guide, um Eingabe-, Ausgabe-, gecachte Token- und Reasoning-Kosten zu schätzen.
Nutzen Sie anschließend den model catalog, um geeignete Routen zu identifizieren, und den Quickstart, um einen OpenAI-kompatiblen Client zu konfigurieren.
Für Fallback im Produktivbetrieb folgen Sie dem CometAPI model fallback guide, um Routen zu wechseln, ohne bereits ausgeführte Tool-Aufrufe zu wiederholen oder validierten Zustand zu verwerfen.
Einheitlicher Zugriff vereinfacht den Modellvergleich und die Fallback-Integration. Token-Budgets, Verdichtung, Validierung, Tool-Filterung, Retry-Grenzen und Abnahmekriterien gehören dennoch auf die Anwendungsebene.
FAQ
Why do AI agents use more tokens than chatbots?
Agenten führen mehrere Modellaufrufe aus und können bei jedem Schritt frühere Nachrichten, Tool-Ergebnisse, Anweisungen und Zwischenzustände erneut senden. Dadurch wird früherer Kontext wiederholt verarbeitet.
Does prompt caching reduce context-window usage?
Nein. Prompt-Caching kann den effektiven Preis oder die Latenz wiederholter Eingaben senken, aber gecachte Token sind weiterhin Teil des verarbeiteten Kontexts. Verwenden Sie Verdichtung, Filterung oder selektiven Abruf, um die Prompt-Größe zu reduzieren.
When should an AI agent compact its context?
Verdichten Sie, bevor das Kontextwachstum Kosten, Latenz oder verfügbaren Ausgaberaum beeinflusst. Vergewissern Sie sich, dass der verdichtete Zustand Entscheidungen, Evidenz-IDs, geänderte Dateien, offene Fragen und Sicherheits-Constraints bewahrt.
Do subagents reduce token costs?
Nicht automatisch. Sie können die verstrichene Zeit reduzieren oder die Abdeckung unabhängiger Arbeit verbessern, aber duplizierter Kontext und überlappende Analysen erhöhen oft den gesamten Token-Verbrauch.
What is the best metric for AI agent cost optimization?
Verwenden Sie Kosten pro erfolgreicher Aufgabe als primäre Kennzahl. Diagnostizieren Sie sie mit kumulativer Eingabe, Kontextverstärkung, Tool-Beibehaltung, Retry-Steuer, Reasoning-Anteil, Latenz und Zeit für menschliche Prüfung.
