LLM-Tokenverbrauch: 4 Tokens Antwort, 217 Tokens berechnet

Stellt man GPT-5.6 eine einzeilige Rechenaufgabe, entfallen 88% der Output-Kosten auf Reasoning, das nie sichtbar wird: 10 sichtbare Tokens, 81 abgerechnete. Dabei ist GPT-5.6 noch der moderate Fall. Für dieselbe Aufgabe rechnete GLM 5.2 bei einer Antwort mit 4 Tokens insgesamt 217 Completion-Tokens ab. Qwen3.7-max kam für die identische Antwort auf 1,104. Das ist kein Ausreißer, sondern bei Reasoning-Modellen Teil des Abrechnungsmodells. Reasoning ist außerdem nur die erste von mehreren Token-Klassen, die in den meisten Kosten-Dashboards nicht separat ausgewiesen werden. Dieser Beitrag zerlegt ein echtes usage-Objekt Klasse für Klasse und zeigt die gemessenen Werte.

TL;DR

• GPT-5.6 rechnete in der Default-Konfiguration für eine Antwort mit 10 Tokens insgesamt 81 Tokens ab, davon 88% für Reasoning; bei GLM 5.2 waren es 98%, bei Qwen3.7-max 99.3%.
• Claude Sonnet 5 rechnete für eine Antwort mit 5 Tokens zusätzlich 114 Thinking-Tokens ab, obwohl kein Thinking-Parameter gesetzt war.
• Ohne Thinking antworteten fünf Modellfamilien falsch (399, 400, 427, 466, 467). Nur GPT-5.6 lag auch ohne Thinking richtig, und jeder Lauf mit Reasoning lieferte 401.
• Ein Claude-Cache-Write mit 1,181 Tokens und der anschließende Read kosteten $0.01246 beziehungsweise $0.00566, exakt entsprechend den Listenpreisen.

Testaufbau

Alle Messungen in diesem Beitrag basieren auf demselben Single-Turn-Prompt. Sofern in einer Tabellenzeile nichts anderes angegeben ist, wurde er mit den Default-Einstellungen an das jeweilige Modell gesendet:

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 lautet 401: Es gibt 333 Vielfache von 3 und 200 Vielfache von 5. Zieht man die 66 doppelt gezählten Vielfachen von 15 ab, erhält man 467. Davon müssen nochmals die 66 Vielfachen von 15 entfernt werden, sodass 401 übrig bleiben. Die Aufgabe wurde bewusst gewählt: Die sichtbare Antwort ist sehr kurz und umfasst je nach Tokenizer nur 3-4 Tokens. Es gibt genau eine richtige Lösung, daher lässt sich leicht prüfen, ob das Thinking einen Nutzen hatte. Gleichzeitig ist die Aufgabe anspruchsvoll genug, dass Modelle typischerweise Reasoning einsetzen. Genau dieses Verhalten soll hier untersucht werden.

Die fünf Token-Klassen auf der Rechnung

Bei einer modernen Completion können bis zu fünf verschiedene Token-Klassen mit vier unterschiedlichen Tarifen abgerechnet werden. Eine einzelne Kennzahl wie „verbrauchte Tokens“ verschleiert diese Aufteilung vollständig.

Die Feldnamen in der Tabelle entsprechen dem OpenAI-kompatiblen Format. Claude bildet dieselben fünf Klassen mit eigenen Bezeichnungen ab: input_tokens und output_tokens, dazu Thinking unter output_tokens_details.thinking_tokens, das als Output abgerechnet wird. Cache-Writes werden zusätzlich nach TTL in einem cache_creation-Objekt aufgeteilt: ephemeral_5m_input_tokens zum Faktor 1.25x und ephemeral_1h_input_tokens zum Faktor 2x. Inhaltlich ist die Aufteilung gleich, nur die Bezeichnungen unterscheiden sich. Auf das daraus entstehende Parsing-Problem gehen wir später noch ein.

Die fünf Klassen mit ihren Preismultiplikatoren und den jeweiligen OpenAI-kompatiblen sowie Anthropic-Feldnamen. Die 88% entsprechen dem gemessenen Reasoning-Anteil von GPT-5.6 aus dem Beispiel oben.

Das echte Objekt hinter der Überschrift stammt von GPT-5.6 mit Default-Einstellungen bei der Beantwortung der Testfrage:

