LLM-Kosten senken: FinOps für Claude im Betrieb

TL;DR

LLM-Kosten bei Claude bewegen vier Hebel und ein Buchhaltungsproblem. Die Hebel heissen Caching, Batch, Modellwahl und Kontextgrösse, und sie verändern eine Token-Rechnung um einen Faktor, nicht um Prozente. Das Buchhaltungsproblem: Ausgabelimits gelten pro Mitglied, ein Gruppenlimit von 200 USD erlaubt 50 Personen also 10.000 USD.

Was FinOps bei LLM beantworten muss und in der Cloud nicht musste

Cloud-FinOps verteilt eine Rechnung auf Teams. FinOps bei Sprachmodellen muss das auch und zusätzlich eine Frage beantworten, die es in der Cloud nie gab: Was hat eine einzelne Aufgabe gekostet, und hätte ein günstigeres Modell dieselbe Antwort geliefert? Instanzgrössen haben eine richtige Antwort, die man aus einem Diagramm abliest. Modellwahl hat keine, weil der Qualitätsunterschied erst im Ergebnis sichtbar wird.

Drei strukturelle Unterschiede verändern die Methode.

Dimension	Cloud-FinOps	Claude-FinOps
Einheit der Verschwendung	Bereitgestellte Kapazität, die ungenutzt lief	Kontext, den Sie gesendet haben und den die Antwort nicht brauchte
Hebel mit der grössten Wirkung	Commitments und Rightsizing	Caching und Batch, also Entscheidungen auf Anfrage-Ebene
Zuordnung	Tags auf Ressourcen	Token-Metriken pro Person, die es nur auf manchen Routen gibt
Wer Kosten erzeugen kann	Platform-Engineering	Jede Person mit einem Platz

Die letzte Zeile ist die unangenehme. Auf einer Cloud-Rechnung erzeugen wenige Personen den Grossteil der Kosten. Auf einer Claude-Rechnung kann das jede Person mit einem Platz, und die Kontrollen dagegen heissen Standardwerte und Limits, nicht Code-Review. Der 90-Tage-Plan zur KI-Einführung sagt, wann sie gesetzt werden.

Wo Sie in welchem Setup messen und begrenzen können

Bevor Sie optimieren, klären Sie, ob Sie überhaupt Zahlen pro Person sehen. Das hängt vollständig davon ab, wie Ihre Organisation Claude erreicht.

Ihr Setup	Verbrauch sehen	Verbrauch begrenzen	Reporting pro Person
Claude für Teams oder Enterprise	Spend-Report in der Organisations-Analytics, eine Zeile pro Person und Modell, täglich aktualisiert	Ausgabelimits in den Admin-Einstellungen, auf Organisations-, Gruppen- oder Mitgliedsebene	Spend-Report-CSV, auf Enterprise zusätzlich die Enterprise-Analytics-API
Claude Console (API)	Usage-Seite der Console	Workspace-Ausgabelimits, auch für den automatisch erzeugten Claude-Code-Workspace	Console-Dashboard, Claude-Code-Analytics-API
Bedrock, Google Cloud, Microsoft Foundry	Die Billing-Konsole Ihrer Cloud	Die Budget-Steuerung Ihrer Cloud	OpenTelemetry, ein Claude-Apps-Gateway oder ein LLM-Gateway

Die dritte Zeile ist die Falle. Auf den Cloud-Routen sendet Claude Code keine Metriken an Anthropic zurück, die Anthropic-Dashboards und die Claude-Code-Analytics-API deckten diese Nutzung also überhaupt nicht ab. OpenTelemetry-Export ist die einzige Option, die Token- und Kostenmetriken pro Person nahezu in Echtzeit in den eigenen Stack schreibt, und zwar in jedem Setup.

Ein Detail der Abrechnung noch. Auf Team- und Enterprise-Plänen wird Nutzung innerhalb des Platz-Kontingents gar nicht in Geld gemessen. Das Kontingent setzt sich in einem rollierenden Fünf-Stunden-Fenster und einem Wochenfenster zurück und gilt gemeinsam für Chat, Cowork und Claude Code. Beträge erscheinen erst, wenn Usage Credits aktiviert sind. Wenn Ihr Spend-Report leer aussieht, ist das meist der Grund.

Die vier Hebel, die die Token-Rechnung bewegen

Sortiert nach Wirkung, abgeleitet aus den veröffentlichten Multiplikatoren statt aus Allgemeinplätzen.

