Zeit- und Kostenbudget für Modellaufrufe in Agenten

Ziel

Vor dem Ausrollen wissen, was ein Lauf des Agenten kostet und wie lange Nutzerinnen warten, beides im Code begrenzen und sehen, wenn eine Änderung eines von beiden verschiebt.

Voraussetzungen

Die Verbrauchsfelder, die der Anbieter pro Aufruf zurückgibt. Die zitierte Herstellerdokumentation zum Prompt-Caching beschreibt im usage-Objekt input_tokens, cache_creation_input_tokens und cache_read_input_tokens; die Summe der drei ist die tatsächliche Eingabemenge. Dazu eine Preisliste der eingesetzten Modelle, ein Auswertungssatz mit typischen Aufgaben und Laufprotokolle, die Kosten einzelnen Schritten zuordnen.

Schritte

1. Grundlinie messen: pro Lauf auf dem Auswertungssatz die Zahl der Modellaufrufe, Eingabe- und Ausgabetoken, Gesamtdauer und den längsten einzelnen Aufruf festhalten.
2. Budgets pro Lauf setzen – Tokenobergrenze, Schrittobergrenze, Frist – und in der Schleife durchsetzen. Ist ein Budget erreicht, bekommt der Agent eine letzte Runde, um zu berichten, was erledigt ist und was nicht; ein abgebrochener Lauf ohne Bericht ist verlorene Arbeit.
3. Eingabetoken zuerst senken: Systemprompt, Werkzeugdefinitionen und Referenzdokumente an den Anfang stellen und für das Caching markieren. Die Dokumentation beschreibt eine Standardlebensdauer von fünf Minuten, die bei jeder Nutzung ohne Zusatzkosten erneuert wird, eine Stunde gegen Aufpreis, sowie die Reihenfolge tools → system → messages, bei der eine Änderung auf einer Stufe alle folgenden Stufen ungültig macht. Zeitstempel und Werte pro Anfrage gehören deshalb hinter den gecachten Teil; ob das Caching greift, zeigt cache_read_input_tokens.
4. Ausgabetoken senken: die kürzeste Ausgabe verlangen, die der nächste Schritt verarbeiten kann – einen Werkzeugaufruf, eine Kennung, strukturierte Daten –, keine Erzählung.
5. Kontext beschneiden: alte Werkzeugergebnisse zusammenfassen oder weglassen, statt sie bei jedem Schritt erneut zu senden.
6. Offline-Arbeit (Auswertungsläufe, nächtliche Extraktion) auf den Batch-Endpunkt legen. Die zitierte Batch-Dokumentation nennt 50 Prozent des Standardpreises, meist Abschluss innerhalb einer Stunde, Verfall nach 24 Stunden ohne Abschluss und Ergebnisse, die 29 Tage abrufbar bleiben.
7. Ein kleineres Modell nur dort einsetzen, wo der Auswertungssatz zeigt, dass es die Aufgabe besteht; Kosten pro abgeschlossener Aufgabe vergleichen, nicht pro Aufruf.
8. Alarmieren auf Kosten pro erledigter Aufgabe und auf die Latenz beim 95. Perzentil, nicht nur auf die Gesamtausgaben.

Erwartetes Ergebnis

Dokumentierte Kosten und Latenz je Aufgabentyp, im Code erzwungene Budgets und ein Dashboard, auf dem eine Prompt-Änderung, die den Tokenverbrauch verdoppelt, am selben Tag auffällt.

Grenzen und Prüfbasis

Preise, Cache-Lebensdauern und Batch-Bedingungen sind Anbieterangaben und ändern sich; die Zahlen stammen aus der zitierten Dokumentation zum Zeitpunkt des Schreibens. Batch-Verarbeitung taugt nicht für interaktive Nutzung. Budgets stoppen ausufernde Läufe, machen sie aber nicht billiger; das leisten nur die Schritte 3 bis 7.

Kontext beschneiden, ohne den Cache zu verlieren

Das Prompt-Caching vergleicht Präfixe: Jede Änderung an einer früheren Nachricht macht den Cache ab dieser Stelle ungültig. Wer den Verlauf in jeder Runde kürzt, bezahlt in jeder Runde den Rest des Verlaufs neu und zusätzlich den Schreibaufschlag für den neuen Eintrag. Deshalb: Werkzeugergebnisse von Anfang an klein halten (Kopf statt ganze Datei, Zähler statt Liste, Verweis statt Inhalt), den Verlauf nur an wenigen definierten Schwellen beschneiden und dann in einem Schritt, damit der neue Präfix wieder mehrere Runden lang stabil ist, und den Erfolg an cache_read_input_tokens prüfen, das nach jeder Runde wachsen soll. Serverseitige Varianten wie Context Editing und Kompaktierung arbeiten aus demselben Grund mit Schwellen.