LLM Token Usage: Why a 4-Token Answer Bills 217 Tokens

Ask GPT-5.6 a one-line math question and 88% of the output charge is reasoning you will never see: 10 visible tokens, 81 billed. And GPT-5.6 is the mild case. The same question billed 217 completion tokens for a 4-token answer on GLM 5.2, and 1,104 for the identical answer on Qwen3.7-max. That is not an anomaly; it is how reasoning models bill by design, and it is the first of several token classes that most cost dashboards never break out. This post dissects a real usage object, class by class, with the measured numbers.

TL;DR

• GPT-5.6’s default billed 81 tokens for a 10-token answer, 88% reasoning; GLM 5.2 ran 98% and Qwen3.7-max 99.3%.
• Claude Sonnet 5 billed 114 thinking tokens on a 5-token answer with no thinking parameter sent.
• Five families answered wrong without thinking (399, 400, 427, 466, 467); GPT-5.6 alone was correct without it, and every reasoning run said 401.
• A 1,181-token Claude cache write then read cost $0.01246 and $0.00566, matching list prices exactly.

What we tested with

Every measurement in this post is the same single-turn prompt, sent to each model at its default settings unless a row says otherwise:

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

The correct answer is 401 (333 multiples of 3, plus 200 multiples of 5, minus 66 counted twice, gives 467; drop the 66 multiples of 15 and 401 remain). We chose it deliberately: the visible answer is tiny and fixed at 3-4 tokens on every tokenizer, there is exactly one right answer so “did the thinking pay off” is checkable, and it is just hard enough that models want to think, which is the behavior being audited.

The five token classes on your bill

A modern completion bills up to five different token classes, at four different rates. A single flat “tokens used” number hides all of it.

The field names above are the OpenAI-compatible shape. Claude carries the same five classes under its own names: input_tokens and output_tokens, with thinking reported in output_tokens_details.thinking_tokens and billed as output, and the cache write further split by TTL in a cache_creation object (ephemeral_5m_input_tokens at 1.25x, ephemeral_1h_input_tokens at 2x). Same anatomy, different labels: that parsing problem returns in a later section.

The five classes and their price multipliers, labeled with the OpenAI-compatible and Anthropic field names. The 88% figure is GPT-5.6’s measured reasoning share from the example above.

Here is the real object behind the headline, GPT-5.6 on its default setting answering the test question:

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

This is where the billing arithmetic lives, and it is worth doing once explicitly. The answer you received is completion_tokens minus reasoning_tokens: 81 − 71 = 10 tokens, the word “401” and its formatting. The other 71 tokens are chain-of-thought billed at the full output rate, 88% of the output charge, and on GPT-5.6 you cannot read a single one of them. Every “visible answer” figure in this post is computed the same way. The ratio only gets steeper elsewhere: GLM 5.2 answered the same question with 217 completion tokens for a 4-token answer, so a cost model that reads completion_tokens as “what the model said” is off by 8x here and 54x there.

Reasoning is the budget, and it is steerable

The same one-line question across every thinking setting the three steerable families accept, one gateway, 2026-07-13/14 (rows ordered least to most reasoning within each family; the remaining families’ flagship defaults are in the next section):

Four things worth reading out of that table honestly:

• The lever is large where it works. reasoning_effort: none answered correctly for $0.000062, 8.5x under luna’s default, and on harder tasks we’ve measured 20x on GLM 5.2. Tier choice is part of the same lever: GPT-5.6’s flagship answered this question with zero reasoning by default (next section), so a bigger model that doesn’t need to think can out-cheap a smaller one that does.
• And nearly inert where it doesn’t. How far the dial turns is a family trait: monotonic with a 5x cost swing on Sonnet 5 (84 to 249), mild and unordered on GPT-5.6, nearly inert on Qwen3.7-max (low still spent 974 reasoning tokens against the default’s 1,096), dead on DeepSeek V4 Pro (267 against 269).
• Labels are not monotonic and defaults are not deterministic. GPT-5.6’s high spent fewer tokens than its medium here; GLM’s low out-spent its high in our earlier post; Sonnet 5 thought for 114 tokens on a request that sent no thinking parameter at all; and the same GLM default request spent 213 reasoning tokens in one run and 1,312 in another, six times apart. Measure the dial’s real effect on your workload; don’t read it off the label.
• Cheap-and-wrong is the recurring failure. Both families that answered without thinking here answered wrong (GLM 399, Sonnet 5 467); the full five-family roll call is in the next section. Reasoning is a correctness budget, and whether cutting it pays off belongs to the task, not the model.