1. Prompt Caching. Cache-Writes kosten 1,25x Basis-Input für den Fünf-Minuten-Cache und 2x für den Stunden-Cache. Cache-Reads kosten 0,1x Basis-Input, auf Opus 5.5 und Sonnet 5.5 nur 0,05x und auf Fable 5.1 nur 0,025x. Absolut sind das 0,20 USD pro Million Tokens auf Opus 5.5 und 0,10 USD auf Sonnet 5.5. Die Rechnung ist einfach: Der Fünf-Minuten-Cache rechnet sich ab dem ersten Treffer, der Stunden-Cache ab dem zweiten. Unser Leitfaden zum Prompt Caching beschreibt, wohin die Breakpoints gehören.

2. Die Batch-API. 50 Prozent Rabatt auf Input und Output, und der Rabatt stapelt mit Caching. Alles, was nicht zeitkritisch ist, also Klassifikation, Anreicherung, Dokumentenextraktion und nächtliche Zusammenfassungen, gehört dorthin. Fast Mode ist mit der Batch-API nicht verfügbar, und zustandsbehaftete Managed-Agents-Sessions können sie ebenfalls nicht nutzen.

3. Modellwahl. Die Spanne ist so gross, dass sie bei hohem Volumen alles andere dominiert.

Modell	Input pro Million Tokens	Output pro Million Tokens
Claude Fable 5.1	10,00 USD	50,00 USD
Claude Opus 5.5	4,00 USD	20,00 USD
Claude Opus 4.5	5,00 USD	25,00 USD
Claude Sonnet 5.5	2,00 USD	10,00 USD
Claude Sonnet 4.6	3,00 USD	15,00 USD
Claude Haiku 5.5, Prompts bis 100.000 Tokens	0,10 USD	0,50 USD
Claude Haiku 5.5, Prompts über 100.000 Tokens	0,50 USD	2,50 USD
Claude Haiku 4.5	1,00 USD	5,00 USD

Haiku 5.5 auf kurzen Prompts ist beim Input und beim Output vierzigmal günstiger als Opus 5.5. Das ist keine Feinabstimmung, das ist eine Routing-Entscheidung, und am schnellsten verankert sie sich über die Modell-Berechtigungen statt über eine Richtlinie, die niemand liest.

4. Kontextgrösse. Claude 4.6 und neuere Modelle ausser Haiku 5.5 enthalten das volle Kontextfenster von einer Million Tokens zum Standardpreis. Eine Anfrage mit 900.000 Tokens kostet pro Token dasselbe wie eine mit 9.000. Das ist bequem und nimmt die Bremse heraus: Nichts in der Preisliste bestraft es, das ganze Repository mitzusenden. Haiku 5.5 ist die Ausnahme und wird nach Prompt-Länge bepreist, wobei ein Prompt über 100.000 Tokens den höheren Satz zahlt, auch wenn Teile davon Cache-Treffer sind.

Zwei Modifikatoren arbeiten gegen Sie. Inferenz ausschliesslich in den USA über inference_geo kostet 1,1x auf allen Kategorien einschliesslich Cache-Reads, und auf Bedrock kosten regionale und multiregionale Endpunkte 10 Prozent mehr als globale. Claude 4.7 und neuer nutzen zudem einen neuen Tokenizer, der für denselben Text rund 30 Prozent mehr Tokens erzeugt. Eine Preissenkung pro Token bedeutet also nicht automatisch eine günstigere Anfrage.

Gruppenlimits sind kein gemeinsames Budget

Dieses Detail macht die meisten Claude-Budgetmodelle ungültig, und es steht ausdrücklich in der Dokumentation zur Spend Limits API: Ein Gruppenlimit ist ein Standardwert pro Mitglied, jedes Mitglied wird gegen den eigenen Verbrauch geprüft, nicht gegen ein gemeinsames Gruppenbudget.

Die Gruppen, an denen diese Limits hängen, kommen aus Ihrem Verzeichnis, siehe unseren Leitfaden zu SCIM-Provisioning und SSO. Limits lösen sich hierarchisch auf, und das Feld source in der effektiven Zeile eines Mitglieds nennt die Ebene:

1. Ein Nutzer-Override über POST /v1/organizations/spend_limits, der das Mitglied unabhängig von jeder Vererbung festsetzt.
2. Das Gruppenlimit, ausgewiesen als rbac_group.
3. Die Platz-Stufe, ausgewiesen als seat_tier.
4. Der Organisationsstandard.

