AI-Agent-Kosten kontrollieren: Modell-Routing, Tool-Budgets, Caching und Retry-Limits

Um 3 Uhr morgens liefert ein Hintergrund-report-Agent eine leere Antwort. Der HTTP-Status ist 200, aber der body ist leer. Die Retry-Logik prueft nur den Statuscode und versucht es weiter. Jede Anfrage sendet 500 input tokens. Nach 1.500 Retries sind 750.000 Tokens verbraucht. Die Rechnung am naechsten Morgen ist dann der eigentliche Alarm.

Die Ursache ist nicht “das Modell war zu teuer”. Es fehlten drei Dinge: Circuit Breaker, Budgetpruefung und Fehlerklassifikation. Agent-Kosten laufen typischerweise in drei Mustern aus dem Ruder:

Unbegrenzte Retries. Fehlermodi werden nicht klassifiziert, also gilt eine leere Antwort als retryable error. Es gibt keinen Circuit Breaker, daher stoppen auch 1.500 Fehlversuche nicht. Jeder Retry sendet den kompletten Kontext erneut und vervielfacht die Kosten um 2-5x.

Aufgeblaehter Kontext. Ein Langlaeufer laeuft 6 Stunden und die Conversation History waechst auf 80K tokens. Ohne checkpoint startet der Task nach einem Fehler von vorn und jeder Schritt wird erneut bezahlt.

Modell-Uebernutzung. Alle Aufgaben laufen auf einem frontier model, weil es keine Routing-Strategie gibt. Selbst einfache Klassifikation nutzt den teuersten Pfad und verschwendet 70% der Tokens.

Kostenkontrolle fuer AI-Agents ist keine Einzeloptimierung. Sie besteht aus mehreren Schichten: Budget-Objekten, Routing-Strategie, Cache-Hits, Retry-Circuit-Breakern, Kostenlogs und Alert-Schwellen. Diese sechs Engineering-Objekte sollten als Entscheidungstabellen oder ausfuehrbare Checks enden.

Budget-Objekte: Was Sie erfassen, wo Sie es speichern und wann Sie abbrechen

Kostenkontrolle beginnt mit einem Budget-Objekt. Eine Gesamtsumme reicht nicht. Ohne Aufteilung koennen Sie bei einer Rechnungsspitze nicht erkennen, welcher Nutzer, welcher Task oder welches Tool die Kosten verursacht hat.

Sieben Budget-Ebenen

Budget-Objekte lassen sich von grob nach fein in sieben Ebenen aufteilen:

Budget-Ebene	Budget-Objekt	Empfohlene Obergrenze	Alert-Ausloeser
Layer 1	user	Tages-/Monatslimit pro Nutzer	Alert bei Restbudget < 20%
Layer 2	tenant	Eigener Budgetpool pro Tenant	Alert bei Restbudget < 30%
Layer 3	workflow	Eigenes Budget pro Workflow-Typ	Alert bei Restbudget < 40%
Layer 4	task	Eigenes Budget pro Task-Typ	Alert bei Restbudget < 50%
Layer 5	tool	Eigenes Budget pro Tool-Aufruf	Tool bei Ueberschreitung ueberspringen
Layer 6	retry	Retry-Limit + Circuit Breaker	Tool nach N Folgefehlern deaktivieren
Layer 7	cache	Cache-Hit-Rate beobachten	Alert, wenn Hit-Rate unter Erwartung liegt

Die konkreten Limits haengen vom Geschaeftsmodell ab und sind veraenderliche Konfiguration. Die Schichtstruktur ist stabiler. Das Feld fuer Restbudget gehoert in die Kostenlogs, damit Alerts und Circuit Breaker darauf zugreifen koennen.

Felder, die jede Ebene erfassen sollte

Jede Budget-Ebene sollte diese Felder erfassen:

Feldname	Zweck	Typ	Warum es noetig ist
model	Modell identifizieren	string	Zeigt, ob das Modell-Routing passt
inputTokens	Input-Token-Zahl	integer	Berechnet Input-Kosten
outputTokens	Output-Token-Zahl	integer	Output-Kosten unterscheiden sich und muessen separat erfasst werden
cachedTokens	Cache-hit Tokens	integer	Misst Cache-Ersparnis
costEstimate	Kostenschaetzung fuer diesen Aufruf	float	Ermoeglicht laufende Kostenakkumulation
budgetRemaining	Restbudget	float	Grundlage fuer Circuit-Breaker-Entscheidungen

