LLM Token Usage: Warum eine 4-Token-Antwort 217 Tokens kostet

Stell GPT-5.6 eine einzeilige Matheaufgabe, und 88 % der Output-Kosten sind Reasoning, das du nie zu sehen bekommst: 10 sichtbare Tokens, 81 berechnet. GPT-5.6 ist dabei noch der harmlose Fall. Dieselbe Frage kostete auf GLM 5.2 217 Completion-Tokens für eine 4-Token-Antwort, und auf Qwen3.7-max 1.104 für exakt dieselbe Antwort. Das ist keine Anomalie, sondern die Art, wie Reasoning-Modelle von Haus aus abrechnen. Und es ist nur die erste von mehreren Token-Klassen, die die meisten Kosten-Dashboards gar nicht erst aufschlüsseln. Dieser Beitrag zerlegt ein echtes usage-Objekt, Klasse für Klasse, mit den gemessenen Zahlen.

TL;DR

• GPT-5.6 berechnete im Standard 81 Tokens für eine 10-Token-Antwort, davon 88 % Reasoning; GLM 5.2 lag bei 98 % und Qwen3.7-max bei 99,3 %.
• Claude Sonnet 5 berechnete 114 Thinking-Tokens für eine 5-Token-Antwort, ohne dass ein Thinking-Parameter mitgeschickt wurde.
• Fünf Familien antworteten ohne Thinking falsch (399, 400, 427, 466, 467); nur GPT-5.6 lag ohne Thinking richtig, und jeder Reasoning-Durchlauf sagte 401.
• Ein Claude-Cache-Write über 1.181 Tokens und der anschließende Read kosteten 0,01246 $ und 0,00566 $ — exakt die Listenpreise.

Was wir getestet haben

Jede Messung in diesem Beitrag ist derselbe Single-Turn-Prompt, an jedes Modell mit seinen Standardeinstellungen geschickt, sofern eine Zeile nichts anderes angibt:

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

Die richtige Antwort ist 401 (333 Vielfache von 3, plus 200 Vielfache von 5, minus 66 doppelt gezählte ergibt 467; zieht man die 66 Vielfachen von 15 ab, bleiben 401). Wir haben sie bewusst gewählt: Die sichtbare Antwort ist winzig und liegt auf jedem Tokenizer fest bei 3-4 Tokens, es gibt genau eine richtige Antwort, sodass sich prüfen lässt, ob das Nachdenken etwas gebracht hat, und sie ist gerade schwer genug, dass die Modelle nachdenken wollen — genau das Verhalten, das hier untersucht wird.

Die fünf Token-Klassen auf deiner Rechnung

Eine moderne Completion wird mit bis zu fünf verschiedenen Token-Klassen zu vier verschiedenen Preisen abgerechnet. Eine einzige pauschale Zahl “verbrauchte Tokens” verbirgt das alles.

Die Feldnamen oben entsprechen dem OpenAI-kompatiblen Schema. Claude trägt dieselben fünf Klassen unter eigenen Namen: input_tokens und output_tokens, wobei Thinking in output_tokens_details.thinking_tokens gemeldet und als Output abgerechnet wird und der Cache Write nach TTL weiter in ein cache_creation-Objekt aufgeteilt wird (ephemeral_5m_input_tokens mit 1,25x, ephemeral_1h_input_tokens mit 2x). Gleiche Anatomie, andere Labels — dieses Parsing-Problem kommt in einem späteren Abschnitt wieder.

Die fünf Klassen und ihre Preismultiplikatoren, beschriftet mit den OpenAI-kompatiblen und den Anthropic-Feldnamen. Die 88 %-Angabe ist der gemessene Reasoning-Anteil von GPT-5.6 aus dem obigen Beispiel.

So sieht das echte Objekt hinter der Schlagzeile aus — GPT-5.6 mit Standardeinstellung, das die Testfrage beantwortet:

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

