You deployed a reasoning model, ran it for a week, and got a billing email that was twice what you expected. You didn’t change the model. You didn’t change the prompt. You didn’t add more users. The only thing that changed is that the model started thinking harder and that thinking costs money you can’t see in your logs.

This is not an edge case. It is the default experience of moving from a standard language model to a reasoning model without adjusting your cost assumptions, your monitoring, or your token budgets. This article explains where the hidden cost actually comes from, why it varies so much between runs, and what to do about it.

What a reasoning model is actually doing

When you send a prompt to a reasoning model like Claude Opus 4.8 with adaptive thinking enabled, o3, DeepSeek V4 Pro in think mode, Gemini 2.5 Pro, the model does not immediately produce an answer. It first generates a chain of internal reasoning: it works through the problem step by step in a private scratchpad before committing to a final response. That scratchpad content is what people mean by “thinking tokens.”

The thinking tokens are billed as output tokens. Output tokens are the expensive kind across most providers, output costs four to eight times more than input per token. Whatever the rate, thinking tokens consume it at exactly the same rate as the words you actually see in the response.

The thinking tokens are mostly invisible. Depending on the provider, you either do not see them at all, see a compressed summary, or, in the case of DeepSeek, see the raw chain of thought returned alongside the final answer. But invisible does not mean unbilled. Your application shows the user a clean four-sentence answer; behind it, the model burned through 15,000 tokens of reasoning that appear as output tokens in your usage statement.

How each provider handles it

Provider / model	Thinking tokens billed?	Visible to caller?	Can be disabled?	Control mechanism
Anthropic Opus 4.8 / Sonnet 4.6 (adaptive)	Yes — at output rate ($25/M for Opus 4.8)	Summary only; full chain-of-thought hidden	Yes — omit thinking parameter	thinking: {type: “adaptive”} or omit
OpenAI o-series (o3, o3-pro)	Yes — at output rate	Reasoning summary only (summary: auto)	No — use GPT-5.x instead	reasoning.effort: low / medium / high
DeepSeek V4 Pro (Think mode)	Yes — at output rate ($0.87/M)	Yes — reasoning_content returned in full	Yes — V4 Pro has explicit non-think mode	Model param: think vs. non-think variant
DeepSeek V4 Flash (Think mode)	Yes — at output rate ($0.28/M)	Yes — reasoning_content returned in full	Yes — use deepseek-chat (V3.2) instead	Model selection at call time
Google Gemini 2.5 Pro / Flash	Yes — included in output pricing	thoughts_token_count returned separately	Yes — thinking_budget: 0	thinkingConfig.thinkingBudget
Kimi K3	Yes — always-on, no non-think mode	Not exposed separately	No	None — always maximum reasoning

Billing mechanics as of August 2026. Check provider documentation for current API parameters — these have changed frequently across 2025–2026.

A few things in this table deserve elaboration.

The “visible to caller” column matters more than it looks. When Anthropic returns a thinking summary rather than the raw chain of thought, you are being billed for tokens you cannot inspect. Claude 4.8 and newer models return a condensed version of the thinking block but not the full internal reasoning. The full thinking content is billed regardless. This means you cannot audit what you paid for by reading the API response. DeepSeek is the exception: it returns reasoning_content in full alongside content, so you can measure thinking token length directly and know exactly what drove the bill.

Kimi K3 has no off switch. Every K3 request runs at maximum reasoning effort. There is no non-thinking mode, no effort level to reduce, no parameter to turn off the chain of thought. The Artificial Analysis cost-per-task figure of $0.95 for K3 (versus $1.80 for Opus 4.8) reflects K3’s lower per-token rate compensating for its verbose reasoning. But the verbosity is structural and you cannot opt out of it.

OpenAI’s o-series cannot be made non-reasoning. There is no effort: none setting. If you want a non-reasoning OpenAI model, you pick a different model — GPT-5.x instead of o3. This matters for agentic pipelines where task complexity varies: you cannot route easy subtasks to a lighter version of the same model the way you can with Claude’s adaptive thinking or Gemini’s zero-budget option.

The variance problem

The number that most teams are not prepared for is not the average thinking token count — it is the range.

A Stanford, UC Berkeley, CMU, and Microsoft Research study published in March 2026 tested 8 frontier reasoning models across 11,872 queries. One finding: running the exact same prompt against the same model multiple times produced thinking token variance of up to 9.7x. Same prompt. Same model. Same parameters. The model might spend 1,000 thinking tokens on one run and 9,700 on the next, at identical output cost per token.