Der Kern ist Buchhaltung nach Dimensionen, nicht “nur total_cost speichern”. In Multi-Tenant-Systemen muessen Kosten nach tenantId verteilt werden. Bei vielen Tools ist toolName der Weg, die Blackbox zu finden.

Circuit-Breaker-Logik

Wenn das Restbudget unter einen Schwellwert faellt, greift der Circuit Breaker:

def check_budget_before_retry(budget_remaining, retry_cost_estimate):
    if budget_remaining < retry_cost_estimate:
        return "skip_retry"  # Retry ueberspringen, weil er das Budget sprengen wuerde
    if budget_remaining < threshold:  # threshold zum Beispiel 20%
        return "wait_approval"  # Restbudget ist niedrig, Freigabe abwarten
    return "continue"

Die Logik prueft das Restbudget vor dem Retry, nicht erst danach. Schaetzen Sie vor jedem Retry die Kosten und stoppen Sie, wenn der naechste Versuch das Budget sprengen wuerde. So verhindern Sie den Fall “leere Antwort 1.500-mal wiederholt”.

Welche Kontextteile in einen stabilen prefix gehoeren und welche nur Laufzeitvariablen sind, behandelt der Kontext-Engineering-Artikel derselben Serie.

Modell-Routing: Nicht jede Aufgabe braucht das teuerste Modell

Ein ticket triage Agent hat oft diese Verteilung: 70% einfache Klassifikation, 20% Entwurf einer Antwort, und nur 10% sollten vor einer Kundenmail auf ein frontier model hochgestuft werden. Eine Routing-Strategie kann 40-85% Kosten sparen.

Modell-Ebenen-Routing

Routen Sie nach Aufgabenkomplexitaet:

Task-Ebene	Typische Aufgaben	Empfohlene Modell-Ebene	Anteil	Kostenprofil
70% - S-Stufe	Klassifikation, Extraktion, Filterung, einfache Q&A	nano/flash (guenstigste Stufe)	70%	Kurzer Output, wenige Turns, wenige Tool-Aufrufe
20% - M-Stufe	Entwurf, Zusammenfassung, Codegenerierung, mittlere Schlussfolgerung	mid-tier (mittlere Kosten)	20%	Mittlere Output-Laenge, moegliche Tool-Nutzung
10% - L-Stufe	Review, Architekturdesign, komplexe Schlussfolgerung, Koordination mehrerer Tools	frontier (teuerste Stufe)	10%	Langer Output, viele Turns, haeufige Tool-Aufrufe

Die Routing-Strategie hat drei Schritte:

Schritt 1: Aufgabe einstufen. Definieren Sie fuer jeden workflow S/M/L-Kriterien: Output-Laenge, Tool-Call-Anzahl, reasoning depth und Risikostufe.

Schritt 2: Standardmaessig S-Stufe nutzen. Nur wenn komplexe Merkmale auftreten, wird auf M oder L hochgestuft.

Schritt 3: Kaskadisch routen. Wenn S scheitert, auf M hochstufen. Wenn M scheitert, auf L hochstufen. Wenn L scheitert, menschliche Intervention. Vor jeder Hochstufung das Restbudget pruefen und bei Budgetueberschreitung nicht hochstufen.

Service-Tier-Routing

Dasselbe Modell kann auch nach latency priority verzweigen. Rabatte und Fertigstellungsfenster sind veraenderliche Fakten; pruefen Sie offizielle Preise vor der Veroeffentlichung.

Service-Tier	Kostenrabatt	Fertigstellungszeit	Geeignete Nutzung
Realtime API	Kein Rabatt	Sofortige Antwort	Interaktive Agent-Chats, hohe Prioritaet
Batch API	50% cost discount (vor Veroeffentlichung pruefen)	24-hour turnaround (vor Veroeffentlichung pruefen)	Batch-Evals, Klassifikation, Embeddings, Repository-Verarbeitung
Flex Processing	Niedrigere Kosten (vor Veroeffentlichung pruefen)	Langsamere Antwort, gelegentlich nicht verfuegbar	Niedrige Prioritaet, asynchrone Tasks, model evaluations, data enrichment

Checkliste fuer Offline-Routing:

• Braucht die Aufgabe sofortige Antwort? Ja -> Realtime API mit Modell-Routing.
• Kann sie 24 Stunden warten? Ja -> Batch API.
• Hat sie niedrige Prioritaet und toleriert gelegentliche Fehler? Ja -> Flex Processing.
• Ist es Batch-Arbeit wie eval, Klassifikation oder embedding? Ja -> Batch API.

Risikostufen

Aufgaben werden auch nach Risiko geroutet:

Risikostufe	Typische Operation	Routing-Strategie	Budget-Zweig
Niedriges Risiko	Klassifikation, Extraktion, interne Zusammenfassung	S-Stufe + automatischer Pfad	Keine Freigabe, lockeres Budgetlimit
Mittleres Risiko	Kundenantwort entwerfen, Codeaenderung vorschlagen	M-Stufe + optionale Freigabe	Bei Budgetueberschreitung Freigabe anfordern
Hohes Risiko	Kundenmail senden, Zahlung ausloesen, Architektur aendern	L-Stufe + Pflichtfreigabe	Freigabe-Warten, Ablehnung und Timeout werden Budget-Zweige

Wie Wartezeit, Ablehnung und Timeout bei Freigaben die Budgetzweige beeinflussen, behandelt der Human-in-the-Loop-Artikel derselben Serie.

Wichtige Constraints

Routing braucht klare Constraints:

• Keine Preise hart codieren: Preise sind veraenderlich. Speichern Sie model + pricingVersion, statt eine Kostenformel in Business-Logik einzubrennen.
• Restbudget pruefen: Vor dem Upgrade budgetRemaining pruefen. Bei Ueberschreitung Upgrade ueberspringen oder Freigabe anfordern.
• Fehler klassifizieren: Routing-Fehler muessen recoverable Modellgrenzen von unrecoverable Parameterfehlern oder Permission Denials trennen.

Tool-Call-Budgets: per-tool budget, timeout und Retry-Limits

Tool-Aufrufe haben Schema- und API-Kosten. Jeder Aufruf sendet Schema, Argumente und Kontext fuer Response-Parsing; externe APIs koennen ausserdem rate-limiten oder timeouts liefern. Diese Kosten stehen neben dem Modellaufruf.

Tool-Budget-Kontrolle

Jedes Tool bekommt eigene Budgetkontrollen:

Kontrolle	Empfohlene Konfiguration	Monitoring-Feld	Ausgeloeste Aktion
Per-tool budget	Limit pro Aufruf	tool_cost_estimate	Tool ueberspringen oder degradieren
Tool timeout	Timeout fuer externe API	tool_duration	Timeout als retryable error markieren
Retry limit per tool	Retry-Limit pro Tool	tool_retry_count	Tool aufgeben, nicht in Retry-Schleife laufen

Tools fuer externe APIs, etwa Suche, Datenbanken oder Drittanbieter, brauchen eigene Buchhaltung. Sonst wird Tool Calling zur Kosten-Blackbox.

Tool-Fehler klassifizieren

Tool-Fehler teilen sich in recoverable und unrecoverable cases:

Fehlertyp	Typische Fehler	Strategie	Kostenwirkung
Recoverable failure	Netzwerk-Timeout, 503 Service Unavailable, 429 Rate Limit	Automatisch mit Exponential Backoff und retry-after wiederholen	Jeder Retry sendet kompletten Kontext
Unrecoverable failure	403 Permission Denied, 400 Bad Request, fehlendes Tool	Nicht wiederholen, Fehler dem Modell zur Entscheidung geben	Kein Retry, keine wiederholte Verschwendung

Die Regel: Nur temporaere Fehler aus externen Bedingungen werden wiederholt. Interne Konfigurationsfehler werden nicht wiederholt.

Circuit Breaker

Nach N Folgefehlern deaktiviert der Breaker das Tool:

def circuit_breaker_tool(tool_name, consecutive_failures, threshold=5):
    if consecutive_failures >= threshold:
        return "disable_tool"  # Tool deaktivieren
    return "continue"

Der Zustand des Circuit Breakers gehoert ins Log, damit Sie spaeter erklaeren koennen, warum ein Tool deaktiviert wurde. Nach dem Ausloesen warten Sie auf menschliche Intervention oder einen automatischen Recovery-Check, statt ein instabiles Tool weiter aufzurufen.

Grundlagen zu Tool Calling stehen in Tool Calling. Dieser Artikel erweitert sie um per-tool budgets, timeouts und Retry-Limits.