Hier steckt die Abrechnungsarithmetik, und man sollte sie einmal explizit durchrechnen. Die Antwort, die du bekommen hast, ist completion_tokens abzüglich reasoning_tokens: 81 − 71 = 10 Tokens, das Wort “401” und seine Formatierung. Die anderen 71 Tokens sind Chain-of-Thought, abgerechnet zum vollen Output-Preis, 88 % der Output-Kosten — und bei GPT-5.6 kannst du keinen einzigen davon lesen. Jede “sichtbare Antwort”-Zahl in diesem Beitrag wird genauso berechnet. Anderswo wird das Verhältnis nur noch krasser: GLM 5.2 beantwortete dieselbe Frage mit 217 Completion-Tokens für eine 4-Token-Antwort. Ein Kostenmodell, das completion_tokens als “das, was das Modell gesagt hat” liest, liegt hier um den Faktor 8 daneben und dort um den Faktor 54.

Reasoning ist das Budget – und es ist steuerbar

Dieselbe einzeilige Frage über alle Thinking-Einstellungen hinweg, die die drei steuerbaren Modellfamilien akzeptieren, über ein Gateway, 2026-07-13/14 (die Zeilen sind pro Familie von am wenigsten zu am meisten Reasoning sortiert; die Flaggschiff-Defaults der übrigen Familien folgen im nächsten Abschnitt):

Vier Dinge, die man ehrlich aus dieser Tabelle herauslesen sollte:

• Wo der Hebel wirkt, wirkt er stark. reasoning_effort: none lieferte für $0.000062 die korrekte Antwort, 8,5x unter Lunas Default, und bei schwereren Aufgaben haben wir 20x auf GLM 5.2 gemessen. Auch die Tier-Wahl gehört zum selben Hebel: Das Flaggschiff von GPT-5.6 beantwortete diese Frage per Default mit null Reasoning (nächster Abschnitt), ein größeres Modell, das nicht nachdenken muss, kann also billiger sein als ein kleineres, das es tut.
• Und wo er nicht wirkt, ist er nahezu wirkungslos. Wie weit sich der Regler drehen lässt, ist ein Familienmerkmal: monoton mit 5x Kostenspanne bei Sonnet 5 (84 bis 249), schwach und ungeordnet bei GPT-5.6, fast wirkungslos bei Qwen3.7-max (low verbrauchte immer noch 974 Reasoning-Tokens gegenüber 1.096 beim Default), tot bei DeepSeek V4 Pro (267 gegen 269).
• Labels sind nicht monoton, und Defaults sind nicht deterministisch. high von GPT-5.6 verbrauchte hier weniger Tokens als sein medium; GLMs low verbrauchte in unserem früheren Beitrag mehr als sein high; Sonnet 5 dachte 114 Tokens lang bei einem Request, der gar keinen thinking-Parameter enthielt; und derselbe GLM-Default-Request verbrauchte in einem Lauf 213 Reasoning-Tokens und in einem anderen 1.312 – Faktor sechs auseinander. Miss die tatsächliche Wirkung des Reglers auf deiner Last; lies sie nicht am Label ab.
• Billig-und-falsch ist der wiederkehrende Fehlerfall. Beide Familien, die hier ohne Thinking antworteten, antworteten falsch (GLM 399, Sonnet 5 467); die vollständige Aufstellung über alle fünf Familien folgt im nächsten Abschnitt. Reasoning ist ein Korrektheitsbudget, und ob sich das Kürzen lohnt, hängt an der Aufgabe, nicht am Modell.

Die praktische Regel: Behandle reasoning_tokens als eigenständigen Posten. Er wird zum Output-Tarif abgerechnet, übertrifft die sichtbare Antwort regelmäßig um ein Vielfaches und reagiert auf Parameter, deren echte Wirkung du messen musst. Bei GPT-5.6 haben sich außerdem die Preisregeln geändert; der GPT-5.6 Kostenguide behandelt den Write-Aufschlag und die Cache-Key-Anforderung.

