The tokens you cannot see are the ones you pay for

A model was asked for one word. It replied with one word. The response envelope reported candidatesTokenCount: 1, and any tool reading that field would have recorded a single output token against the call. Google billed sixty-eight.

The missing sixty-seven were reasoning tokens: text the model generated to work out its answer, discarded before the answer was returned, and charged at the full output rate. They are reported, but in a different field, and they never appear in the answer you receive.

The captured envelope

This is the response that exposed it, reproduced as it arrived through our connector. Read the four numbers together: seven in, one answer token out, sixty-seven thought tokens, and a total the first three do not obviously explain until you add the thoughts to the output.

• promptTokenCountWhat you sent. Billed at the input rate, and reported by everyone.
• candidatesTokenCountThe answer you received. This is the field most cost tooling reads, and on a thinking model it is a fraction of what you are charged for.
• thoughtsTokenCountReasoning the model generated and then discarded. Billed at the output rate, never shown to you, and absent from the answer entirely.
• totalTokenCountPrompt plus answer plus thoughts. 7 + 1 + 67 = 75, which is the only place the discrepancy is visible without knowing the field exists.

What it costs when you read the wrong field

Gemini 3.6 Flash lists at $0.75 per million input tokens and $3.75 per million output tokens on Google's own endpoint, as tracked in our live catalog. Priced against that, the call above costs $0.00026. Priced from candidatesTokenCount alone it costs $0.000009 — twenty-nine times less. On output alone the under-count is sixty-eight to one.

Ratios that extreme come from a one-word answer, and a long answer dilutes them. The direction never reverses. Reasoning tokens are additive: they can only make a call cost more than the answer suggests, never less, and the shorter and harder the question, the wider the gap.

Why this is a measurement problem, not a Google problem

Google reports the number honestly. The failure is downstream: a field that did not exist before reasoning models arrived is now the majority of billed output on those models, and anything written against the older envelope silently under-counts rather than erroring. A wrong number that looks like a right number survives review indefinitely.

The same shape appears elsewhere under different names. OpenAI reports reasoning tokens inside completion_tokens_details; other vendors use reasoning_tokens. Our parser now treats every one of them as billed output, including in the fallback path for envelopes it does not recognise, so an unfamiliar provider under-counts nothing while we work out what it is.

This is the difference between tracking prices and measuring spend. A price tracker tells you the published rate per million tokens, and it was correct here: $3.75 is $3.75. It cannot tell you that the call you just made bought sixty-eight of those tokens and showed you one.

What to do with this

Check what your own cost reporting reads. If it sums a field named for the answer rather than for the billing, every thinking model in your stack is under-counted, and the error grows precisely as you adopt more reasoning. Then reconcile a month against the provider invoice: a metering path that has never been reconciled against a bill is an estimate wearing the clothes of a measurement.

There is a second consequence, taken up in a later note rather than here: if the billed number lives in a field the answer does not touch, then an unchanged request is free to get more expensive without anything visible changing. That is the argument in "An audit is a photograph of a market that keeps moving", which uses the envelope above as its starting point.