Prompt-Caching-Design: Stabiler Prefix, variable Positionen und 1024-Token-Schwelle

Prompt Caching optimiert Input-Token-Kosten fuer einen stabilen prompt prefix. Es ist kein Business-Result-Cache. Requests mit demselben prompt prefix werden zu einem Server geroutet, der diesen Prefix kuerzlich verarbeitet hat; das kann Latenz und Input-Kosten senken.

Prompt Caching ist kein Result-Cache

Prompt Caching speichert den stabilen prompt prefix, nicht das Business-Ergebnis. Der Unterschied ist wichtig:

• Prompt Caching: speichert einen stabilen prompt prefix wie system prompt oder tool schema. Ein Hit spart input tokens, aber die Inferenz laeuft trotzdem.
• Business-Result-Cache: speichert vollstaendige Ausgaben wie Tool-Ergebnisse oder Datenbankabfragen. Ein Hit wird direkt zurueckgegeben und ruft kein Modell auf.

Die Ziele sind verschieden: Prompt Caching optimiert Input-Token-Kosten, Business-Caching optimiert den kompletten Aufruf. Beides kann zusammenlaufen: stabile Prefixe ueber Prompt Caching, haeufige Tool-Ergebnisse ueber Business-Cache.

Strukturelle Anforderungen

Entscheidend ist die Trennung von stabilem Prefix und Laufzeitvariablen:

Inhaltstyp	Position	Cache-Hit-Wahrscheinlichkeit	Typische Inhalte
Stabiler Prefix (geht in den Cache)	Anfang des Prompts	Hoch	System prompt, Tool schema, Policy-Dokumente, Few-shot-Beispiele
Laufzeitvariablen (nicht in den Cache)	Spaeter im Prompt	Niedrig	User input, File fragments, Runtime state wie aktueller Turn und temporaere Variablen

Design-Schritte:

1. System prompt, Tool schema und Policy nach vorne legen: Diese Inhalte bleiben ueber mehrere Aufrufe stabil und treffen leichter den Cache.
2. User input, File fragments und Runtime state nach hinten legen: Diese Inhalte aendern sich jedes Mal und gehoeren nicht in den stabilen Prefix.
3. Cache hit rate beobachten: cachedTokens und gesamte input tokens erfassen, dann Hit-Rate berechnen. Ueber 40% ist gesund, unter 20% sollten Sie die Prompt-Struktur pruefen.

Schwelle und Wirkung

Die automatische Schwelle und Wirkung von Prompt Caching sind veraenderliche Fakten. Pruefen Sie die offiziellen Docs vor der Veroeffentlichung:

• Schwelle: ab 1024 tokens automatisch aktiviert (vor Veroeffentlichung pruefen).
• Wirkung: Hits koennen Kosten und Latenz senken (konkrete Werte pruefen).
• Hit pruefen: Feld usage.prompt_tokens_details.cached_tokens.

Unterstuetzte Modelle, Schwellen und Rabatte fuer Prompt Caching koennen sich aendern. Pruefen Sie sie gegen die offizielle Pricing-Seite. Das stabile Prinzip bleibt: statische Inhalte nach vorn, variable Inhalte nach hinten.

Retry-Circuit-Breaker: Idempotenz, Checkpoints und Restbudget

Retries sind eine der groessten Quellen fuer ausufernde Kosten. Wenn ein report-Agent an einem instabilen Tool haengt und bei jedem Fehler den kompletten Kontext erneut sendet, liegt der Task nach 1.500 Retries weit ausserhalb des normalen Kostenpfads.

Budget vor dem Retry pruefen

Pruefen Sie das Restbudget vor dem Retry, nicht danach:

def should_retry(error_type, budget_remaining, retry_cost_estimate):
    # Fehlerklassifikation
    if error_type in ["403", "400", "tool_not_exist"]:
        return False  # Unrecoverable error, nicht wiederholen

    # Budgetpruefung
    if budget_remaining < retry_cost_estimate:
        return False  # Ueber Budget, nicht wiederholen

    return True  # Retry moeglich

Die Budgetpruefung gehoert vor die Retry-Logik. So verhindern Sie, dass eine leere Antwort 1.500-mal wiederholt und ein Tagesbudget verbraucht wird.

Idempotenz

Retries duerfen Nebenwirkungen wie E-Mails oder Zahlungen nicht doppelt ausfuehren:

• Tool-Aufrufe nutzen eine Idempotenz-ID wie requestId. Wenn die externe API dieselbe ID erneut erhaelt, liefert sie das gecachte Ergebnis statt die Operation erneut auszufuehren.
• Die Idempotenz-ID gehoert ins Kostenlog, damit doppelte Aufrufe nachvollziehbar sind.

Der Kern von Idempotenz: dieselbe Operation sollte nicht zweimal Kosten und Nebenwirkungen erzeugen.

Zustand speichern (Checkpoint)

Lang laufende Tasks sollten nicht den ganzen Workflow neu starten:

• Speichern Sie an wichtigen Knoten einen checkpoint mit erledigten Schritten, aktuellem Zustand und Kontextzusammenfassung.
• Nach einem Fehler geht es vom checkpoint weiter, nicht von vorn.
• Persistieren Sie den checkpoint. Nur im Speicher reicht nicht.

Checkpoint- und Thread-State-Design behandelt LangGraph Agent Architecture.

Retry-Strategie

Verschiedene Fehlertypen brauchen verschiedene Retry-Strategien:

Fehlertyp	Typischer Fehler	Retry-Strategie	Kostenwirkung
Netzwerk-Timeout	10 Sekunden ohne Antwort	Exponential Backoff + retry-after, maximal 3 Retries	Jeder Retry sendet kompletten Kontext
503/429	Service Unavailable, Rate Limit	Rate-Limit-Fenster + retry-after abwarten, maximal 3 Retries	Warten verbraucht keine Tokens, der Retry schon
403/400	Permission Denied, Bad Request	Nicht wiederholen, Fehler dem Modell geben	Kein Retry, vermeidet ungueltige Kosten

Die Regel lautet: Nur recoverable errors werden wiederholt. Ungueltige Requests gehoeren nicht immer wieder zurueck zum Modell.

Circuit Breaker

Nach N Folgefehlern stoppt der Retry und wartet auf Intervention:

def circuit_breaker(consecutive_failures, threshold=5):
    if consecutive_failures >= threshold:
        return "stop_retry"  # Retry stoppen
    return "continue"

Die Circuit-Breaker-Entscheidung gehoert ins Log, damit Sie erklaeren koennen, warum Retries gestoppt wurden. Danach warten Sie auf menschliche Intervention oder Budgeterholung, statt instabile Tools oder Modelle weiter aufzurufen.

Kostenlogs und Alerts: Welche Felder und welche Schwellwerte

Kostenbeobachtung ist die Voraussetzung fuer Kostenkontrolle. Sind die Logfelder unvollstaendig, finden Sie die Ursache nicht.

OpenTelemetry trace span attributes

Kostenlogs lassen sich in drei Span-Ebenen entwerfen:

Agent run span (oberste Ebene):

Feldname	Zweck	Typ	Warum es noetig ist
runId	Konkrete Ausfuehrung identifizieren	string	Trennt mehrere Laeufe desselben Workflows
tenantId	Tenant identifizieren	string	Verteilt Kosten in Multi-Tenant-Systemen
userId	Nutzer identifizieren	string	Zeigt Kostentrends pro Nutzer
workflowName	Workflow identifizieren	string	Erfasst Kosten nach Workflow-Typ
totalCost	Gesamtkostenschaetzung	float	Ermoeglicht laufende Kostenakkumulation
budgetRemaining	Restbudget	float	Grundlage fuer Circuit Breaker
totalRetries	Gesamtzahl der Retries	integer	Zeigt Retry-Verstaerkung

Model call span (Kind-Span):

Feldname	Zweck	Typ	Warum es noetig ist
model	Modell identifizieren	string	Zeigt, ob Modell-Routing passt
pricingVersion	Pricing-Version	string	Verhindert hart codierte Kostenformeln
inputTokens	Input-Token-Zahl	integer	Berechnet Input-Kosten
outputTokens	Output-Token-Zahl	integer	Erfasst Output-Kosten separat
cachedTokens	Cache-hit Tokens	integer	Misst Cache-Ersparnis
costEstimate	Kostenschaetzung dieses Aufrufs	float	Ermoeglicht laufende Kostenakkumulation
latencyMs	Aufruflatenz	integer	Hilft zu entscheiden, ob Batch/Flex passt

Tool call span (Kind-Span):