Semantik, die vor jeder Automatisierung stimmen muss. Es gibt nur monatliche Perioden, und der Verbrauch wird am Ersten jedes Kalendermonats um 00:00 UTC zurückgesetzt. Beträge sind Dezimal-Strings in der kleinsten Währungseinheit, "50000" sind also 500,00 USD. Ein null in der effektiven Zeile bedeutet unbegrenzt, "0" bedeutet, dass das Mitglied über die im Plan enthaltene Nutzung hinaus nichts verbrauchen kann. Die API gibt es nur auf Enterprise, nicht in Console-Organisationen, sie verlangt aktive Usage Credits und einen Admin-API-Key mit read:spend_limits oder write:spend_limits, den nur der Primary Owner erstellen kann. Alle acht Endpunkte teilen ein Limit von 60 Anfragen pro Minute und Organisation.

Die Alarmierung ist asymmetrisch und brauchbar: Organisationsweite Warnungen erreichen Admins bei 75 und 90 Prozent, Mitglieder sehen Hinweise bei 75 und 95 Prozent und können eine Erhöhung anfragen. Die API kann solche Anfragen nicht erzeugen, nur listen, genehmigen und ablehnen, und eine Genehmigung schreibt ein Nutzerlimit in der Höhe, die der Admin angibt, weil die Anfrage selbst keinen Wunschbetrag enthält. Nach einer Ablehnung bleibt die Anfrage-Schaltfläche für dieses Mitglied 30 Tage verborgen.

Was ein Claude-Code-Platz wirklich kostet

Entwicklerplätze dominieren eine Claude-Rechnung, und sie verhalten sich anders als Chat-Plätze, weil jeder Schritt Dateiinhalte, Werkzeugaufrufe und mehrstufiges Nachdenken mitführt.

Die veröffentlichten Werte: rund 13 USD pro Entwickler und aktivem Tag, 150 bis 250 USD pro Entwickler und Monat, und unter 30 USD pro aktivem Tag bei 90 Prozent der Nutzer. Hintergrundfunktionen kosten auch im Leerlauf unter 0,04 USD pro Session.

Drei Gewohnheiten erklären den Grossteil des Unterschieds zwischen einem 150-USD- und einem 400-USD-Entwickler:

1. Nicht zwischen unabhängigen Aufgaben aufräumen, sodass jede Nachricht eine Unterhaltung erneut liest, die seit Stunden offen ist.
2. Opus als Standardmodell für Routinearbeit stehen lassen.
3. Agent-Teams, die im Plan-Modus etwa das Siebenfache einer normalen Session verbrauchen. Sie sind standardmässig aus und brauchen eine ausdrückliche Umgebungsvariable.

Eine CLAUDE.md über 200 Zeilen ist eine kleinere, aber dauerhafte Abgabe, weil sie bei jedem Session-Start in den Kontext geladen wird, ob die Arbeit sie braucht oder nicht. Die /usage-Aufschlüsselung schlägt Änderungen für jedes Verhalten vor, das hinter 10 Prozent oder mehr der letzten Nutzung steht, und das ist ein besserer Einstieg als ein Richtliniendokument. Unser Leitfaden zu Claude-Code-Kosten hat die Details je Setup.

Warum Ihr gemeldeter Verbrauch nicht zur Rechnung passt

Claude Code berechnet jede Kostenzahl, die es Entwicklern zeigt, zu Listenpreisen. Wenn Ihre Organisation verhandelte Preise zahlt, sind die Werte in /usage, in der Statuszeile und in OpenTelemetry alle in dieselbe Richtung falsch. Die Korrektur heisst modelPricing, eine Managed-Setting mit einem Multiplikator unter 1 für Rabatt oder über 1 für Aufschlag plus Überschreibungen pro Modell. Sie verändert das Reporting, nicht die Abrechnung, und muss über Managed Settings verteilt werden, weil Claude Code den Schlüssel in Nutzer-, Projekt- und lokalen Einstellungen ignoriert.

Zwei weitere Abweichungen. Antworten, die zum Datenresidenz-Satz von 1,1x abgerechnet werden, erscheinen in der Session-Kostenzahl ebenfalls mit 1,1x. Und auf Claude Platform on AWS sowie in Microsoft Foundry wird in Claude Consumption Units zu 0,01 USD pro CCU fakturiert, wobei verhandelte Rabatte als weniger gemessene CCUs auftauchen und nicht als niedrigerer CCU-Preis. Eine CCU-Rechnung gegen ein Token-Reporting abzustimmen braucht die Umrechnungstabelle, keinen Multiplikator.

Selbst betreiben oder auslagern?