The practical rule: treat reasoning_tokens as a first-class line item. It bills at the output rate, it routinely dwarfs the visible answer, and it responds to parameters whose real effect you must measure. On GPT-5.6, note that the pricing rules changed too; the GPT-5.6 cost guide covers the write premium and the cache-key requirement.

Can you actually read what you paid for?

“Separate from the answer” does not always mean hidden, and the difference is worth being precise about. We checked the response bodies, not just the usage:

• GLM 5.2, DeepSeek, Qwen3.7-max, and MiniMax return the full reasoning text in a reasoning_content field beside the answer (3,987, 1,604, 2,509, and 581 characters here). A developer can read every billed token; end users only see it if you render it, and most applications don’t.
• GPT-5.6 withholds the raw chain of thought; a summary is the most you get. The response can carry a model-written reasoning.summary (359 characters here), but the 91 billed tokens are the hidden raw text, not the summary. The closest thing to that text is reasoning.encrypted_content: an encrypted blob you can hand back for multi-turn continuity but never decrypt. The tokens you paid for sit in your own response body, unreadable.
• Claude depends on how you ask. Our adaptive-thinking Sonnet 5 call returned a thinking block whose text was empty while thinking_tokens billed 114: proof it thought, nothing to read. Fable 5 behaved the same way on its always-on default (59 billed, empty block). Yet the same Sonnet 5 called with an explicit reasoning budget returned the actual thinking text (73 tokens billed, text present). How you ask decides what you can see.

So the billing statement is universal, the visibility is not: every family charges output rate for reasoning, and whether you can audit the text you bought ranges from “in full” through “summary only” to “a signed empty block.”

When the text does come back, you can grade it mechanically. Our question has five fixed intermediate results (333, 200, 66, 467, 401), and every returned reasoning text contained all of them: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code, and MiniMax M3 each shipped a complete derivation, while the low-effort variants dropped one step each. For anyone who needs the process and not just the answer, that is the split: with reasoning_content you can verify what you paid for; with a summary or an empty block you take it on faith. Invisible Tokens, Visible Bills formalizes that accountability gap, and PALACE estimates hidden reasoning from the outside.

The same question across every family’s best model

The steering table used specific tiers to show the knobs. Here is the newest flagship of each family on the same question, default settings:

Billed output tokens per flagship for the same question (hatched orange = reasoning share; green = the visible answer). The asterisk on MiniMax: its usage carries no reasoning count, so the share is reconstructed by subtraction, verified against the reasoning text it returns. The check mark on GPT-5.6 sol marks the only correct zero-reasoning run; the cross on Gemini 3.5 Flash marks the only wrong flagship answer (466).

Every reporting style in one chart:

• Seven of eight flagships answered correctly, at wildly different prices for the same 401. Qwen3.7-max spent 1,096 reasoning tokens, 22 seconds, and $0.0084; GPT-5.6’s flagship spent zero reasoning tokens and $0.00031. A 27x cost spread and a 7x latency spread for an identical right answer is the reasoning budget made visible.
• MiniMax returns its reasoning text but no count. 260 completion tokens for a 3-token visible answer: the response carries the full derivation in reasoning_content, yet completion_tokens_details has no reasoning line. When the count is missing, reconstruct it by subtraction: completion minus visible tokens is your hidden-output count.
• Gemini 3.5 Flash is the outlier: the only flagship to answer wrong (466), with 3 completion tokens and no reasoning count anywhere. Its sibling 2.5 Flash once spent 12.5 seconds producing a 3-token 401 with nothing in the bill saying why, and a repeat run answered 427.
• Smaller tiers and disabled thinking are where the wrong answers live. GLM with thinking off said 399; Sonnet 5 disabled said 467; the older qwen3-max didn’t think at all (3 tokens) and said 400; Kimi K2.5, which has no reasoning channel, reasoned out loud for 144 visible billed tokens, derived 401 inside its own prose, then concluded 400. Five families, five different wrong answers: 399, 400, 427, 466, 467; GPT-5.6 alone was correct without reasoning.

