Why reasoning models cost more than you expected: how thinking tokens are billed

The mechanism, plainly

A reasoning model generates two kinds of output. The first is the chain of reasoning it works through before answering. The second is the answer itself.

You see the second. You are billed for both.

This is not a billing trick; generating the reasoning is the entire point of the model. But it means any cost estimate built by counting the characters in the answer will be wrong, and wrong in the direction that surprises people.

How much reasoning tokens actually cost you

It depends almost entirely on the task, which is what makes this hard to budget for.

The pattern: the harder the problem, the more of your bill is invisible. A workload of simple questions shows almost no difference between a reasoning model and a standard one. A workload of genuinely hard problems can be dominated by tokens you never see.

Where you actually find the number

This is the practical part, and it is the reason this article exists.

The API response's usage block typically includes a separate field for reasoning tokens alongside the visible output count. Most people read output_tokens, compare it to their estimate, and conclude they are being overcharged.

They are not. They are reading the wrong field.

What to do: log the full usage object on every call, not just the field you use for display. Break it down by endpoint, model and task type. Within a week you will have the real ratio for your workload, and it will be stable enough to budget against.

Why a relay service makes this harder

Two additional effects:

Reasoning tokens may be billed at a multiplier. Some vendors charge reasoning output at the same rate as visible output; some do not. A relay service that applies its own rate structure may apply it differently to the two categories. Read the billing detail rather than assuming.

Relay-side accounting can hide the split. If a service bills you a single blended number, you lose the ability to tell how much was reasoning — which means you also lose the main lever for controlling it.

The practical implication: if your workload uses reasoning models heavily, prefer a service that reports the token breakdown faithfully. It is not a marketing feature; it is the thing that lets you control cost.

How to control the cost

Match the model to the task. Reasoning models are worth it when the problem actually needs the reasoning. For retrieval, formatting, classification and simple extraction, a standard model is usually a fraction of the cost and just as good.

Turn the reasoning effort down where it is offered. Several vendors expose a control for how much reasoning to apply. Defaulting to the highest setting across every request is an easy way to spend several times what you need to.

Measure before you optimise. You cannot tune what you do not observe. Getting the token breakdown logged is the whole task; the decisions follow from it.

Watch for reasoning on retries. If a call fails and is retried, the reasoning tokens from the failed attempt were still generated and are still billed. High failure rates multiply this effect.

A rough budgeting approach

Without exact figures for your workload, a workable starting point:

1. Take a sample of 50–100 real tasks
2. Log the full usage split for each
3. Compute the average reasoning-to-visible ratio
4. Budget on that ratio, and add a margin, because long-tail complex tasks pull it up

Then re-measure monthly. The ratio drifts as you change prompts and as vendors change defaults.

What this does not mean

It does not mean reasoning models are bad value. For the tasks that need them, there is no substitute and the extra tokens are the price of the capability.

It means the cost model is different from a standard model, and that comparison shopping on headline rates alone will systematically favour the cheaper-looking option in a way that does not survive contact with a real workload.

Related reading

• From list price to your invoice: a worked cost conversion (guides)
• 2026 model API pricing review: who actually got cheaper (guides)
• A relay service starts erroring or slowing down: how to tell whose problem it is (guides)