That variance is not random noise but it reflects the stochastic nature of how reasoning models explore a problem. A model that takes a more efficient path to the correct answer on one run might pursue a longer chain of verification or alternative approaches on the next. The final answer quality may be nearly identical; the token spend is not.

The practical consequence is that per-token pricing becomes almost meaningless as a cost planning tool for reasoning models if you are calculating it against expected output length. A pipeline that generates 300 visible output tokens per call might generate between 1,500 and 15,000 total billed output tokens depending on how the model decides to think on any given run. The same study found that in 21.8% of model-pair comparisons, the cheaper (lower per-token cost) model ended up more expensive in practice because it generated more thinking tokens per task.

The range the research established: typical thinking token usage runs from a few hundred tokens for simple classification tasks to tens of thousands for complex multi-step reasoning. On the most demanding agentic tasks, a single call can consume 50,000+ thinking tokens before producing a final answer. At output rates, that is $1.25 on Opus 4.8 for the thinking alone, before you count the visible response.

What this looks like in practice

A worked example makes the cost structure concrete.

Scenario	Visible output tokens	Thinking tokens	Billed output tokens	Cost on Opus 4.8 ($25/M)
Simple classification task	50	~200–800	~250–850	$0.006–$0.021
Multi-step coding problem	400	~3,000–15,000	~3,400–15,400	$0.085–$0.385
Complex agentic task (tool calls)	800	~10,000–50,000	~10,800–50,800	$0.27–$1.27
Same agentic task, non-reasoning model	800	0	800	$0.02

The last row is the one teams miss when switching to reasoning models. The agentic task that costs $0.02 on a non-reasoning model at 800 visible output tokens can cost anywhere from $0.27 to $1.27 on Opus 4.8 depending on how much the model decides to think. At 100,000 calls per day, that gap is the difference between a $2,000 daily bill and a $127,000 daily bill and you would not see it coming from visible output token counts alone.

Agentic workflows compound this further. In a multi-step agent, thinking tokens accumulate across every LLM call in the loop. A pipeline that makes 10 model calls per user task generates thinking token overhead 10 times and each intermediate call might trigger a long reasoning chain depending on what tool results or error states the model encounters. Research on agentic token usage found 5x to 30x more total token consumption per task compared to single-turn interactions, with thinking tokens responsible for a substantial share of that multiplier.

Why your monitoring probably missed it

Most standard API observability setups measure response length as the primary cost proxy. Response length means visible output tokens, i.e. the characters the user sees. Thinking tokens are not in the response body unless you are on DeepSeek. They are in the usage block.

The usage block is where providers report thinking tokens, under different field names:

usage.cache_creation_input_tokens / usage.cache_read_input_tokens / (thinking) — Anthropic

usage.completion_tokens_details.reasoning_tokens — OpenAI

usageMetadata.thoughtsTokenCount — Google Gemini

usage.completion_tokens_details.reasoning_tokens — DeepSeek (V4 Pro think mode)

If your logging pipeline samples response.content length and uses it as a cost proxy, you are measuring the visible answer and ignoring everything above it. A dashboard that shows “response length: 300 tokens” for every call while thinking tokens vary from 500 to 25,000 between those calls will give you perfectly stable response-length metrics and wildly unstable billing with no signal connecting one to the other.

The fix is straightforward once you know to apply it: log the thinking token count from the usage block on every call, track it per endpoint and per model separately from visible output tokens, and set up an alert threshold if average thinking tokens exceed a percentage of your max token cap. That threshold tells you when a reasoning model is consuming more of its budget on thinking than you intended which is usually the earliest detectable signal that a cost spike is coming before the billing cycle closes.

The max_tokens trap

There is a second hidden cost mechanic that interacts badly with thinking tokens: the max_tokens parameter.

On standard models, max_tokens caps the length of the visible response. On reasoning models, it caps the combined total of thinking tokens plus visible response tokens. If your thinking tokens consume most of the budget, the model runs out of room before producing a useful final answer and you get a truncated or degraded response, but you still pay for all the thinking tokens that led nowhere.

The concrete failure mode: a pipeline built on a non-reasoning model set max_tokens: 500 because responses were short. A reasoning model was swapped in. The model generated 450 thinking tokens and then had only 50 tokens left for the actual answer. Every response was truncated. The team saw quality degradation, not a cost spike but the cost was also higher, because 450 thinking tokens at output rate is more expensive than the 0 they budgeted.