{
  "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
}

Darin steckt die gesamte Abrechnungslogik. Die erhaltene Antwort ergibt sich aus completion_tokens abzüglich reasoning_tokens: 81 − 71 = 10 Tokens für das Wort „401“ und dessen Formatierung. Die übrigen 71 Tokens entfallen auf die Chain of Thought und werden zum vollen Output-Tarif abgerechnet. Sie machen 88% der Output-Kosten aus, und bei GPT-5.6 ist kein einziges dieser Tokens lesbar. Alle Angaben zu „sichtbaren Antworten“ in diesem Beitrag werden auf dieselbe Weise berechnet. Bei anderen Modellen fällt das Verhältnis noch extremer aus: GLM 5.2 benötigte für dieselbe Aufgabe 217 Completion-Tokens bei einer Antwort mit 4 Tokens. Ein Kostenmodell, das completion_tokens mit „dem, was das Modell ausgegeben hat“ gleichsetzt, liegt bei GPT-5.6 um den Faktor 8 und bei GLM 5.2 um den Faktor 54 daneben.

Reasoning bestimmt das Budget und lässt sich steuern

Die folgende Tabelle zeigt dieselbe einzeilige Aufgabe für alle unterstützten Thinking-Einstellungen der drei steuerbaren Modellfamilien. Alle Anfragen liefen über dasselbe Gateway am 2026-07-13/14. Innerhalb einer Familie sind die Zeilen nach zunehmendem Reasoning-Verbrauch sortiert. Die Default-Werte der Flagship-Modelle der übrigen Familien folgen im nächsten Abschnitt.

Aus der Tabelle lassen sich vier Punkte ableiten:

• Wo der Regler funktioniert, ist sein Effekt groß. Mit reasoning_effort: none beantwortete luna die Aufgabe für $0.000062 korrekt. Das ist 8.5x günstiger als der Default. Bei anspruchsvolleren Aufgaben haben wir für GLM 5.2 einen Faktor von 20 gemessen. Auch die Wahl des Tiers gehört zu diesem Hebel: Das Flagship-Modell von GPT-5.6 beantwortete die Aufgabe standardmäßig ohne Reasoning, wie im nächsten Abschnitt zu sehen ist. Ein größeres Modell, das kein Thinking benötigt, kann dadurch günstiger sein als ein kleineres Modell mit Reasoning.
• Bei anderen Modellen bewirkt der Regler fast nichts. Wie stark sich der Regler auswirkt, hängt von der Modellfamilie ab. Bei Sonnet 5 steigt der Verbrauch monoton von 84 auf 249 Tokens und die Kosten variieren um den Faktor 5. Bei GPT-5.6 ist der Effekt gering und nicht monoton. Bei Qwen3.7-max bewirkt die Einstellung kaum etwas: Selbst mit low wurden 974 Reasoning-Tokens verbraucht, gegenüber 1,096 mit dem Default. Bei DeepSeek V4 Pro ist der Unterschied praktisch nicht vorhanden: 267 gegenüber 269.
• Die Labels sind nicht monoton, und Default-Werte liefern keine deterministischen Ergebnisse. Bei GPT-5.6 verbrauchte high weniger Tokens als medium. Bei GLM lag low in unserem früheren Beitrag über high. Sonnet 5 verbrauchte 114 Thinking-Tokens, obwohl die Anfrage keinen Thinking-Parameter enthielt. Zwei identische GLM-Anfragen mit Default-Einstellungen kamen zudem auf 213 beziehungsweise 1,312 Reasoning-Tokens, also auf einen Unterschied um den Faktor sechs. Der tatsächliche Effekt muss mit dem eigenen Workload gemessen werden und lässt sich nicht am Label ablesen.
• Günstig und falsch ist ein wiederkehrendes Muster. Beide Familien, die hier ohne Thinking antworteten, lagen falsch: GLM mit 399 und Sonnet 5 mit 467. Die Ergebnisse aller fünf Familien folgen im nächsten Abschnitt. Reasoning ist ein Budget für Korrektheit. Ob es sich lohnt, dieses Budget zu reduzieren, hängt von der Aufgabe ab, nicht vom Modell.

