Cost Monitoring fuer Agenten

Idee in 30 Sekunden

Cost Monitoring fuer KI-Agenten zeigt nicht nur die Gesamtkosten, sondern auch, wo sie steigen: bei LLM-Tokens, externen APIs und wiederholten Agent-Schritten.

Ohne das verpasst man leicht den Moment, in dem das System noch "funktioniert", aber fuer Production bereits zu teuer ist.

Hauptproblem

Ein Run kann erfolgreich enden, aber 2-3x teurer sein als gewohnt.

Zwei Anfragen mit derselben finalen Antwort koennen unterschiedliche Stueckkosten haben: durch zusaetzliche reasoning-Schritte, retries oder unnoetige Tool-Aufrufe. Ohne cost monitoring sieht man das meist erst nach Budget-Ueberschreitung.

Als Naechstes schauen wir, wie man diese Signale liest und erkennt, was einen Run teuer macht.

In Production sieht das oft so aus:

• Tokens steigen nach einem Release in Wellen;
• ein Tool beginnt unbemerkt, den groessten Teil des Budgets zu verbrauchen;
• retries erhoehen Kosten auch ohne Traffic-Wachstum;
• das Team sieht das Problem erst nach Budget-Explosion.

Darum sollte der Cost-Layer separat ueberwacht werden und nicht nur ueber allgemeine Run-Metriken.

Wie es funktioniert

Cost Monitoring basiert auf zwei Signalarten:

• usage signals (prompt_tokens, completion_tokens, tool_calls, retries);
• cost signals (llm_cost_usd, tool_cost_usd, total_cost_per_run).

Diese Metriken beantworten, "wo und warum das System ueber Zeit teurer wird". Logs und Tracing sind noetig, um einen konkreten teuren Run zu erklaeren.

Kosten steigen nicht nur durch Traffic-Volumen, sondern auch durch Agent-Verhalten. Usage != cost. Ein Agent kann dieselbe Aufgabe mit demselben Ergebnis loesen, aber deutlich mehr kosten: wegen retries, laengerer reasoning-Ketten oder teurer Tools.

Typische Production-Cost-Metriken

budget_burn_rate wird meist auf Dashboard-Ebene berechnet (Kosten pro Zeiteinheit), nicht als eigener Runtime-Counter.

Damit Metriken praktisch bleiben, werden sie meist nach release, model, tool und Request-Typ segmentiert.

Wichtig: keine hoch-kardinalen Felder (run_id, request_id, user_id) in Labels aufnehmen, sonst wird das Metrik-Storage schnell ueberlastet.

Wie man den Cost-Layer liest

Was verbraucht wird -> wie sich der Agent verhaelt -> was es real kostet. Diese drei Ebenen sollte man immer zusammen betrachten.

Wichtig sind Zeittrends und Unterschiede zwischen Releases, nicht Einzelwerte.

Jetzt zu Signal-Kombinationen:

• token_usage_per_run ↑ + llm_cost_per_run ↑ -> Agent verbraucht mehr Tokens pro Run;
• tool_cost_per_run ↑ + total_cost_per_run ↑ -> over-tooling oder teurer Tool-Pfad;
• llm_cost_per_run ↑ + tool_cost_per_run ~= stabil -> Problem liegt in Prompt oder reasoning, nicht in Tools;
• budget_burn_rate ↑ + run_count ~= stabil -> Regression der Stueckkosten;
• cost_p95 ↑ + budget_burn_rate ↑ -> teure anomale Runs beschleunigen den Budgetverbrauch.

Wann einsetzen

Vollstaendiges cost monitoring ist nicht immer noetig.

Fuer einfache Prototypen reichen manchmal token_usage und ein taegliches Ausgabenlimit.

Detailliertes Cost Monitoring wird kritisch, wenn:

• das System bereits in Production mit Budgetgrenzen laeuft;
• der Agent mehrere Tools mit kostenpflichtigen APIs nutzt;
• Releases haeufig sind und Kosten-Regressionen sichtbar sein muessen;
• Traffic skaliert werden muss, ohne Budgetkontrolle zu verlieren.

Implementierungsbeispiel

Unten ist ein vereinfachtes Prometheus-Beispiel fuer Cost-Metrik-Instrumentierung. Es zeigt Basis-Kontrolle fuer LLM-Kosten, Tool-Kosten und Gesamtpreis pro Run.

import time
from prometheus_client import Counter, Histogram

RUN_TOTAL = Counter(
    "agent_run_total",
    "Total number of agent runs",
    ["status", "stop_reason", "release"],
)

LLM_COST_USD_TOTAL = Counter(
    "agent_llm_cost_usd_total",
    "Total LLM cost in USD",
    ["model", "release"],
)

TOOL_COST_USD_TOTAL = Counter(
    "agent_tool_cost_usd_total",
    "Total tool/API cost in USD",
    ["tool", "release"],
)

TOKEN_USAGE_TOTAL = Counter(
    "agent_token_usage_total",
    "Total LLM tokens",
    ["model", "token_type", "release"],
)

RUN_COST_USD = Histogram(
    "agent_run_cost_usd",
    "Cost per run in USD",
    ["release"],
    buckets=(0.001, 0.003, 0.01, 0.03, 0.1, 0.3, 1, 3),
)

BUDGET_BREACH_TOTAL = Counter(
    "agent_budget_breach_total",
    "Total runs that crossed cost budget",
    ["release"],
)

LLM_PRICING = {
    # WARNING: Beispielpreise (koennen veraltet sein).
    # In Production sollten diese Werte aus Konfiguration oder Provider-API kommen.
    "gpt-4.1": {
        "prompt": 0.0000015,
        "completion": 0.0000020,
    }
}


def estimate_llm_cost_usd(model, prompt_tokens, completion_tokens):
    # WARNING: replace with actual provider pricing
    pricing = LLM_PRICING.get(model)
    if not pricing:
        # WARNING: unknown model — cost will be reported as 0 (underestimated)
        return 0.0
    prompt_cost = prompt_tokens * pricing.get("prompt", 0)
    completion_cost = completion_tokens * pricing.get("completion", 0)
    return prompt_cost + completion_cost


def run_agent(agent, task, budget_limit_usd=0.25, release="2026-03-21"):
    run_status = "ok"
    stop_reason = "max_steps"
    run_cost_usd = 0.0

    try:
        for step in agent.iter(task):
            step_type = step.type
            try:
                result = step.execute()
            except Exception as error:
                run_status = "error"

                if step_type == "tool_call":
                    stop_reason = "tool_error"
                elif step_type == "llm_generate":
                    stop_reason = "llm_error"
                else:
                    stop_reason = "step_error"

                raise

            if step_type == "llm_generate":
                model = getattr(step, "model", "unknown")
                usage = getattr(result, "token_usage", {}) or {}
                prompt_tokens = usage.get("prompt_tokens", 0)
                completion_tokens = usage.get("completion_tokens", 0)

                TOKEN_USAGE_TOTAL.labels(model=model, token_type="prompt", release=release).inc(
                    prompt_tokens
                )
                TOKEN_USAGE_TOTAL.labels(
                    model=model, token_type="completion", release=release
                ).inc(completion_tokens)

                llm_cost = estimate_llm_cost_usd(model, prompt_tokens, completion_tokens)
                run_cost_usd += llm_cost
                LLM_COST_USD_TOTAL.labels(model=model, release=release).inc(llm_cost)

            if step_type == "tool_call":
                tool_name = getattr(step, "tool_name", "unknown")
                tool_cost = float(getattr(result, "cost_usd", 0.0) or 0.0)
                run_cost_usd += tool_cost
                TOOL_COST_USD_TOTAL.labels(tool=tool_name, release=release).inc(tool_cost)

            if result and result.is_final:
                stop_reason = "completed"
                break
    finally:
        RUN_COST_USD.labels(release=release).observe(run_cost_usd)
        if run_cost_usd > budget_limit_usd:
            BUDGET_BREACH_TOTAL.labels(release=release).inc()
        RUN_TOTAL.labels(status=run_status, stop_reason=stop_reason, release=release).inc()