Cache tokens: two directions, 12x apart

Prompt caching splits input into two more classes, and the price gap between them is the reason the split exists: writes bill at 1.25x the input rate on Claude (2x for the 1-hour TTL), reads at 0.1x. A measured pair of Opus 4.8 calls with a 1,181-token cached system prompt cost $0.01246 (write) then $0.00566 (read), both reconciling against list prices to the sixth decimal, with the input-side charge dropping about 11x call-over-call. The point for this post is the accounting: if you lump cache_creation_input_tokens and cache_read_input_tokens into “input tokens”, you can neither verify the discount nor notice when it silently stops happening. And it stops more often than the docs suggest: our caching measurements found effective thresholds 1.4 to 2.4x above the documented minimums, and the prompt caching guide covers the per-provider mechanics in depth.

Why your local estimate never matches the bill

A common pattern is estimating cost client-side with a tokenizer library and reconciling later. Three reasons the numbers won’t match:

• Tokenizers differ per vendor. Counting Claude-bound text with an OpenAI tokenizer is measuring with the wrong ruler; the same string tokenizes differently on every family.
• You bill for more than your message. System prompts and tool schemas are input tokens on every request that carries them, and they’re easy to leave out of a local estimate.
• Reasoning is unpredictable until the response. No client-side count can predict how many thinking tokens a model will spend; you only learn it from the returned usage.

The returned usage object is the upstream’s own billing record, so the cheapest accurate counter is to stop estimating and read it. The catch is that every provider shapes it differently: cached tokens alone appear as cached_tokens, prompt_cache_hit_tokens, total_cached_tokens, or cache_read_input_tokens depending on the family.

The detail objects are not a fixed schema either. OpenAI’s reference documents four completion-side fields: reasoning_tokens, audio_tokens, and the Predicted Outputs pair accepted_prediction_tokens / rejected_prediction_tokens; rejected prediction tokens never appear in the output yet still bill as completion tokens. On the prompt side, the same shape adds text_tokens, audio_tokens, and image_tokens beside cached_tokens; GPT-5.6 adds cache_write_tokens, and we have seen video_tokens in the wild. Vendors extend it freely: Kimi K2.7 returned an undocumented completion_tokens_details.text_tokens, and Gemini counts thinking and tool-use tokens separately under its own names. Parse defensively: treat unknown detail fields as expected, and never assume a missing field means zero.

This is where a gateway earns its place: Synthorai normalizes all of these into one object, with reasoning_tokens and the two cache directions populated across OpenAI, Anthropic, Gemini, and the open-weight families, so one parser covers every model you route to.

From seeing to stopping

Reading the ledger is half the job; the other half is making overruns impossible rather than merely visible. Month-end dashboards report a surprise after the money is gone, and an agent stuck in a retry loop does not read dashboards. On the gateway, every key carries a quota with tracked used_quota and an RPM ceiling, enforced at request time: a key that exhausts its budget gets an explicit error on the next request, not a bigger invoice three weeks later. Per-request attribution (which key, which model, BYOK or platform billing) comes back in the same response envelope, so cost-per-feature is a group-by, not a reconstruction project.

The order of operations that follows from the measurements: read reasoning_tokens and the cache fields before optimizing anything, set the reasoning dial per task, and put a hard quota on every key whose failure mode is a loop. To see what a specific mix of models and token classes costs at your volume, the cost optimizer prices it from the same per-token rates used above.

← Back to blog