Die agentische Token-Explosion: Kostenattribution & Budgets für Claude Code in CI/CD

Wenn Agenten von interaktiven Sitzungen zu CI/CD-Pipelines wechseln, entfällt der menschliche Pacing-Mechanismus und ReAct-Schleifen erweitern den Kontext quadratisch. Die Rechnung des Anbieters sagt Ihnen, wie viel Sie ausgegeben haben. Sie kann Ihnen nicht sagen, warum – oder wo Sie kürzen können, ohne die Geschwindigkeit zu beeinträchtigen.

Warum CI/CD die Wirtschaftlichkeit verändert

Interaktive KI-Sitzungen verfügen über einen integrierten Taktgeber: den Menschen vor der Tastatur. Der Mensch liest die Ausgabe des Agenten, entscheidet, was als Nächstes zu tun ist, und verbraucht etwa einen Prompt alle paar Minuten. Dieses Tempo ist eine sanfte Ratenbegrenzung, selbst wenn keine Richtlinie sie erzwingt.

CI/CD-Pipelines haben das nicht. Ein für die automatisierte PR-Überprüfung konfigurierter Agent kann durch normalen Commit-Verkehr hunderte Male pro Stunde ausgelöst werden, und es gibt nichts in seiner Umgebung, das ihn verlangsamt. Die Rechnung ist schlimmer, als die Auslösefrequenz vermuten lässt, da die Kosten pro Aufruf selbst steigen – agentische Frameworks wie ReAct das Ergebnis jeder Aktion vor dem nächsten Denkschritt wieder an das Kontextfenster anhängen. Der Token-Verbrauch pro Agentenlauf wächst annähernd O(n²) in der Anzahl der Schritte.

.

‍

Der blinde Fleck bei der Anbieterabrechnung

Die Dashboards von Anthropic und OpenAI zeigen Ihnen genau, wie viele Tokens Ihre Organisation letzten Dienstag verbraucht hat. Sie werden Ihnen nicht sagen, warum. Der Anbieter hat keinen Anwendungskontext – er kann eine kritische Produktionsdatenpipeline nicht von einem Endlos-Schleifen-Nebenprojekt eines Junior-Ingenieurs unterscheiden. Beide werden gleich abgerechnet.

Ohne granulare Zuordnung greift die Finanzabteilung auf das einzige verfügbare Mittel zurück: pauschale Verbote. Die KI-Nutzung wird bis zur Überprüfung pausiert. Legitime Workloads werden zusammen mit den Ausreißern gedrosselt. Technische Führungskräfte lernen, den monatlichen Finanzabschluss zu fürchten. Das grundlegende Problem ist, dass die Zuordnung beim Ingest erfolgen muss, nicht bei der Abrechnung – bis die Rechnung eintrifft, sind die benötigten Labels verschwunden.

Die Rechnung des Anbieters beantwortet die Frage „wie viel“. Das Gateway-zugeordnete Ledger beantwortet die Frage „welches Repo, welche Pipeline, welcher Agentenschritt und was zu beheben ist“. Dieser Unterschied verwandelt eine Finanzkrise in ein Engineering-Ticket.

Metadaten-Tagging auf Gateway-Ebene

Die Grundlage der Kostenzuordnung ist das obligatorische Tagging am Gateway. Jede Anfrage aus einer CI/CD-Pipeline injiziert über den X-TFY-METADATA-Header ein kleines JSON-Objekt, das das Team, das Repository, die Pipeline, den Agentenschritt und die verantwortliche Kostenstelle identifiziert. Die Struktur ist einfach, bewusst gewählt und in jedem Team gleich:

HTTP  ·  erforderlicher Header bei jeder CI-Anfrage

X-TFY-METADATA: {
  "team":         "payments-platform",
  "repo":         "transaction-service",
  "pipeline":     "pr-security-audit",
  "agent_step":   "step-2-policy-check",
  "cost_center":  "eng-backend",
  "environment":  "production"
}

Tags sind obligatorisch, nicht nur eine Empfehlung. Nicht getaggte Anfragen werden am Gateway abgelehnt, nicht stillschweigend durchgelassen. Dies ist die Richtlinie, die 100 % Observability erzeugt – es gibt keinen „unbekannten“ Bucket im Dashboard, da es keinen Pfad gibt, der einen solchen erzeugt. Die Kosten der Durchsetzung sind eine Cedar/OPA-Regel. Die Kosten der Nichtdurchsetzung sind eine vierteljährliche Eskalation der Finanzabteilung.