Feldname	Zweck	Typ	Warum es noetig ist
toolName	Tool identifizieren	string	Identifiziert Tool-Call-Overhead
toolBudget	Tool-Budgetlimit	float	Grundlage fuer Circuit Breaker
toolTimeout	Tool-Timeout	integer	Klassifiziert Timeout-Fehler
retryCount	Retry-Anzahl	integer	Zeigt Retry-Verstaerkung
errorType	Fehlertyp	string	Trennt recoverable und unrecoverable failures

Speichern Sie nicht nur total_cost. Zerlegen Sie Kosten nach Dimensionen. Ohne diese Felder sagt eine Rechnungsspitze nur “ueber Budget”; sie sagt nicht, welcher Nutzer, welches Tool oder welcher Retry-Pfad schuld war.

Das vollstaendige Design fuer Logs, Alerts und Recovery steht in Agent Monitoring and Recovery. Dieser Artikel ergaenzt Kostenfelder und Budget-Objekte.

Alert-Schwellwerte

Setzen Sie Alert-Schwellen je Dimension:

Alert-Dimension	Alert-Schwelle	Alert-Kanal	Ausgeloeste Aktion
Globaler Budgetverbrauch	70%, 90%, 100%	Slack/E-Mail	70% Hinweis, 90% Degradation, 100% Break
Verbrauch eines Nutzers/Tenants	Mehr als 3x Durchschnitt	Slack/E-Mail	Auf ungewoehnliche Aufrufe pruefen
Fehlerrate eines Modells	> 5%	Dashboard-Alert	Modell-Routing oder Service-Status pruefen
Retry-Anzahl eines Tools	> Schwellwert	Dashboard-Alert	Tool-Stabilitaet pruefen
Cache-Hit-Rate	< Erwartungswert	Dashboard-Alert	Prompt-Struktur pruefen

Alert-Schwellen gehoeren in die Kostenlogik, damit Alerts und Circuit Breaker automatisch ausloesen.

Degradationsstrategie

Nach einem Alert kann die Degradation so aussehen:

Degradationspfad	Degradation	Geeigneter Fall	Kostenwirkung
Modelldegradation	Grosses Modell -> kleines Modell	Ein Modell hat hohe Fehlerrate	Weniger Kosten, moeglicher Qualitaetsverlust
Pfaddegradation	Realtime API -> Batch API -> Flex Processing	Globales Budget wird zu schnell verbraucht	Mehr Latenz, weniger Kosten
Feature-Degradation	Nicht-kritische Tool-Aufrufe deaktivieren	Ein Tool hat zu viele Retries	Reduziert Tool-Call-Overhead
Nutzerdegradation	Rate Limit, Queue, Hinweis “spaeter erneut versuchen”	Ein Nutzer verbraucht ungewoehnlich viel	Verhindert, dass ein Nutzer das Budget verbrennt

Degradation gehoert in die Budgetlogik. Bei einem Alert sollte das System automatisch degradieren, nicht erst nach manueller Reaktion.

Naechste Schritte

Agent-Kostenkontrolle steht nicht allein. Sie braucht Monitoring, Tool Calling und Kontext-Engineering:

• Veroeffentlicht: Agent Monitoring and Recovery: Logfelder, Alerts und Fehlerwiederherstellung. Dieser Artikel ergaenzt Kostenfelder und Budget-Objekte.
• Veroeffentlicht: LangGraph Agent Architecture: Checkpoints, thread state und Recovery fuer Langlaeufer.
• Veroeffentlicht: Tool Calling: Grundlagen von Tool Calling. Dieser Artikel ergaenzt per-tool budgets, timeouts und Retry-Limits.
• Gleiche Serie: Kontext-Engineering: stabile Prefixe, Cache-Hits und welche Kontexte in den stabilen prefix gehoeren.
• Gleiche Serie: Human-in-the-Loop: Freigabewartezeit, Ablehnung, Timeout-Zweige und wie Freigaben Kosten und Retries veraendern.

Beginnen Sie mit der Session-Schutzlinie: Setzen Sie ein per-session cost limit und beenden Sie eine Session automatisch, wenn sie das Budget ueberschreitet. Das ist der schnellste Schutz dagegen, dass ein entgleister Task das Tagesbudget verbrennt. Danach erweitern Sie das Design auf Budget-Ebenen, Modell-Routing, Tool-Call-Budgets, Prompt Caching, Retry-Circuit-Breaker und Kostenlogs.