Die praktische Regel lautet: reasoning_tokens muss als eigener Kostenposten behandelt werden. Diese Tokens werden zum Output-Tarif abgerechnet, übersteigen die sichtbare Antwort regelmäßig um ein Vielfaches und lassen sich über Parameter beeinflussen, deren tatsächliche Wirkung gemessen werden muss. Bei GPT-5.6 haben sich außerdem die Preisregeln geändert. Der Kostenleitfaden für GPT-5.6 beschreibt den Write-Aufschlag und die erforderliche Cache-Key-Konfiguration.

Kann man das bezahlte Reasoning tatsächlich lesen?

„Getrennt von der Antwort“ bedeutet nicht automatisch „unsichtbar“. Wir haben deshalb nicht nur die Usage-Daten, sondern auch die Response-Bodies geprüft:

• GLM 5.2, DeepSeek, Qwen3.7-max und MiniMax geben den vollständigen Reasoning-Text neben der Antwort in einem reasoning_content-Feld zurück. In unseren Tests waren das 3,987, 1,604, 2,509 beziehungsweise 581 Zeichen. Entwickler können jedes abgerechnete Token lesen. Endnutzer sehen den Text nur, wenn die Anwendung ihn rendert, was die meisten Anwendungen nicht tun.
• GPT-5.6 hält die rohe Chain of Thought zurück; höchstens eine Zusammenfassung ist verfügbar. Die Response kann eine vom Modell erstellte reasoning.summary enthalten, hier mit 359 Zeichen. Die 91 abgerechneten Tokens beziehen sich jedoch auf den verborgenen Rohtext und nicht auf diese Zusammenfassung. Am nächsten kommt man diesem Text über reasoning.encrypted_content: ein verschlüsselter Blob, der für Multi-Turn-Kontinuität erneut mitgesendet, aber nicht entschlüsselt werden kann. Die bezahlten Tokens stehen damit unlesbar im eigenen Response-Body.
• Bei Claude hängt die Sichtbarkeit von der Anfrage ab. Unser Aufruf von Sonnet 5 mit adaptivem Thinking lieferte einen thinking-Block mit leerem Text, obwohl 114 thinking_tokens abgerechnet wurden: Das Modell hat nachweislich gedacht, aber es gibt nichts zu lesen. Fable 5 verhielt sich mit seinem standardmäßig immer aktiven Thinking genauso: 59 abgerechnete Tokens bei leerem Block. Derselbe Sonnet-5-Aufruf mit explizitem Reasoning-Budget gab dagegen den tatsächlichen Thinking-Text zurück: 73 Tokens wurden abgerechnet und der Text war vorhanden. Die Art der Anfrage entscheidet darüber, was sichtbar wird.

Die Abrechnung ist bei allen Anbietern gleich, die Sichtbarkeit nicht: Jede Modellfamilie berechnet Reasoning zum Output-Tarif. Der Zugriff auf den gekauften Text reicht von „vollständig lesbar“ über „nur als Zusammenfassung“ bis hin zu „signierter, leerer Block“.

Wenn der Text zurückgegeben wird, lässt er sich automatisch bewerten. Unsere Aufgabe hat fünf feste Zwischenergebnisse: 333, 200, 66, 467 und 401. Jeder zurückgegebene Reasoning-Text enthielt alle fünf Werte. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code und MiniMax lieferten jeweils eine vollständige Herleitung; bei den Low-Effort-Varianten fehlte jeweils ein Schritt. Wer nicht nur die Antwort, sondern auch den Lösungsweg benötigt, hat damit eine klare Trennlinie: Mit reasoning_content lässt sich das bezahlte Reasoning prüfen. Bei einer Zusammenfassung oder einem leeren Block muss man dem Modell vertrauen. Unsichtbare Tokens, sichtbare Rechnungen formalisiert diese Lücke bei der Nachvollziehbarkeit, während PALACE verborgenes Reasoning von außen schätzt.

Dieselbe Aufgabe mit dem besten Modell jeder Familie

Die vorherige Tabelle verwendete bestimmte Tiers, um die Steuerungsmöglichkeiten zu zeigen. Hier folgt das jeweils neueste Flagship-Modell jeder Familie mit Default-Einstellungen und derselben Aufgabe:

Abgerechnete Output-Tokens pro Flagship-Modell für dieselbe Aufgabe (orange schraffiert = Reasoning-Anteil; grün = sichtbare Antwort). Der Stern bei MiniMax weist darauf hin, dass die Usage keine Anzahl für Reasoning enthält. Der Anteil wurde deshalb per Subtraktion rekonstruiert und anhand des zurückgegebenen Reasoning-Texts geprüft. Der Haken bei GPT-5.6 sol markiert den einzigen richtigen Lauf ohne Reasoning; das Kreuz bei Gemini 3.5 Flash die einzige falsche Antwort eines Flagship-Modells (466).

Das Diagramm enthält alle relevanten Reporting-Varianten:

• Sieben von acht Flagship-Modellen antworteten richtig, allerdings zu sehr unterschiedlichen Preisen für dieselbe 401. Qwen3.7-max verbrauchte 1,096 Reasoning-Tokens, benötigte 22 Sekunden und kostete $0.0084. Das Flagship-Modell von GPT-5.6 verbrauchte keine Reasoning-Tokens und kostete $0.00031. Bei identischer richtiger Antwort liegen die Kosten um den Faktor 27 und die Latenz um den Faktor 7 auseinander. Der Unterschied entsteht durch das Reasoning-Budget.
• MiniMax gibt den Reasoning-Text zurück, aber keine Token-Anzahl. Insgesamt wurden 260 Completion-Tokens für eine sichtbare Antwort mit 3 Tokens abgerechnet. Die Response enthält die vollständige Herleitung in reasoning_content, aber completion_tokens_details weist Reasoning nicht separat aus. Fehlt die Anzahl, kann sie durch Subtraktion rekonstruiert werden: Completion-Tokens minus sichtbare Tokens ergeben die Anzahl der nicht sichtbaren Output-Tokens.
• Gemini 3.5 Flash ist der Ausreißer: Es ist das einzige Flagship-Modell mit einer falschen Antwort (466), 3 Completion-Tokens und keiner Angabe zu Reasoning. Das Schwestermodell 2.5 Flash benötigte in einem früheren Test 12.5 Sekunden für eine 3 Tokens lange Antwort mit 401, ohne dass die Abrechnung den Grund dafür auswies. Bei einer Wiederholung antwortete es mit 427.
• Falsche Antworten treten vor allem bei kleineren Tiers und deaktiviertem Thinking auf. GLM antwortete ohne Thinking mit 399; Sonnet 5 mit deaktiviertem Thinking mit 467. Das ältere qwen3-max verwendete überhaupt kein Thinking, gab 3 Tokens aus und antwortete mit 400. Kimi K2.5 besitzt keinen Reasoning-Kanal, führte die Herleitung aber sichtbar in 144 abgerechneten Tokens aus, ermittelte dabei selbst 401 und kam anschließend trotzdem zum Ergebnis 400. Fünf Familien lieferten fünf unterschiedliche falsche Antworten: 399, 400, 427, 466 und 467. Nur GPT-5.6 lag ohne Reasoning richtig.

Cache-Tokens: zwei Richtungen mit Faktor 12

Prompt-Caching teilt den Input in zwei weitere Klassen auf. Der große Preisunterschied erklärt, warum diese Trennung nötig ist: Bei Claude werden Writes mit dem 1.25-Fachen des Input-Tarifs berechnet, bei einer TTL von einer Stunde mit dem 2-Fachen. Reads kosten dagegen nur das 0.1-Fache. Zwei gemessene Aufrufe von Opus 4.8 mit einem gecachten System-Prompt von 1,181 Tokens kosteten zunächst $0.01246 für den Write und anschließend $0.00566 für den Read. Beide Beträge stimmen bis auf die sechste Dezimalstelle mit den Listenpreisen überein; die Input-Kosten sanken vom ersten zum zweiten Aufruf ungefähr um den Faktor 11. Für die Abrechnung ist entscheidend: Wer cache_creation_input_tokens und cache_read_input_tokens gemeinsam als „Input-Tokens“ erfasst, kann weder den Rabatt prüfen noch erkennen, wenn das Caching unbemerkt aussetzt. Das passiert häufiger, als die Dokumentation vermuten lässt. Unsere Messungen zu Cache-Mindestgrößen ergaben effektive Schwellenwerte, die 1.4- bis 2.4-mal über den dokumentierten Mindestwerten lagen. Der Leitfaden zum Prompt-Caching beschreibt die Mechanismen der einzelnen Anbieter im Detail.

Warum lokale Schätzungen nie mit der Rechnung übereinstimmen