# cost_per_1k_runs wird meist auf Dashboard-Ebene berechnet:
# (sum(agent_run_cost_usd) / run_count) * 1000
# budget_burn_rate wird meist auf Dashboard-Ebene berechnet:
# Kosten pro Zeiteinheit (z. B. USD/hour), nicht als separater Counter im Code.

So koennen diese Metriken zusammen in einem realen Dashboard aussehen:

Investigation

Wenn ein Kosten-Alert ausloest:

1. Segment mit Anomalie finden (model, tool, release);
2. teure Runs im Tracing ansehen;
3. retries, stop_reason und Tool-Pfad in Logs pruefen;
4. root cause finden (Prompt, Agent-Logik, teures API, falsches Routing).

Typische Fehler

Auch wenn Cost-Metriken da sind, bringen sie oft wenig wegen typischer Fehler unten.

Es gibt nur eine taegliche Gesamtkostenzahl

Die Tages-Summe zeigt nicht, welcher Run oder welches Segment teurer wurde. Ohne cost_per_run und cost_p95 sieht man Probleme meist zu spaet.

Es werden nur Tokens gezaehlt, Tool-Kosten ignoriert

In vielen Agentensystemen sind externe API-Calls der teure Teil. Ohne tool_cost_per_run verpasst man leicht fruehe Budget-Explosion.

Keine Aufteilung nach release und model

Ohne Segmentierung ist schwer nachzuweisen, dass ein neues Release oder neues Modell die Stueckkosten erhoeht hat.

Hoch-kardinale Labels

run_id, request_id oder session_id in Labels ueberlasten Metrik-Backends schnell. Diese Daten besser in Logs und Tracing halten.

Keine Alerts auf burn rate und cost_p95

Ohne Alerts sammeln sich Probleme unbemerkt, bis sie das Budget treffen. Das tritt oft zusammen mit Token-Ueberverbrauch auf.

Selbstcheck

Unten ist eine kurze Checkliste fuer Basis-Cost-Monitoring vor Release.

FAQ

Q: Worin unterscheidet sich Cost Monitoring von Token-Monitoring?
A: Tokens sind nur ein Teil der Kosten. Cost Monitoring umfasst LLM-Tokens, bezahlte Tool/API-Calls und die gesamte Run-Stueckkosten.

Q: Welches Minimum an Kosten-Metriken braucht man zum Start?
A: Starte mit token_usage_per_run, total_cost_per_run, cost_p95 und budget_burn_rate.

Q: Wie berechnet man cost_per_run bei mehreren Providern?
A: Alle Schrittkosten auf eine einheitliche Waehrung (meist USD) normalisieren und LLM + Tool-Kosten innerhalb eines Runs aufsummieren.

Q: Wie trennt man Traffic-Wachstum von Stueckkosten-Regression?
A: run_count und cost_per_run gemeinsam betrachten. Wenn Traffic stabil ist, aber cost_per_run steigt, ist das eine Stueckkosten-Regression.

Verwandte Seiten

Weiter zum Thema:

• Agent-Metriken — Gesamtmodell fuer Metriken in Agentensystemen.
• Tool-Usage-Metriken — Kosten- und Zuverlaessigkeitskontrolle auf Tool-Ebene.
• Agent Tracing — wie man teure Schritte in einem Run findet.
• Agent-Logging — Events fuer die Analyse von Kosten-Incidents.
• Latenz-Monitoring fuer Agenten — Zusammenhang zwischen latency und cost.