Reasoning Tokens: The Invisible Line on Your Bill

A reasoning model writes a private draft before it answers you. You are billed for that draft at the output rate, you usually cannot read it, and on a hard problem it can be several times longer than the answer. It is the only line on an inference invoice that corresponds to text nobody ever sees.

What you are paying for

Mechanically nothing new is happening. The model generates tokens autoregressively as it always did; some of those tokens are marked as thinking and are filtered out of, or separated from, the content returned to you. The commercial consequence is that a single API call now has an output length you did not request and cannot precisely predict.

The two families differ in how much they show you. OpenAI’s reasoning models keep the chain private and return only a count. Anthropic’s extended thinking returns thinking content blocks alongside the answer, and requires you to pass them back verbatim in subsequent turns of a tool-use loop, which means they occupy input budget on the next call too. Google reports a separate thoughtsTokenCount. All three bill the tokens as output.

Where they show up in usage

The single most useful thing to do is log the field. It is nested, it is easy to miss, and its absence from your dashboards is why a bill arrives larger than the model was expected to cost:

# OpenAI-shaped
usage = {
  "prompt_tokens": 1200,
  "completion_tokens": 2350,
  "completion_tokens_details": {"reasoning_tokens": 2100},
}
visible = usage["completion_tokens"] - \
          usage["completion_tokens_details"]["reasoning_tokens"]   # 250

# Anthropic-shaped: thinking blocks are inside output_tokens already
usage = {"input_tokens": 1200, "output_tokens": 2350}

In that example 2,100 of the 2,350 output tokens — 89% — are invisible. At a hypothetical $15.00 per million output tokens the visible 250-token answer costs $0.00375 and the request costs $0.035. Anyone forecasting from the length of the answers they can see will be out by an order of magnitude.

The empty-response failure

This is the failure mode worth memorising because it looks like a bug in your code. Reasoning tokens are spent before the visible answer and they count against the same max_tokens ceiling. Set that ceiling too low and the model exhausts it while thinking:

request:  max_completion_tokens = 500
response: 200 OK
          choices[0].message.content = ""
          choices[0].finish_reason   = "length"
          usage.completion_tokens_details.reasoning_tokens = 500

A successful HTTP status, an empty string, and a full charge. The rule that prevents it: set the ceiling to your expected answer length plus a reasoning allowance, and treat finish_reason == "length" with empty content as a retry-with-larger-budget condition rather than as a model failure. Anthropic’s API makes this structural by requiring max_tokens to exceed thinking.budget_tokens, which is a better default than letting the two collide silently.

When the tokens earn their cost

Reasoning is not a general quality upgrade. It is compute spent on search, and it helps in proportion to how much search the task contains.

The evaluation to run is not “is the reasoning model better” but “is it better per cent”. Hold the budget fixed, spend it either way, and compare.

There is a latency dimension too, and it is more visible to users than the cost is. Thinking happens before the first visible token, so a reasoning model can sit silent for many seconds while producing nothing you can stream. Time to first token, the number that dominates perceived responsiveness, is no longer a function of prompt length — it is a function of how hard the model decided the problem was, which you cannot predict per request. For an interactive surface that usually means either showing a distinct thinking state or routing interactive traffic to a non-reasoning model and reserving reasoning for background work.

Finally, note what happens across turns. In a multi-turn conversation you generally do not resend previous reasoning — so you pay for it once and lose it, and the model re-derives whatever it needs next turn. The exception is tool use in the extended-thinking style, where the thinking blocks from the turn that issued a tool call must be returned alongside the tool result, which means they occupy input budget on the following request. Budget for that explicitly in an agent loop; it is the difference between a cost model that holds and one that drifts upward with every turn.

Controlling the spend

• Use the effort control. Providers expose a coarse dial — an effort level, or an explicit thinking token budget. It is the highest-leverage knob and most integrations leave it at default.
• Do not ask for reasoning in the prompt as well. “Think step by step” on a model that already thinks adds visible chain-of-thought to a hidden one, and you pay for both.
• Route by difficulty. Classify cheaply, then escalate the hard fraction. Most production traffic is easy and a uniform model choice overpays for it.
• Expect poor cacheability. Reasoning output is generated fresh per request; it is not a prefix and it is not reused. Caching helps the input side only.
• Alert on the ratio. Reasoning tokens divided by visible tokens is a single number that will tell you about a prompt regression days before the invoice does.