‍

‍

Mit den Tags in der Hand zählt das Gateway Eingabe-, Ausgabe- und zwischengespeicherte Tokens für jeden Aufruf, bewertet das Ergebnis anhand der aktuellen Anbieterpreise und schreibt einen vollständig zugeordneten Journaleintrag. Kostenansichten sind standardmäßig nach Benutzer, Modell und Team aufgeteilt, mit einer Option zum Herunterladen von Rohdaten, die den Export mit benutzerdefinierten Gruppierungsfeldern ermöglicht (Benutzername, Modellname, Teams oder beliebiger Metadaten-Schlüssel, den Sie getaggt haben). Jeder Dollar hat einen Namen.

Projektbezogene Budgets mit Schutzschaltern

Sichtbarkeit ohne Durchsetzung ist ein Dashboard, das niemand nutzt. TrueFoundry weist jedem Kostenpunkt, den die Tagging-Funktion erzeugt, hierarchische, mathematisch durchgesetzte Budgets zu. Budgets sind eine geordnete Liste von Regeln, die jeweils nach Themen, Modellen oder Metadaten-Schlüsseln gegliedert sind. Zwei Semantiken unterscheiden Budgetregeln von Ratenbegrenzungsregeln, und es lohnt sich, sie genau zu verstehen:

• Die Budgetverfolgung erfolgt für jede passende Regel. Wenn eine Anfrage drei Regeln entspricht, werden die Kosten allen dreien belastet. Geschichtete Budgets – ein Team-Budget von 500 $ zusätzlich zu einem 50 $-Budget pro Repository und einem 10 $-Budget pro Entwickler – bleiben alle gleichzeitig synchron.
• Erlaubnis-/Blockierungsentscheidungen stammen nur von der ersten passenden Regel. Regeln werden von oben nach unten ausgewertet, und die erste, deren Bedingungen übereinstimmen, entscheidet, ob die Anfrage zugelassen oder abgelehnt wird. Platzieren Sie hochpriorisierte Überschreibungen oben, Standardwerte unten.

Budgetwarnungen werden bei vier konfigurierbaren Schwellenwerten ausgelöst – 75 %, 90 %, 95 % und 100 % der Obergrenze – mit Benachrichtigungskanälen für E-Mail, Slack-Webhook und Slack-Bot. Die Überprüfung erfolgt alle 20 Minuten anhand des neuesten zugeordneten Ledgers:

Tabelle 1 – Budgets-Schwellenwerte. Jeder Schwellenwert wird einmal pro Budgetperiode (Tag / Woche / Monat) ausgelöst und am Beginn der nächsten Periode zurückgesetzt. Warnungen werden alle 20 Minuten überprüft.

Das 100%-Verhalten ist Teil des Designs, nicht nachträglich hinzugefügt. Das Gateway gibt einen strukturierten Fehler zurück, der das ausgeschöpfte Budget benennt und den Bediener auf das Dashboard verweist:

JSON  ·  429-Antwort bei harter Obergrenze

{
  "error":      "Budget Exceeded",
  "rule_id":    "transaction-service-daily",
  "detail":     "Repository \"transaction-service\" has exhausted its
                 daily $50 AI budget at 14:32 UTC.",
  "mitigation": "Review pipeline logs for infinite loops or request a
                 quota increase via the platform team.",
  "dashboard":  "https://gateway.example.com/budgets/transaction-service"
}

Eine Pipeline, die ihr Budget erreicht, sollte wissen, was als Nächstes zu tun ist, ohne dass der Entwickler das Plattformteam um Kontext bitten muss. CI-Runner interpretieren 429 als ein standardmäßiges Backoff-Signal; der Build schlägt sauber mit einer umsetzbaren Meldung fehl, anstatt auf verwirrende Weise abzustürzen.

