GPT-5.6 Luna price down 80%, Terra down 20% →

So reduzieren Sie die Token-Kosten von KI-Agenten im Produktivbetrieb

CometAPI
Mia MarenAug 5, 2026
So reduzieren Sie die Token-Kosten von KI-Agenten im Produktivbetrieb

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 sourceWhat causes itFirst control to test
Repeated instructionsSystem prompts, tool schemas, policies, examplesStabilize the reusable prefix
Growing historyEarlier turns are resent at each stepCompact or selectively retrieve state
Tool resultsSearch pages, files, logs, and database recordsFilter before adding them to context
Intermediate outputPlans, status messages, and verbose tool decisionsUse compact structured outputs
Reasoning tokensHigh reasoning effort on routine stepsMatch effort to task complexity
RetriesInvalid output, timeouts, tool errors, and rate limitsClassify failures and cap retries
SubagentsWorkers duplicate context, tools, and analysisSend each worker a narrow context slice

Es gibt zwei unterschiedliche Wege, die Rechnung zu reduzieren:

  1. Weniger Token verarbeiten durch Filterung, Verdichtung, Ausgabelimits und Loop-Kontrollen.
  2. 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:

  1. Das stabile Präfix mit 4.000 Token nach dem ersten Aufruf cachen.
  2. Den Verlauf nach Schritt sechs in einen 2.500-Token-Zustand verdichten.
ScenarioUncached inputCached inputTotal processed inputChange
Full history on every step147,0000147,000Baseline
Stable prefix cached103,00044,000147,000Same volume, cheaper mix
Cache plus compaction64,00044,000108,00026.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.

Bild

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:

FieldWhy it matters
run_id, step_id, parent_step_idRekonstruiert den Agenten- und Subagenten-Baum
Rendered input tokensZeigt, wie der Kontext zwischen Aufrufen wächst
Cached and uncached inputTrennt Wiederverwendung von neuem Kontext
Output and reasoning tokensIdentifiziert teure Generierungsschritte
Tool result size and retained tokensZeigt, wie viel Roh-Evidenz in spätere Prompts gelangt
Retry reason and attempt numberIdentifiziert wiederholte Fehler
Compaction tokens before and afterMisst die tatsächliche Kontextreduktion
Worker ID and returned tokensDeckt doppelte Subagenten-Arbeit auf
Accepted, rejected, or escalated resultVerknü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.

FailureBetter response
Invalid structured outputValidierungsfehler zurückgeben und einmal erneut versuchen
Tool timeoutEine idempotente Operation einmal wiederholen, dann stoppen oder Fallback nutzen
Context overflowZustand verdichten oder weniger Evidenz abrufen
Repeated tool callMit einem Operations-Hash deduplizieren
Rate limitBackoff oder getestete Fallback-Route nutzen
Low-confidence resultFehlende 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 signalStart here
Context amplification is highVerlauf verdichten und Zustand selektiv abrufen
Tool output dominates the promptFelder filtern und vollständige Artefakte extern speichern
Retry tax is highValidierung, Timeouts und wiederholte Tool-Aufrufe beheben
Reasoning share is highAufwand bei Routine-Schritten senken
Subagents repeat the same evidenceWorker-Scopes und Kontextausschnitte verengen
Cached input remains lowWiederverwendbares Präfix stabilisieren
Costs remain high after loop cleanupGünstigere Modellrouten vergleichen

Eine sichere Implementierungsreihenfolge ist:

  1. Kumulative Eingabe, Tool-Beibehaltung, Retries und Reasoning messen.
  2. Harte Limits für Schritte, Tools, Retries und Gesamt-Token hinzufügen.
  3. Große Tool-Ergebnisse filtern.
  4. Älteren Zustand ab einem gemessenen Schwellwert verdichten.
  5. Das wiederverwendbare Prompt-Präfix stabilisieren.
  6. 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.

Bereit, die KI-Entwicklungskosten um 20 % zu senken?

In wenigen Minuten kostenlos starten. Inklusive kostenlosem Testguthaben. Keine Kreditkarte erforderlich.

Mehr lesen