Home › Guides › Cost modelling

Reasoning models: why your bill is 2-5x the token count you estimated

With a reasoning model, the tokens you can count are not the tokens you are charged for. This is the most common source of a genuinely shocking first invoice.

Cost modelling · 9 min read · Last reviewed 2026-07-28

Every cost estimate assumes you can count what you will be billed for. With reasoning models that assumption breaks, and it breaks in the expensive direction.

What reasoning models do differently

A conventional model reads your prompt and generates an answer. Every token it produces is returned to you, and if you cap output at 500 tokens you are billed for at most 500 output tokens.

A reasoning model — OpenAI's o-series, and extended-thinking modes in several other families — inserts a phase before answering. It generates internal reasoning: working through the problem, considering approaches, checking itself, sometimes backtracking. Then it produces the visible answer.

This works. On mathematics, competitive programming, scientific reasoning and complex multi-constraint problems, reasoning models substantially outperform conventional models of comparable size. It is a real capability gain, not marketing.

The billing consequence is the problem. Those internal reasoning tokens are billed at the output rate, and at most providers they are not returned in the response — you may get a summary or a count, but not the tokens themselves. So you are charged, at the most expensive rate on the card, for a quantity you cannot inspect and could not have predicted.

How large is the invisible part

It varies enormously, which is precisely what makes it hard to budget.

For a simple question a reasoning model may use a few hundred reasoning tokens. For a genuinely hard problem it may use tens of thousands. The determining factor is how difficult the model finds the problem — which correlates with, but is not the same as, how difficult you think it is.

A reasonable planning assumption is 3× the visible output as a starting point, with the understanding that it can be far higher. Some observations that hold fairly generally:

• Reasoning volume scales with problem difficulty, not prompt length. A one-line hard maths question can generate more reasoning than a long straightforward summarisation task.
• The relationship is non-linear. Problems near the edge of a model's competence generate the most reasoning, because that is where it explores and backtracks most.
• The variance is high. Two similar-looking requests can differ by an order of magnitude in reasoning tokens.
• Ambiguous or underspecified prompts inflate reasoning, as the model works through interpretations. Clarity is a cost saving here.

That last point deserves emphasis: with reasoning models, a vague prompt is directly more expensive than a precise one, in a way that is not true of conventional models.

Why estimates go so wrong

The naive calculation looks fine. Input 1,000 tokens, expected answer 500 tokens, apply the rate card, get a per-request cost. It is arithmetically correct and can be off by 5× or more.

Consider a model priced at $2.00 input / $8.00 output per million tokens, with a 1,000-token prompt and a 500-token answer:

The bottom rows are not hypothetical. Hard problems with high reasoning effort routinely produce tens of thousands of reasoning tokens. An application that budgeted on the first row and encountered the fourth has a thirty-fold cost overrun, and no obvious signal as to why.

Note also that input is a trivial share of every row. With reasoning models the input side of your prompt barely matters to the bill. This inverts the usual advice: optimising prompt length is close to pointless here, and controlling reasoning volume is everything.

Measuring it properly

The API response includes a usage object that reports reasoning tokens separately (commonly as a field within output token details). This is the only authoritative source for what you are paying.

Concretely:

1. Log reasoning tokens on every request, from day one. Not aggregate spend — the per-request breakdown, so you can attribute cost to request types.
2. Look at the distribution, not the mean. Reasoning token counts are heavily right-skewed. The 95th percentile matters far more than the average for capacity and budget planning, and the mean will mislead you.
3. Segment by request type. You will usually find a small category of requests responsible for a disproportionate share of reasoning spend. That is where optimisation effort belongs.
4. Run a real pilot before committing. A few hundred representative requests will tell you your actual multiplier. Any estimate made without this is guesswork.
5. Set budget alerts. Reasoning cost can spike from a change in input distribution rather than a change in your code, so a deploy-time review is not enough.

Controlling the cost

Use reasoning models selectively

The largest saving by far. Most applications contain a small number of steps that genuinely need deep reasoning and a large number that do not. Classification, extraction, formatting, routing and summarisation almost never need it.

Route the hard step to the reasoning model and everything else to a conventional one. This is more effective than any parameter tuning, and the architecture is straightforward.

Use the reasoning effort controls

Providers expose a control over how much reasoning to spend — typically low, medium and high settings. The difference in cost between the extremes is large.

Test whether low effort suffices for your task. It frequently does, and the default is often higher than you need. This is the cheapest optimisation available: one parameter.

Be precise in your prompts

Because ambiguity inflates reasoning, prompt clarity has a direct cost effect. State constraints explicitly. Specify the output format. Remove genuine ambiguity about what is being asked. A model that does not need to reason about what you meant spends fewer tokens reasoning.

Cap output where you can

Setting a maximum on completion tokens does bound total spend, but be careful: if the cap is hit during the reasoning phase, you can be billed for reasoning and receive no usable answer — the worst outcome. Set caps generously enough to allow completion, and treat truncated responses as a monitored failure mode rather than a cost control.

Consider whether prompted reasoning is enough

A conventional model asked to "work through this step by step" also generates reasoning tokens — but visible ones, that you can count, inspect and control. For moderately hard problems this is often competitive on quality and far more predictable on cost.

The trade is real: dedicated reasoning models are meaningfully better on genuinely hard problems. But test the cheaper option before assuming you need the expensive one. Visible reasoning also has a debugging advantage — you can see where it went wrong.

When they are worth it

Reasoning models earn their cost where correctness has high value and errors are expensive: mathematical and scientific work, complex code generation and debugging, multi-constraint planning, analysis where a subtle mistake carries real consequences.

They are poor value for high-volume simple tasks, anything latency-sensitive (reasoning takes wall-clock time as well as money), tasks where a conventional model already succeeds reliably, and creative or open-ended generation where there is no correct answer to reason toward.

Further reading

• Why output tokens cost more — why reasoning tokens are billed at the expensive rate.
• LLM API pricing explained — where reasoning tokens sit among the other line items.
• Context windows — reasoning tokens consume window capacity as well as budget.