Es gibt noch ein weiteres Verhalten, das wissenswert ist: den Audit-Modus. Das Setzen von block_on_budget_exceed: false für eine beliebige Regel hält die Verfolgung und Alarmierung aktiv, lässt aber Anfragen durch. Dies ist die richtige Standardeinstellung während des ersten Monats der Einführung. Beobachten Sie, wie die Warnungen bei simulierten Obergrenzen ausgelöst werden; passen Sie die Obergrenzen an; erst dann schalten Sie die Durchsetzung ein. Das Überspringen des Audit-Modus führt dazu, dass Sie mit einem wütenden Team aufwachen, dessen Pipelines alle um 03:00 Uhr fehlgeschlagen sind.

YAML  ·  Konfiguration geschichteter Budgets

name: cicd-budget
type: gateway-budget-config
rules:
  - id: "ml-team-override"
    when: { subjects: ["team:ml-engineering"] }
    limit_to: 200
    unit: cost_per_day
    budget_applies_per: ["user"]
  - id: "default-user-daily"
    when: {}
    limit_to: 10
    unit: cost_per_day
    budget_applies_per: ["user"]
  - id: "per-repo-daily"
    when: {}
    limit_to: 50
    unit: cost_per_day
    budget_applies_per: ["metadata.repo"]
    alerts:
      thresholds: [75, 90, 100]
      notification_target:
        - type: slack-webhook
          notification_channel: "ai-budget-alerts"

Aufbau eines Dashboards zur Kostenattribution

Gekennzeichnete Daten, die in die Metrikebene des Gateways fließen, ermöglichen es dem Plattformteam, Dashboards zu erstellen, die Eigentumsfragen beantworten, anstatt mehr aggregiertes Rauschen zu erzeugen. Anstatt auf einen Anstieg zu starren und zu fragen „Wer hat das getan?“, sagt Ihnen das Dashboard bereits, dass um 02:00 UTC das Frontend-Team einen neuen Agenten im React-Monorepo bereitgestellt hat, der eine fehlende Abhängigkeit halluzinierte und in eine 400-Schritte-Auflösungsschleife geriet.

Diese Art von operativem Kontext verwandelt Kosten von einem Finanzproblem in ein Engineering-Problem. Sobald Sie sehen, dass das Umschalten des anfänglichen Code-Zusammenfassungsschritts von Sonnet auf Haiku die Kosten dieses Schritts um 80 % senkt, ohne die Qualität der PR-Überprüfung zu beeinträchtigen, nehmen Sie die Änderung vor. Sie streiten nicht über Budgetobergrenzen in einem Lenkungsausschuss. Die TrueFoundry-Kostenverfolgungsansichten werden standardmäßig für Benutzer-, Modell- und Team-Perspektiven geliefert, und der Rohdatenexport ermöglicht es Ihnen, nach jedem Metadaten-Schlüssel zu filtern – so ist eine Ansicht pro Repository, pro Pipeline oder pro Agenten-Schritt ein Ein-Klick-Download, kein Data-Engineering-Projekt.

‍

‍

Monatliche Ausgaben prognostizieren, bevor die Rechnung kommt

Aggregierte Tagging-Daten machen auch die Prognose handhabbar. Agentenbasierte Workloads sind sprunghaft – periodische, ressourcenintensive CI-Jobs dominieren die Rechnung – weshalb einfache gleitende Durchschnitte die Ausgaben systematisch unterschätzen. Der Durchschnitt der letzten 7 Tage ist die falsche Prognose für einen Workload, dessen 95. Perzentil das Vierfache seines Mittelwerts beträgt.

Das richtige Modell ist eine P95-Rollierende Prognose, die pro Repository und pro Team durchgeführt wird. P95 erfasst das Spitzenrisiko, das ein Durchschnitt glättet, und prognostiziert die Ausgaben zum Monatsende mit ausreichend Vorlaufzeit, um Budgets anzupassen, Quoten zu erhöhen oder eine fehlerhafte Pipeline zu stoppen, bevor die Finanzabteilung die Überraschung bemerkt. „Überraschung“ ist das Schlüsselwort: Dies ist eine Prognose, die genau das vermeiden soll. In der Praxis hat eine 7-Tage-P95-Prognose die tatsächlichen Ausgaben zum Monatsende bei den von uns gemessenen Workloads innerhalb von 8–12 % erfasst – ausreichend genau, um darauf zu reagieren, und weitaus besser als die Alternative des gleitenden Durchschnitts.

Ein reales Beispiel: 8.400 $ → unter 800 $