Aufgabe	Intern halten	Sinnvoll auslagerbar
Modell-Standards und Berechtigungen	Ja. Das ist eine Richtlinienentscheidung	Nein
Design und Automatisierung der Limits	Ja, nach dem Entwurf	Der erste Entwurf plus die Admin-API-Skripte
Caching- und Batch-Umbau	Ja, das ist Anwendungsarbeit	Review, wo die Breakpoints gehören
Zuordnung pro Person auf Cloud-Routen	Ja, Ihr Observability-Stack	Einmaliger Aufbau der OpenTelemetry-Pipeline
Monatlicher Kostenbericht	Ja. Er wiederkehrt	Der erste Bericht und seine Abfragen

Das Muster wiederholt sich in diesem Cluster: Den ersten Aufbau einkaufen, den laufenden Betrieb behalten. Eine FinOps-Funktion außerhalb des Unternehmens produziert ab Monat drei keine Entscheidungen mehr, weil die Person, die einen Modell-Standard ändern kann, intern sitzt.

FAQ

Wie viel sparen Caching und Batch tatsächlich?

Zusammen genug, um die Form der Rechnung zu ändern, nicht nur ihre Höhe. Ein Cache-Read kostet 0,1x Basis-Input und auf Opus 5.5 und Sonnet 5.5 nur 0,05x, und die Batch-API nimmt 50 Prozent auf Input und Output. Beides stapelt. Für eine Last mit grossem stabilem Präfix und ohne Latenzanforderung ist das auf der Input-Seite etwa eine Grössenordnung. Für einen kurzen, latenzkritischen Einzel-Prompt ist es nichts.

Ausgabelimits oder Modell-Berechtigungen: was zuerst?

Modell-Berechtigungen, weil sie Kosten verhindern statt Arbeit zu stoppen. Das Standardmodell für neue Unterhaltungen zu setzen und Opus auf die Rollen zu beschränken, die es brauchen, kostet niemanden Produktivität. Ein Ausgabelimit blockiert ein Mitglied dagegen mitten in der Aufgabe. Berechtigungen formen die Normalnutzung, Limits begrenzen den Ausnahmefall.

Gibt ein Gruppenlimit einem Team ein gemeinsames Budget?

Nein, und das ist der häufigste Modellierungsfehler. Ein Gruppenlimit ist ein Standardwert pro Mitglied, jedes Mitglied wird gegen den eigenen Verbrauch geprüft. Fünfzig Mitglieder mit einem 200-USD-Gruppenlimit dürfen im Monat zusammen 10.000 USD verbrauchen. Wenn Sie eine gemeinsame Obergrenze brauchen, setzen Sie das Organisationslimit und beobachten die Warnungen bei 75 und 90 Prozent.

Warum stiegen unsere Token-Kosten nach einem Modellwechsel mit Preissenkung?

Höchstwahrscheinlich der Tokenizer. Claude 4.7 und neuer nutzen einen neuen Tokenizer, der für denselben Text rund 30 Prozent mehr Tokens erzeugt. Ein niedrigerer Preis pro Token kann also höhere Kosten pro Anfrage bedeuten. Vergleichen Sie Kosten pro Aufgabe, nicht pro Token, wenn Sie die Modellgeneration wechseln.

Sehen wir Claude-Code-Kosten pro Entwickler auf Bedrock?

Nicht von Anthropic. Auf Bedrock, Google Cloud und Microsoft Foundry sendet Claude Code keine Metriken an Anthropic zurück, die Anthropic-Dashboards und die Claude-Code-Analytics-API decken diese Nutzung also nicht ab. Sie brauchen OpenTelemetry-Export, ein selbst betriebenes Claude-Apps-Gateway oder ein LLM-Gateway, das Verbrauch pro Key zählt. Unser LLMOps-Leitfaden ordnet das in das Betriebsmodell ein.

Woher kommt die Zahl für Kosten pro Aufgabe im Business Case?

Aus einem gemessenen Pilot, nicht aus einer Preisliste. Nehmen Sie eine Aufgabe, führen Sie sie zwanzigmal mit dem geplanten Modell aus und lesen Sie die Token-Zahlen. Dann rechnen Sie die Caching- und Batch-Multiplikatoren dazu, die der Produktionspfad tatsächlich haben wird. Unser Business-Case-Leitfaden enthält die Rechnung und die Fehler, die die Zahl unbrauchbar machen.

Quellen

1. Anthropic: Modell- und Feature-Preise (28. Oktober 2026)
2. Anthropic: Spend Limits API (28. Oktober 2026)
3. Claude Code: Kosten steuern (28. Oktober 2026)
4. Anthropic: Mehr Transparenz und Kontrolle für Admins (28. Oktober 2026)
5. Anthropic: Claude Preise und Pläne (28. Oktober 2026)