Kannst du überhaupt lesen, wofür du bezahlt hast?

„Getrennt von der Antwort” heißt nicht automatisch „versteckt”, und diesen Unterschied lohnt es sich genau zu benennen. Wir haben nicht nur die Usage geprüft, sondern die Response-Bodies selbst:

• GLM 5.2, DeepSeek, Qwen3.7-max und MiniMax liefern den vollständigen Reasoning-Text in einem Feld reasoning_content neben der Antwort (hier 3.987, 1.604, 2.509 und 581 Zeichen). Als Entwickler kannst du jeden abgerechneten Token lesen; Endnutzer sehen ihn nur, wenn du ihn renderst, und das tun die meisten Anwendungen nicht.
• GPT-5.6 gibt die rohe Gedankenkette nicht heraus; mehr als eine Zusammenfassung bekommst du nicht. Die Response kann eine vom Modell geschriebene reasoning.summary enthalten (hier 359 Zeichen), aber die 91 abgerechneten Tokens sind der versteckte Rohtext, nicht die Zusammenfassung. Am nächsten an diesem Text kommt reasoning.encrypted_content: ein verschlüsselter Blob, den du für die Kontinuität über mehrere Turns zurückgeben, aber nie entschlüsseln kannst. Die bezahlten Tokens liegen in deinem eigenen Response-Body, unlesbar.
• Bei Claude hängt es davon ab, wie du fragst. Unser Sonnet-5-Call mit adaptivem Thinking lieferte einen thinking-Block mit leerem Text, während thinking_tokens 114 abrechnete: der Beweis, dass gedacht wurde, aber nichts zum Lesen. Fable 5 verhielt sich mit seinem stets aktiven Default genauso (59 abgerechnet, leerer Block). Derselbe Sonnet-5-Call mit einem expliziten Reasoning-Budget lieferte dagegen den echten Thinking-Text (73 Tokens abgerechnet, Text vorhanden). Wie du fragst, entscheidet, was du sehen kannst.

Die Abrechnung ist also universell, die Sichtbarkeit nicht: jede Familie berechnet Reasoning zum Output-Tarif, und ob du den gekauften Text prüfen kannst, reicht von „vollständig” über „nur Zusammenfassung” bis zum „signierten leeren Block”.

Kommt der Text zurück, kannst du ihn mechanisch bewerten. Unsere Frage hat fünf feste Zwischenergebnisse (333, 200, 66, 467, 401), und jeder zurückgegebene Reasoning-Text enthielt alle: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code und MiniMax M3 lieferten jeweils eine komplette Herleitung, während die Low-Effort-Varianten je einen Schritt ausließen. Für alle, die den Weg brauchen und nicht nur die Antwort, ist das die Trennlinie: mit reasoning_content kannst du prüfen, wofür du bezahlt hast; bei einer Zusammenfassung oder einem leeren Block musst du darauf vertrauen. Invisible Tokens, Visible Bills formalisiert diese Lücke bei der Nachvollziehbarkeit, und PALACE schätzt verstecktes Reasoning von außen ab.

Dieselbe Frage über die besten Modelle jeder Familie hinweg

Die Steuerungstabelle hat mit bestimmten Stufen gezeigt, an welchen Reglern man drehen kann. Hier ist das neueste Flaggschiff jeder Familie bei derselben Frage, jeweils mit den Standardeinstellungen:

Abgerechnete Ausgabe-Tokens pro Flaggschiff für dieselbe Frage (schraffiertes Orange = Reasoning-Anteil; Grün = die sichtbare Antwort). Das Sternchen bei MiniMax: seine Nutzung enthält keine Reasoning-Zählung, daher wird der Anteil durch Subtraktion rekonstruiert und gegen den zurückgelieferten Reasoning-Text verifiziert. Das Häkchen bei GPT-5.6 sol markiert den einzigen korrekten Zero-Reasoning-Durchlauf; das Kreuz bei Gemini 3.5 Flash markiert die einzige falsche Flaggschiff-Antwort (466).