The rule of thumb from provider documentation and practitioner experience: for tasks where you enable reasoning, set max_tokens to at least 2x to 5x your expected visible output length. For simple tasks with short expected answers: 1,500 to 2,000. For paragraph-length responses: 4,000. For long-form analysis: 8,000 to 16,000. Monitor reasoning token counts from the usage block and adjust the ceiling if average thinking tokens are consistently consuming more than 30% of the cap.

What you can actually control

The mechanisms for controlling thinking token spend differ by provider, but the general levers exist across the ecosystem.

• Effort levels (Anthropic, OpenAI, Gemini). Claude Opus 4.8 exposes effort as a parameter with levels low, high, xhigh, and max. Lower effort means the model uses fewer thinking tokens before producing a final answer, at the cost of less thorough reasoning. For tasks where speed matters more than depth, setting effort to low on a per-call basis can cut thinking token spend by a factor of 3 to 5 compared to max, with modest accuracy tradeoffs on tasks that do not require exhaustive reasoning. OpenAI’s reasoning.effort works similarly for o3. Gemini’s thinkingBudget lets you set an explicit token ceiling, including zero to disable thinking entirely.
• Adaptive thinking (Anthropic). On Opus 4.8 and Sonnet 4.6, setting thinking: {type: “adaptive”} rather than a fixed budget lets the model decide whether to think at all on a given request. For simple classification or lookup tasks, the model frequently skips the reasoning chain entirely. For complex multi-step problems, it engages it. The net effect on a mixed-complexity workload is meaningfully lower average thinking token spend than setting a fixed budget sized for the hardest task.
• Model routing by task complexity. The most effective thinking token control is not a parameter but model selection. A simple retrieval or classification task routed to DeepSeek V4 Pro in non-think mode, or to a non-reasoning model like DeepSeek V3.2 or GPT-5.x, costs a fraction of the same task on a reasoning model with thinking enabled. The question is not “should I use a reasoning model” but “which calls in this pipeline actually need reasoning?” Tool calls that assemble context, format outputs, validate structure, or route decisions typically do not. Calls that need to synthesise conflicting information, plan multi-step strategies, or solve genuine open-ended problems often do.
• Prompt-level budget instructions. Research published in late 2024 and validated in 2025 practice (the TALE-EP approach) found that including an explicit token budget instruction in the prompt, i.e. telling the model how much thinking is appropriate for the task, reduces output token counts by an average of 67% with less than a 3% accuracy drop across seven datasets. The instruction is simple: something like “think as concisely as the problem requires; this is a straightforward classification task” or “limit your reasoning to what is strictly necessary to produce a correct answer.” The model will not always comply perfectly, but it consistently produces shorter reasoning chains than a blank-canvas prompt on the same task.
• Track, then tune. None of the above can be calibrated without measurement. Log reasoning_tokens or equivalent from the usage block on every call. Separate it from visible output token counts. Identify which endpoints in your pipeline are spending the most on thinking, and whether that thinking is correlated with quality improvements on those specific tasks. Most teams that have done this audit find that 20% to 30% of their reasoning model calls are on tasks where thinking adds no measurable quality benefit — and those calls are candidates for a non-reasoning model at the same or lower cost.

The case where reasoning tokens are worth every one

None of this is an argument against reasoning models. On tasks that genuinely require multi-step reasoning like competition-grade mathematics, complex code generation, or long-horizon planning, reasoning models produce materially better outputs than standard models, and the thinking tokens are doing real work. DeepSeek’s 93.5% on LiveCodeBench and Opus 4.8’s 96.7% on USAMO 2026 are not achieved without the reasoning chain; the thinking tokens are what closes the gap.

The problem is not reasoning tokens on hard tasks. The problem is reasoning tokens on easy tasks that happen to be routed through a reasoning model because it was the last model you deployed, or because a framework default picked it, or because nobody audited the model selection in a pipeline that grew over several months.

Reasoning models that cost 3x to 10x more per task than non-reasoning alternatives justify that premium on a subset of tasks. Identifying that subset and routing everything else to a cheaper configuration is the most leveraged cost optimization available in 2026 AI infrastructure.

Reasoning models on DeepInfra

DeepInfra serves the full reasoning model tier — DeepSeek V4 Pro and V4 Flash in both think and non-think modes, Kimi K3, Claude Opus 4.8, Qwen3 235B, and more — alongside non-reasoning alternatives at the same endpoint. Switching between reasoning and non-reasoning is a model parameter change, not an integration change, which makes the kind of per-task routing described above straightforward to implement.