Reasoning models, sometimes called thinking models, generate an internal chain of thought before producing the visible answer. Those intermediate tokens often improve results on hard problems such as maths, complex code and multi-step planning. They are also billed, usually at the output-token rate, and they can be many times longer than the answer itself.
The result is a new kind of cost surprise: two requests with identical prompts and similar-length answers can differ in price by an order of magnitude because one triggered a long internal reasoning process. This guide explains how reasoning tokens are billed, why they make spend unpredictable, and how to run a cost audit that shows where reasoning pays for itself.
How reasoning tokens are billed
Details vary by provider, so always check current documentation, but the common pattern is:
- Reasoning tokens count as output tokens for billing, and output tokens are typically priced several times higher than input tokens.
- They may be hidden or summarised. Some APIs return the full reasoning, some return a summary, and some return nothing but a token count in the usage data.
- They count towards output limits. If the maximum output setting is too low, a model can use the whole budget thinking and return a truncated or empty answer.
- Many APIs offer a control: a reasoning effort level or a thinking-token budget that caps how much the model can think.
cost = input_tokens × input_price
+ (reasoning_tokens + visible_output_tokens) × output_price
Illustrative example (prices per million tokens: $3 input, $15 output):
1,500 input + 300 visible output, no reasoning → $0.0090
1,500 input + 300 visible output + 4,000 reasoning → $0.0690 (≈7.7× more)The numbers above are illustrative; plug in your own provider's prices. The structure is what matters: reasoning tokens are usually the largest and least predictable part of the bill.
Why reasoning spend is hard to predict
Reasoning length depends on how hard the model *judges* the problem to be, not on prompt length. In practice you will often see:
- a long tail of requests that use many times the median number of reasoning tokens;
- higher reasoning use on ambiguous or underspecified prompts, as the model explores interpretations;
- reasoning on tasks that do not need it, such as classification or simple rewriting, when a reasoning model is used for everything.
Averages hide this. A monthly invoice can be dominated by a small share of requests.
The reasoning cost audit, step by step
1. Log usage per request
Record input, reasoning and visible output tokens for every request, along with a task label (which feature, which endpoint, which prompt template) and latency. Most APIs return a usage object; store it with your request logs.
2. Break down spend by task type
Group by task label and compute total cost, cost per request at p50 and p95, and the share of cost that is reasoning. You will usually find that a few task types account for most reasoning spend.
3. Test quality with less or no reasoning
For each expensive task type, run your eval set at lower reasoning effort, with a non-reasoning model, and with a small model. Our guide does "think step by step" help on short tasks? shows that many short, well-specified tasks gain little from extended reasoning.
| Task type | Share of spend | Quality with low effort | Action |
|---|---|---|---|
| Ticket classification | 22% | Same as high effort | Switch to low effort or small model |
| Field extraction | 18% | Same | Use a non-reasoning model |
| Multi-step planning | 35% | Noticeably worse | Keep high effort |
| Code fixes | 25% | Slightly worse | Medium effort, retry with high on failure |
4. Set budgets and escalation rules
Rather than one setting for everything, use a policy:
- default to low effort or a non-reasoning model for routine tasks;
- escalate to higher effort only for task types where the eval shows a real gain;
- retry with more reasoning only when a cheap first attempt fails a validation check.
This is a form of routing, and it is usually the biggest single saving available; see where small models quietly win.
5. Watch latency too
Reasoning tokens are generated before the visible answer, so they add directly to the time a user waits. A request that thinks for 4,000 tokens at 60 tokens per second adds over a minute before the answer starts. Use streaming of status or summaries to keep users informed, and measure time to first visible token separately; our latency benchmark guide covers how.
Building a cost dashboard that stays useful
An audit is a snapshot; a dashboard keeps the savings. Keep it small enough that someone actually looks at it every week:
- Cost per completed task, by task type, not cost per request. Retries and escalations belong to the task they serve.
- Reasoning share of spend, so you notice when a prompt or model change makes the model think more.
- p95 reasoning tokens per task type. The tail moves before the average does.
- Escalation rate: how often routine tasks fall back to a higher reasoning level. A rising rate means the cheap path is failing more often.
- Quality signals next to cost: pass rate on a weekly sample, user corrections or support tickets. Cost cuts that silently lower quality are not savings.
Set an alert on daily spend per feature as well as total spend. A single misbehaving feature can double a bill while the total still looks normal for a few days.
Prompting habits that reduce reasoning waste
- Be specific. Ambiguous prompts trigger exploration. State the format, constraints and what to do when information is missing.
- Do not ask for reasoning the model already does. "Think step by step" on top of a reasoning model can lengthen output without improving quality.
- Provide the key facts. Reasoning is often spent reconstructing information you could have included.
- Set output limits with headroom so answers are not truncated after long thinking.
Turning the audit into a decision
Reasoning is worth paying for when it changes outcomes that matter. The decision framework is the same one in choosing a model is a budget decision: price the completed task, including retries and human fixes, at the quality bar the task needs. For hard problems, a more expensive reasoning call that is right the first time can be the cheapest option. For routine work, it is usually waste.
Re-run the audit monthly or after any model change. Providers adjust reasoning behaviour between versions, and a model update can change your cost profile overnight.
Frequently asked questions
Are reasoning tokens charged?
With most providers, yes. Reasoning or thinking tokens are typically billed as output tokens, even when the reasoning text is hidden or summarised. Check your provider's documentation and the usage data returned with each response.
How can I reduce the cost of reasoning models?
Use reasoning only for task types where your evals show a quality gain, set a reasoning effort level or token budget, route routine tasks to cheaper models, and write specific prompts that reduce unnecessary exploration.
Why did my reasoning model return an empty answer?
Usually because the output token limit was reached during reasoning, leaving no room for the visible answer. Increase the maximum output setting or lower the reasoning budget.
Do reasoning tokens make responses slower?
Yes. Reasoning is generated before the visible answer, so longer reasoning means a longer wait before the first visible token. Measure this separately from total response time.