Viele Systeme schätzen die Kosten clientseitig mit einer Tokenizer-Library und gleichen sie später mit der Rechnung ab. Die Werte stimmen aus drei Gründen nicht überein:

• Jeder Anbieter verwendet andere Tokenizer. Claude-Text mit einem OpenAI-Tokenizer zu zählen bedeutet, mit dem falschen Maßstab zu messen. Derselbe String wird von jeder Modellfamilie anders tokenisiert.
• Abgerechnet wird mehr als nur die eigene Nachricht. System-Prompts und Tool-Schemas zählen bei jeder Anfrage als Input-Tokens. In lokalen Schätzungen werden sie leicht übersehen.
• Der Reasoning-Verbrauch ist erst nach der Response bekannt. Clientseitig lässt sich nicht vorhersagen, wie viele Thinking-Tokens ein Modell verbrauchen wird. Der Wert steht erst im zurückgegebenen usage-Objekt fest.

Das zurückgegebene usage-Objekt ist der Abrechnungsdatensatz des Upstreams. Die günstigste präzise Zählmethode besteht daher darin, nicht mehr zu schätzen, sondern dieses Objekt auszulesen. Allerdings strukturiert jeder Anbieter die Daten anders: Gecachte Tokens heißen je nach Modellfamilie cached_tokens, prompt_cache_hit_tokens, total_cached_tokens oder cache_read_input_tokens.

Auch die Detailobjekte folgen keinem festen Schema. Die OpenAI-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 enthält dieselbe Struktur neben cached_tokens auch text_tokens, audio_tokens und image_tokens. GPT-5.6 ergänzt cache_write_tokens; in realen Responses ist uns außerdem video_tokens begegnet. Anbieter erweitern das Schema nach Bedarf: Kimi K2.7 gab ein nicht dokumentiertes completion_tokens_details.text_tokens zurück, und Gemini zählt Thinking- und Tool-Use-Tokens separat unter eigenen Feldnamen. Parser müssen daher defensiv implementiert werden: Unbekannte Detailfelder sind normal, und ein fehlendes Feld darf nie automatisch als Null interpretiert werden. Für Audio gelten wiederum eigene Preismodelle. Die Kosten der Spracherkennung haben wir separat pro abgerechneter Audiominute für sieben spezialisierte ASR-Modelle gemessen.

Hier spielt ein Gateway seine Stärke aus: Synthorai normalisiert all diese Varianten in ein einheitliches Objekt. reasoning_tokens und beide Cache-Richtungen werden für OpenAI, Anthropic, Gemini und Open-Weight-Familien einheitlich befüllt. Dadurch reicht ein Parser für alle gerouteten Modelle.

Vom Beobachten zum Begrenzen

Die Kostenaufstellung zu lesen ist nur die halbe Arbeit. Ebenso wichtig ist es, Überschreitungen technisch zu verhindern, statt sie nur sichtbar zu machen. Ein Monats-Dashboard meldet die Überraschung erst, nachdem das Geld ausgegeben wurde. Ein Agent in einer Retry-Schleife schaut nicht auf Dashboards. Im Gateway besitzt jeder Key eine quota mit dem erfassten used_quota sowie einem RPM-Limit, das bei jeder Anfrage durchgesetzt wird. Ist das Budget eines Keys aufgebraucht, liefert bereits die nächste Anfrage einen expliziten Fehler. Die Alternative wäre eine drei Wochen später eintreffende, höhere Rechnung. Auch die Zuordnung pro Anfrage - welcher Key, welches Modell, BYOK oder Plattformabrechnung - steht im selben Response-Envelope. Kosten pro Feature lassen sich deshalb mit einem einfachen Group-by ermitteln und müssen nicht nachträglich rekonstruiert werden.

Aus den Messungen ergibt sich folgende Reihenfolge: Zuerst reasoning_tokens und die Cache-Felder auswerten, bevor andere Optimierungen beginnen. Danach den Reasoning-Regler je nach Aufgabe konfigurieren. Schließlich für jeden Key, dessen Fehlermodus eine Schleife sein kann, ein hartes Budget setzen. Der Kostenoptimierer berechnet anhand derselben Per-Token-Tarife wie oben, was eine konkrete Mischung aus Modellen und Token-Klassen beim eigenen Volumen kostet.

← Zurück zum Blog