Im selben Zeitfenster, über denselben Key, zeigten drei Systeme drei Summen: $0.20 im Dashboard des Anbieters, $0.07231 in Langfuse, $0.0711 in Grafana. Der Key existierte nur für diesen Prüfstand, fremde Kosten konnten also nicht hineinlaufen. Die Frage sah aus wie „welches der drei lügt“.
Die richtige Frage war eine andere.
Wie viele unabhängige Messungen liegen hier vor
Langfuse und Grafana sind keine zwei Zeugen. Beide bezogen ihre Zahl aus derselben Formel: Tokens_aus_der_Antwort × statischer Preis aus der Config. Sie stimmten miteinander überein, nicht weil beide recht hatten, sondern weil sie sich denselben Input teilten. Es gibt genau eine unabhängige Quelle, und das ist das Ledger des Anbieters — dagegen wird abgerechnet.
| Quelle | Woher die Zahl stammt | Unabhängig |
|---|---|---|
| Ledger des Anbieters | danach wird abgerechnet | ja |
| Langfuse | Formel „Tokens × Preis“ | nein |
| Prometheus / Grafana | dieselbe Formel | nein |
Zwei übereinstimmende Dashboards lesen sich wie eine Bestätigung und sind keine. Zeugen zählt man nach Datenquellen, nicht nach Panels. Danach verengte sich die Untersuchung auf eine Frage: Warum rechnet die einzige Formel um fast das Dreifache zu niedrig?
Die Preise stimmten
Erster Verdacht: Die Preise in der Config sind veraltet. Diese Hypothese lässt sich billig erledigen — der Modellkatalog des Aggregators ist öffentlich und braucht keinen Key. Der Abgleich passte bis zur dritten Stelle: 0.43 / 0.87 gegen 0.435 / 0.87 beim einen Modell, exakt 0.10 / 0.40 beim anderen.
Nebenbei tauchte ein Detail auf, das später wichtig wurde: Bei einem Reasoning-Modell steht im Katalog eine eigene Preiszeile, internal_reasoning, die nicht dem Completion-Preis entspricht.
Das Indiz: derselbe Faktor in beide Richtungen
Eine direkte Probe mit aktiviertem Usage Accounting zeigte, dass die Abweichung nicht überall auftrat:
| Modell | Eigene Formel | Anbieter berechnete | Verhältnis |
|---|---|---|---|
| gemini-Klasse | $6.67e-5 | $6.67e-5 | 1.00 |
| deepseek-Klasse | $2.81e-4 | $4.82e-4 | 1.7× |
Ein Modell traf auf den Cent, das andere lag um den Faktor 1,7 daneben. Entscheidend ist nicht die Lücke selbst, sondern ihre Form. In cost_details war der Prompt-Anteil mit 0.745/M statt 0.435/M berechnet — und der Faktor 1,7 war beim Prompt und bei der Completion identisch.
Bei korrekten Preisen kann ein und derselbe Multiplikator in beide Richtungen zugleich nur eines bedeuten: Die Token-Zahlen in der Antwort sind nicht die Zahlen, nach denen abgerechnet wird.
Was unter der Abweichung lag
Der Aggregator rechnete nach den nativen Tokens des Anbieter-Modells ab, während usage.prompt_tokens und usage.completion_tokens normalisierte lieferten — auf eine gemeinsame Skala gebracht, damit sich verschiedene Modelle vergleichen lassen. Ein Modell hat einen dichteren nativen Tokenizer, daher die 1,7×. Beim anderen sind normalisierte gleich nativen, deshalb passte es.
Der Rest ist Arithmetik: Der teuerste und am stärksten belastete Alias auf dem Prüfstand war genau der abweichende. Er zog die Gesamtsumme von $0.20 auf $0.07 herunter.
Die Trennung der beiden Zähler ist nicht verschwunden — sie lebt bis heute in der API. Der Endpunkt für Generierungsstatistik dokumentiert beide Sätze als getrennte Felder: tokens_prompt und tokens_completion gegen native_tokens_prompt, native_tokens_completion, native_tokens_reasoning, native_tokens_cached — letztere mit dem Vermerk „as reported by provider“.
Die Regel, die jeden einzelnen Anbieter überlebt
Die eigene Kostenformel ist eine Schätzung, keine Messung. Ihr Platz ist der Fallback-Pfad. Die maßgebliche Zahl kommt von dem, der die Rechnung stellt.
Praktisch heißt das vier Dinge:
usage.costundcost_detailsaus der Antwort des Anbieters als Quelle der Wahrheit nehmen.- Die statische Preistabelle als Sicherheitsnetz behalten: Sie wird dort gebraucht, wo der Anbieter gar keinen Preis liefert — etwa beim lokalen Tier, wo der Preis ohnehin null ist.
- In die Config schreiben, dass die Preise ein Fallback sind. Sonst werden sie in einem halben Jahr wieder als Wahrheit gelesen.
- Prüfen, dass das Client-SDK nicht-standardisierte Felder nicht abschneidet.
costundcost_detailsgehören nicht zum OpenAI-Schema vonusageund landen in den zusätzlichen Feldern des Antwortmodells; in der Praxis überstehen sie das SDK und sind übergetattr,model_dumpundmodel_extraerreichbar — das bestätigt man aber mit einer Probe, nicht mit Vertrauen.
Das Rezept ist abgelaufen, die Regel nicht
Die Messung stammt vom 14. Juli 2026. Vor der Veröffentlichung habe ich die Dokumentation des Anbieters geprüft — sie beschreibt ein anderes Verhalten.
| Was | Messung 14.07.2026 | Doku am 23.08.2026 |
|---|---|---|
| Zähler in der Antwort | normalisiert | „calculated using the model's native tokenizer“ |
| Abrechnungsgrundlage | native Tokens | „pricing are based on these native token counts“ |
| Usage Accounting aktivieren | Parameter im Request-Body | „always included automatically“ |
Der Anbieter hat das Verhalten angeglichen: Die Zähler in der Antwort sind nativ geworden, und der frühere Parameter usage: {include: true} gilt als deprecated und hat laut Doku keine Wirkung. Ihn zu setzen bringt nichts mehr — und genau solche Zeilen sollte man nicht aus einem halbjahralten Artikel übernehmen.
Die Messung ist damit nicht widerlegt: Die Preise waren gegen den Live-Katalog geprüft, ein Modell traf auf den Cent, das andere wich mit identischem Faktor in beide Richtungen ab. Geändert hat sich der Anbieter, nicht der Befund. Die maßgebliche Zahl zu lesen statt selbst nachzurechnen bleibt der einzige Weg, nicht vom Ledger abzuweichen — und über das Einsparen von Tokens sagt das nichts, das ist ein eigenes Thema.
Warum zwei Summanden Arithmetik nicht reichen
Die Formel prompt × Preis_in + completion × Preis_out setzt voraus, dass sich die ganze Generierung mit zwei Zahlen beschreiben lässt. Für Reasoning-Modelle ist das auf mindestens zwei Arten falsch.
Erstens die eigene Preiszeile: Reasoning kann zu einem eigenen Satz abgerechnet werden, der vom Completion-Preis abweicht. Zweitens die nicht offensichtliche Verschachtelung. In meiner Probe lagen die Reasoning-Tokens innerhalb von completion_tokens (261 von 317) — das ist aber eine Aussage über ein konkretes Paar aus Anbieter und Modell, keine allgemeine Regel. Liegen sie bei einem anderen Paar daneben, verliert die Formel stillschweigend eine ganze Kostenposition.
Der Cache gehört ebenfalls hierher: input_cache_read und cache_write_tokens werden separat berechnet. In meinem Lauf waren sie null, wie sich die Formel bei warmem Cache verhält, habe ich also nicht getestet.
Es gibt auch eine benachbarte Klasse, in der überhaupt kein Preis existiert: Eine Generierung, die anbieterseitig fehlschlägt, kommt mit Status 200, ohne Inhalt und ohne Kostenzeile an — keine Schutzschicht sieht sie. Dort fehlt der Preis. Hier ist er da und nur auf den falschen Tokens berechnet.
Die Prüfung lügt auch
Der Abgleich landete nicht beim ersten Versuch auf null, und beide Fehlgriffe steckten in der Prüfung selbst, nicht im System.
Zuerst lief ein Grep gegen einen Metriknamen, den es nicht gab, und lieferte null. Null sieht aus wie „der Fix hat nicht funktioniert“, bedeutet aber „ich habe das Falsche gefragt“.
Dann fiel das Ledger-Delta, direkt nach dem Lauf gelesen, kleiner aus als das Aufgezeichnete: Kind-Workflows schickten ihre Aufrufe zuletzt, und der Account-Zähler des Anbieters holte verzögert auf. Zwei Minuten später stimmten die Zahlen exakt überein — $0.019571 gegen $0.019571.
Beide Fallen sind dieselbe Klasse: Die Prüfung log über sich selbst, nicht über ihren Gegenstand. Dieselbe Klasse wie ein grüner Security-Policy-Header, der nichts beweist, weil er in einem Zustand erhoben wurde, in dem die relevanten Requests noch gar nicht stattfinden.
Was bleibt, wenn der Anbieter alles repariert
Die Trennung nativ gegen normalisiert ist ein Detail eines Aggregators, und sie ist bereits geglättet. Der Mechanismus darunter nicht.
Jede Schicht zwischen Ihnen und dem Modell normalisiert: Sie bringt Zähler auf eine gemeinsame Skala, aggregiert, rundet, fügt eigene Abrechnungszeilen hinzu. Solange die Kosten auf Ihrer Seite per Multiplikation entstehen, messen Sie Ihr Modell der Ausgaben und nicht die Ausgaben. Abweichen wird es leise, und zwar genau an dem Tag, an dem sich stromaufwärts etwas ändert.
Eine einfache Regel: Kosten bekommen eine Quelle, und das ist nicht Ihre Formel.