Alle Reporting-Stile in einem Chart:

• Sieben von acht Flaggschiffen haben korrekt geantwortet, zu extrem unterschiedlichen Preisen für dieselbe 401. Qwen3.7-max verbrauchte 1.096 Reasoning-Tokens, 22 Sekunden und $0.0084; das Flaggschiff von GPT-5.6 verbrauchte null Reasoning-Tokens und $0.00031. Ein Kostenunterschied von 27x und ein Latenzunterschied von 7x für dieselbe richtige Antwort – so sieht das Reasoning-Budget sichtbar gemacht aus.
• MiniMax liefert seinen Reasoning-Text zurück, aber keine Anzahl. 260 Completion Tokens für eine sichtbare Antwort aus 3 Tokens: Die Response enthält die vollständige Herleitung in reasoning_content, aber completion_tokens_details hat keine Reasoning-Zeile. Fehlt die Anzahl, rekonstruiert man sie durch Subtraktion: Completion minus sichtbare Tokens ergibt die Anzahl der versteckten Ausgabe.
• Gemini 3.5 Flash ist der Ausreißer: das einzige Flaggschiff mit falscher Antwort (466), bei 3 Completion Tokens und ohne Reasoning-Anzahl an irgendeiner Stelle. Sein Geschwistermodell 2.5 Flash brauchte einmal 12,5 Sekunden, um eine 401 aus 3 Tokens zu produzieren, ohne dass in der Abrechnung stand, warum – ein Wiederholungslauf antwortete 427.
• Falsche Antworten finden sich bei den kleineren Stufen und wenn Thinking deaktiviert ist. GLM mit ausgeschaltetem Thinking sagte 399; Sonnet 5 mit deaktiviertem Thinking sagte 467; das ältere qwen3-max dachte gar nicht nach (3 Tokens) und sagte 400; Kimi K2.5, das keinen Reasoning-Kanal hat, dachte laut über 144 sichtbare abgerechnete Tokens, leitete intern 401 in seiner eigenen Prosa her und kam dann zu 400. Fünf Familien, fünf verschiedene falsche Antworten: 399, 400, 427, 466, 467; nur GPT-5.6 war ohne Reasoning korrekt.

Cache-Tokens: zwei Richtungen, Faktor 12 dazwischen

Prompt Caching teilt den Input in zwei weitere Klassen auf, und der Preisunterschied dazwischen ist der ganze Grund für diese Aufteilung: Writes werden bei Claude mit dem 1,25-fachen des Input-Preises abgerechnet (2x bei einer TTL von 1 Stunde), Reads mit dem 0,1-fachen. Zwei gemessene Opus-4.8-Calls mit einem gecachten System-Prompt von 1.181 Tokens kosteten $0,01246 (Write) und dann $0,00566 (Read), beide auf die sechste Nachkommastelle mit den Listenpreisen abgeglichen; die Kosten auf der Input-Seite fielen von Call zu Call um etwa das 11-fache. Worum es in diesem Post geht, ist die Abrechnung: Wenn du cache_creation_input_tokens und cache_read_input_tokens in einen Topf “Input Tokens” wirfst, kannst du den Rabatt weder überprüfen noch merken, wenn er stillschweigend ausbleibt. Und das passiert häufiger, als die Docs vermuten lassen: Unsere Caching-Messungen haben effektive Schwellenwerte gefunden, die 1,4- bis 2,4-mal über den dokumentierten Minima liegen, und der Prompt-Caching-Guide geht ausführlich auf die Mechanik pro Provider ein.

Warum deine lokale Schätzung nie mit der Rechnung übereinstimmt

Ein verbreitetes Muster ist, die Kosten clientseitig mit einer Tokenizer-Library zu schätzen und später abzugleichen. Drei Gründe, warum die Zahlen nicht passen:

• Tokenizer unterscheiden sich pro Anbieter. Wer Claude-Text mit einem OpenAI-Tokenizer zählt, misst mit dem falschen Maßstab; derselbe String wird bei jeder Familie anders tokenisiert.
• Du zahlst für mehr als deine Nachricht. System-Prompts und Tool-Schemas sind Input Tokens bei jedem Request, der sie mitschickt, und werden bei einer lokalen Schätzung leicht vergessen.
• Reasoning ist bis zur Response unvorhersehbar. Kein clientseitiger Zähler kann vorhersagen, wie viele Thinking Tokens ein Modell verbraucht; das erfährst du erst aus dem zurückgelieferten usage.

Das zurückgelieferte usage-Objekt ist der eigene Abrechnungssatz des Upstreams. Der günstigste genaue Zähler ist also, mit dem Schätzen aufzuhören und ihn einfach auszulesen. Der Haken: Jeder Provider formt es anders. Gecachte Tokens allein tauchen je nach Familie als cached_tokens, prompt_cache_hit_tokens, total_cached_tokens oder cache_read_input_tokens auf.

Auch die Detail-Objekte folgen keinem festen Schema. OpenAIs Referenz dokumentiert vier Felder auf der Completion-Seite: reasoning_tokens, audio_tokens sowie das Predicted-Outputs-Paar accepted_prediction_tokens / rejected_prediction_tokens; abgelehnte Prediction Tokens erscheinen nie im Output, werden aber trotzdem als Completion Tokens abgerechnet. Auf der Prompt-Seite kommen bei derselben Struktur neben cached_tokens noch text_tokens, audio_tokens und image_tokens dazu; GPT-5.6 ergänzt cache_write_tokens, und wir haben video_tokens in freier Wildbahn gesehen. Anbieter erweitern das Ganze nach Belieben: Kimi K2.7 lieferte ein undokumentiertes completion_tokens_details.text_tokens, und Gemini zählt Thinking- und Tool-Use-Tokens getrennt unter eigenen Namen. Parse defensiv: Rechne mit unbekannten Detail-Feldern und geh nie davon aus, dass ein fehlendes Feld null bedeutet.

Genau hier zeigt sich der Wert eines Gateways: Synthorai normalisiert all das in ein einziges Objekt, mit reasoning_tokens und den beiden Cache-Richtungen befüllt über OpenAI, Anthropic, Gemini und die Open-Weight-Familien hinweg. Ein Parser deckt damit jedes Modell ab, an das du routest.

Vom Sehen zum Stoppen

Das Ablesen der Abrechnung ist nur die halbe Miete. Die andere Hälfte besteht darin, Überschreitungen unmöglich zu machen, statt sie bloß sichtbar zu halten. Dashboards zum Monatsende melden eine böse Überraschung erst, wenn das Geld weg ist, und ein Agent, der in einer Retry-Schleife feststeckt, liest keine Dashboards. Auf dem Gateway trägt jeder Key ein quota mit erfasstem used_quota und einem RPM-Limit, das zur Request-Zeit durchgesetzt wird: Ein Key, der sein Budget aufbraucht, bekommt beim nächsten Request einen expliziten Fehler – und nicht drei Wochen später eine höhere Rechnung. Die Zuordnung pro Request (welcher Key, welches Modell, BYOK oder Platform-Billing) kommt im selben Response-Envelope zurück. Damit sind die Kosten pro Feature ein simples Group-by und kein Rekonstruktionsprojekt.

Aus den Messwerten ergibt sich diese Reihenfolge: Lies reasoning_tokens und die Cache-Felder, bevor du irgendetwas optimierst, stell den Reasoning-Regler pro Task ein, und setz auf jeden Key ein hartes Quota, dessen Fehlermodus eine Schleife ist. Um zu sehen, was ein bestimmter Mix aus Modellen und Token-Klassen bei deinem Volumen kostet, rechnet der Cost Optimizer das anhand derselben Per-Token-Raten aus, die oben verwendet wurden.

← Zurück zum Blog