Ein Unternehmen mit 50 Ingenieuren entwickelte einen dreistufigen Claude Code-Review-Agenten, der bei jeder Pull-Anfrage ausgeführt wurde: (1) die Änderungen zusammenfassen, (2) die Änderungen anhand von Sicherheitsrichtlinien über einen MCP-Dokumentationsserver überprüfen, (3) Codeänderungen vorschlagen. Sinnvolle Architektur, nützlicher Workflow, keine offensichtlichen Warnsignale.

Bei etwa 15 PRs pro Ingenieur pro Woche, unter Berücksichtigung von Wiederholungsversuchen und der Kosten für das Kontextfenster beim Einfügen ganzer Dateien in Prompts, verbrauchte der Agent durchschnittlich etwa 400.000 Input-Tokens pro PR. Rechnung für die CI/CD-Automatisierung im ersten Monat: 8.400 $.

Tabelle 2 – Schritt-für-Schritt-Anleitung zur Fehlerbehebung bei der Kostenattribution. Fünf Gateway-Klicks, eine Konfigurationsänderung. Ohne Attribution wäre die Reaktion ein pauschales Verbot von Sonnet für CI-Workflows gewesen. Mit Attribution war die Reaktion eine einzeilige Konfigurationsänderung.

Diese Lücke – zwischen „Modell verbieten“ und „einen Prompt cachen“ – ist der gesamte Nutzen einer korrekten Attribution. Die Kostendaten existieren so oder so; die Frage ist, ob Sie die Labels haben, um sie zu lesen.

FAQ

Sollten Budgets in Dollar oder Tokens angegeben werden?

Beides, gleichzeitig. Dollar stimmen mit der Finanz- und Betriebsplanung überein. Tokens sind die technische Metrik, mit der Sie die Prompt-Effizienz debuggen können. TrueFoundry verfolgt beides – die Finanzabteilung besitzt die Dollar-Dashboards, die Technikabteilung die Token-Dashboards, und das Gateway ist die Quelle der Wahrheit für beides. Anbieter-Preisänderungen werden auf der Dollar-Ebene absorbiert, ohne dass die Technikabteilung etwas umstrukturieren muss; neue Feinabstimmungen werden auf der Token-Ebene absorbiert, ohne dass die Finanzabteilung den Modellnamen kennen muss.

Was passiert, wenn ein hartes Limit mitten in der Pipeline erreicht wird?

Die Pipeline erhält einen 429-Fehler mit der zuvor gezeigten beschreibenden Fehlermeldung und einem Link zum Budget-Dashboard. CI-Runner interpretieren 429 als ein Standard-Backoff-Signal; der Build schlägt sauber mit einer umsetzbaren Meldung fehl, anstatt auf verwirrende Weise abzustürzen. Quota-Erhöhungen werden als Standard-Tickets an das Plattformteam gemeldet – die Dashboard-URL im Fehlertext verkürzt die übliche Runde von „Ich verstehe nicht, warum das fehlschlägt.“

Verlangsamt die obligatorische Kennzeichnung die Einführung?

In der Praxis nein – die SDK-Wrapper übernehmen die Injektion automatisch innerhalb von CI-Templates, sodass einzelne Entwickler niemals Header bearbeiten müssen. Die einmaligen Kosten bestehen in der Aktualisierung der Pipeline-Templates des Teams; die wiederkehrenden Kosten sind null. Der wiederkehrende Nutzen ist jedes Dashboard, jede Warnung und jede nachfolgende Postmortem-Analyse.

Was ist der Unterschied zwischen Ratenbegrenzungen und Budgetbegrenzungen – wann verwende ich welche?

Ratenbegrenzungen stoppen Spitzenlasten; Budgetbegrenzungen stoppen Ausgaben. Ratenbegrenzungen werden in Anfragen/Minute oder Tokens/Minute angegeben – sie schützen nachgelagerte Dienste vor Überlastung und werden pro Anfrage bewertet. Budgets werden in Dollar pro Tag/Woche/Monat angegeben – sie schützen das Budget des Unternehmens und werden anhand des kumulativen Hauptbuchs bewertet. Die meisten Produktions-Stacks verwenden beides, auf verschiedene Entitäten zugeschnitten. Die Muster ergänzen sich, sind nicht redundant.

‍

‍