Anthropic hat am 27. Oktober einen langen Leitfaden veröffentlicht, 17 Minuten Lesezeit, entstanden nach einem Webinar mit Google Cloud. Es beantwortet die Frage, die Plattformteams bekommen, sobald Claude Code in der Breite läuft: Was kostet das, und was kommt dafür heraus. Anthropic ordnet die Antwort in drei Hebel, control, track und prove.
Control: Leitplanken statt Deckel
Die Steuerung sitzt im Claude apps gateway, einem selbst betriebenen Dienst, der im eigenen Google-Cloud-Projekt zwischen Claude Code und Claude on Google Cloud läuft. Er steckt in derselben claude-Binärdatei, die die Entwickler schon haben. Angemeldet wird über den eigenen Identitätsanbieter, etwa Google Workspace, sodass jede Anfrage eine geprüfte Identität trägt.
Darauf bauen vier Mittel auf: Ausgabengrenzen pro Person, pro IdP-Gruppe oder für die ganze Organisation, nach Tag, Woche oder Monat; Warnungen in der CLI ab 75 und ab 95 Prozent, während die Budgetalarme von Google Cloud den Administratoren gelten; Modellvorgaben und Allowlists, die das Gateway serverseitig bei jeder Anfrage durchsetzt; und eine Admin-API, über die ein Ticketsystem Grenzen anheben kann. Am Limit antwortet das Gateway mit 429, bis die Periode endet oder jemand das Limit hebt.
Bemerkenswert ist, wo Anthropic die Verschwendung vermutet. Teure Sitzungen seien nicht per se schlecht, sondern oft die wertvollsten. Das Geld verbrenne das breite Mittelfeld: Fable für eine tägliche Routine, die Sonnet auch könnte, oder eine geplante Aufgabe, die längst niemand mehr braucht und trotzdem weiterläuft. Wichtig sei nicht der Tokenpreis, sondern die Kosten pro Aufgabe.
Track: wo das Geld hingeht
Die OpenTelemetry-Metriken von Claude Code melden Nutzung und geschätzte Kosten, aufgeschlüsselt nach Skill, Plugin, Agent und MCP-Server. So wird sichtbar, welche internen Skills und Plugins im Haus überhaupt ankommen. Der Weg führt über OTLP in Werkzeuge, die man schon betreibt, etwa Google Cloud Monitoring.
Einrichten muss man das nicht je Rechner: Wer am Gateway ein Telemetrieziel setzt, schaltet es für alle angemeldeten Entwickler ein, und jeder Export trägt deren geprüfte E-Mail-Adresse und IdP-Gruppen statt irgendwelcher clientseitig gesetzten Werte. Für die eigene Kostenstellenlogik gibt es OTEL_RESOURCE_ATTRIBUTES. Daneben stehen die Google-Cloud-Mittel: eigenes Projekt für Claude Code, Budgetalarme, Spend Caps als Preview, Quotas, Provisioned Throughput und ein BigQuery-Export, der nach Claude-SKUs und Tokenart filtert.
Prove: drei Dimensionen, und eine harte Frage
Den Nachweis teilt Anthropic in Nutzung, Zufriedenheit und Wirkung. Zufriedenheit kommt aus einer kurzen Befragung vor und nach dem Rollout. Die Wirkung misst sich an drei Gruppen: Zeit, also PR-Durchlaufzeit von offen bis gemerged und Reaktionszeit im Review; Aufwand, also Review-Runden, Kommentare und Nacharbeit je PR; und Menge, also PRs je Entwickler, Deployment-Häufigkeit und benannte Arbeitspakete, die mit der freien Kapazität fertig wurden.
Die harte Frage steckt in der Zähl-Einheit. Ein Tippfehler und ein Feature-Release sind beide ein PR. Anthropics Vorschlag: nur gemergte PRs einer definierten Klasse zählen, die also, bei denen Claude den PR eröffnet und ein Mensch über das Ausliefern entscheidet. Eine Service-Umstellung oder ein an der Wurzel geschlossener Incident sind kein PR und zählen nach derselben Regel dort, wo sie landen.
Der Leitfaden kommt am passenden Tag
Am selben Tag hat Amazon ein Memo veröffentlicht, das Token-Nutzung als Kennzahl tief fehlerhaft nennt. Anthropics Papier sagt dasselbe von der Anbieterseite aus. Brauchbar macht den Leitfaden ist nicht die Werkzeugliste, sondern der Abschnitt über die Zähl-Einheit. Wer die nicht definiert, baut Dashboards, die hübsch aussehen und nichts beweisen.