Kontextkosten von KI-Agenten: Wiederholte Prompts und Tool Calls messen
Praxisleitfaden zur Messung und Optimierung der Kontextkosten in mehrstufigen KI-Agenten: Tool-Schemas, Baseline-Messung und Qualitätskontrolle.
Inhalt
Bei der Entwicklung von KI-Agenten (Claude Code, Cline, Roo Code oder eigenen Multi-Step-Pipelines) können die API-Kosten mit wachsendem Kontext steigen. Welche Bestandteile eine einzelne Anfrage hat, hängt vom Client ab: Sie kann System-Prompt, Schemata verfügbarer Tools, Nachrichtenverlauf und Ergebnisse von Funktionsaufrufen enthalten.
Um das Budget ohne Funktionsverlust zu steuern, brauchen Sie eine Baseline für eine feste Aufgabe, müssen die wichtigste Quelle überflüssiger Tokens eingrenzen und die Agentenumgebung jeweils nur in einer Variablen optimieren.
Anatomie des KI-Agentenkontexts: Wofür Tokens bei jedem Schritt anfallen
Für die Messung lässt sich der an das Modell gesendete Kontext in vier beobachtbare Komponenten teilen:
- Systemanweisungen und Regeln (System Prompt): Grundanforderungen an Stil, Sicherheitsgrenzen und Repository-Kontext.
- Tool-Schemas (Tool Schemas): JSON-Beschreibungen verbundener Funktionen, Parameter und Datentypen, sofern der Client sie in die Anfrage aufnimmt.
- Nachrichtenverlauf (Message History): Frühere Nutzernachrichten und Agentenantworten, die sich während der Aufgabe ansammeln.
- Tool-Ergebnisse (Tool Outputs): Inhalte gelesener Dateien, Logs ausgeführter Terminalbefehle und API-Dumps.
Multiplizieren Sie die Größe der ersten Anfrage nicht blind mit der Zahl der Schritte. Exportieren Sie die Usage jedes Calls: Der Verlauf kann wachsen, der Client kann Daten kürzen und der Provider kann cached Tokens getrennt abrechnen.
Vergleichstabelle: Kontextquellen und ihre Optimierung
| Kontextkomponente | Was messen? | Hauptrisiko für Mehrkosten | Änderung für einen isolierten Test |
|---|---|---|---|
| Tool-Schemas | Größe der tatsächlich übermittelten Liste | Nicht verwendete Tools im gemeinsamen Satz | Nur für die Aufgabe nötige Tools behalten |
| Tool-Ergebnisse | Größe jedes Ergebnisses | Ganze Dateien statt gezielter Ausschnitte lesen | Zeilenbereiche und Log-Umfang begrenzen |
| Schrittverlauf | Input-Wachstum von Call zu Call | Nicht mehr benötigte Ergebnisse sammeln sich an | Vom Client unterstützte Verlaufskürzung prüfen |
| System Prompt | Größe und Stabilität des Präfixes | Wiederholte Anweisungen | Duplikate entfernen, Pflichtregeln erhalten |
Schritt für Schritt: Baseline messen und Ausgaben senken
Halten Sie zuerst die aktuellen Modellpreise fest. Verwenden Sie für die Baseline die aktuellen BetterToken-Preise und keine Werte aus alten Beispielen. Aktuelle BetterToken-Preise ansehen
Für eine objektive Optimierung nutzen Sie Messungen mit jeweils nur einer Variablen:
Schritt 1. Eine Kontrollaufgabe für den Test festlegen
Wählen Sie ein reproduzierbares Engineering-Szenario, zum Beispiel: „Eine Validierungsfunktion im Repository finden, einen Edge Case behandeln und Unit-Tests ausführen.“ Die Aufgabe braucht ein klares Abschlusskriterium, etwa Exit-Code 0 bei pytest oder bun test.
Schritt 2. Baseline messen (Input, Output, Cache)
Führen Sie die Aufgabe in der Standardkonfiguration des Agenten aus. Halten Sie in Logs oder im Monitoring fest:
- Anzahl ausgeführter Schritte;
- gesamten Input-Token-Umfang;
- gesamten Output-Token-Umfang;
- Umfang gecachter Tokens (
cached tokens); - Kosten nach den aktuellen Preisen.
Die aktuellen Preise des gewählten Modells prüfen Sie auf der BetterToken-Preisseite. In Workspace können Sie für eine angenommene Anfrage Modell, Zeitpunkt und Status, Input-/Output-Tokens, bei unterstützten Modellen cached Tokens sowie die Kosten des Calls prüfen. Erzeugt ein Agentenschritt mehrere Anfragen, darf ein Eintrag auf Anfrageebene nicht als fertige Aufschlüsselung nach Schritten gelten: Ordnen Sie sie über Zeitpunkt und Daten Ihres eigenen Clients zu.
Schritt 3. Eine Kontextvariable ändern
Führen Sie isolierte Tests aus und ändern Sie pro Iteration genau einen Parameter:
- Experiment A (Tool Filtering): Lassen Sie nur die für die Kontrollaufgabe nötigen Tools aktiv und messen Sie die Differenz bei den Input-Tokens.
- Experiment B (Output Truncation): Begrenzen Sie die Terminalausgabe auf die ersten 50 Zeilen eines Fehlers statt auf einen vollständigen Dump mit 2.000 Zeilen.
- Experiment C (Prefix Stability): Falls Modell und Endpoint Prompt Caching unterstützen, halten Sie die Reihenfolge von System Prompt und Tool-Schemas unverändert und prüfen anschließend die tatsächlich ausgewiesenen cached Tokens.
Schritt 4. Wirtschaftlichkeit und Lösungsqualität bewerten
Vergleichen Sie die finalen Kennzahlen mit der ursprünglichen Baseline. Behalten Sie eine Änderung nur bei, wenn die Kontrollaufgabe weiterhin dasselbe Qualitätskriterium erfüllt und sich die gemessene Zeit oder der Verbrauch in Ihrer Reihe von Läufen verbessert.
Empfehlungen für die Einrichtung von Agentenumgebungen
- Tools nach Rolle eingrenzen: Ein Agent zum Lesen braucht keine Schreibfunktionen; prüfen Sie, ob das den tatsächlichen Input ohne Ergebnisverlust senkt.
- Stabiles Präfix bewahren: Wenn Caching unterstützt wird, ändern Sie die Reihenfolge gemeinsamer Regeln nicht ohne Grund und prüfen Sie cached Tokens, statt einen Rabatt anzunehmen.
- Schleife begrenzen: Legen Sie eine endliche Zahl von Versuchen und eine zur konkreten Aufgabe passende klare Abbruchbedingung fest.
Grenzfälle und häufige Fehler
- Fehler: kritische Validierungsschemas abschalten. Wird die Beschreibung eines Tool-Schemas zu stark gekürzt, kann das Modell ungültiges JSON senden und eine Kette wiederholter Anfragen auslösen.
- Fehler: Einsparversprechen aus sozialen Netzwerken blind vertrauen. Die Wirkung der Kontextoptimierung hängt von der Struktur Ihres Repositories und der durchschnittlichen Dateigröße ab.
- Fehler: fehlende transparente Telemetrie. Liefert der Endpoint keine getrennte Statistik für Input- und Cache-Tokens, schätzen Sie die Cache-Nutzung nicht anhand von Annahmen; markieren Sie den Wert als unbekannt.
