Reasoning token cost allocation.
Cost guide · August 1, 2026
Reasoning tokens are the fastest-growing line item on modern LLM bills. Models that "think" before answering generate intermediate reasoning steps billed separately from input and output. For complex workloads, reasoning tokens can exceed the cost of the final answer by 3-5x. Most teams do not meter them separately and miss the real cost driver.
What reasoning tokens are
Reasoning tokens are the model's internal monologue: the chain-of-thought, planning, and self-correction that happens before the final output. Providers bill them differently:
| Provider / Model | Reasoning token price | Visibility |
|---|---|---|
| OpenAI o1, o3 | ~2-4x output token price | usage.completion_tokens_details.reasoning_tokens |
| Claude extended thinking | Same as output tokens | usage.output_tokens (includes thinking) |
| Gemini thinking mode | Same as output tokens | usage.output_tokens (includes thinking) |
The key insight: reasoning tokens are not free "thinking time." They are billed compute. A request that generates 1,000 output tokens after 8,000 reasoning tokens costs 9x the output-only price for OpenAI reasoning models.
Why teams miss this cost
Three reasons reasoning costs hide:
- Aggregation. Daily or monthly aggregates mix reasoning and non-reasoning requests. A support endpoint with 10% reasoning models looks like a modest increase, not a 3x cost spike on specific requests.
- No per-request metering. Without per-request records, you cannot see that the code-debugging endpoint uses 10x more reasoning tokens than the summarization endpoint.
- Quality assumption. Teams assume reasoning = better. For simple tasks, reasoning tokens add cost without improving output. A classification task does not need 5,000 tokens of deliberation.
How to meter reasoning tokens
Add reasoning_tokens to your metering schema alongside input_tokens and output_tokens:
{
"provider": "openai",
"model": "o3",
"input_tokens": 1200,
"output_tokens": 450,
"reasoning_tokens": 3200,
"feature": "code-review",
"team": "platform",
"cost_estimate": 0.028
}
From this you can calculate the reasoning overhead ratio:
reasoning_overhead = reasoning_tokens / (input_tokens + output_tokens)
A ratio above 2.0 means the model spends more time thinking than reading and writing combined. Ratios above 5.0 are common for math, code, and multi-step analysis. Ratios below 0.5 mean the task probably does not need a reasoning model.
Allocating costs to features
Reasoning costs belong to the feature that requested them. A customer-facing code assistant and an internal document summarizer should not share the same cost bucket.
Minimum allocation dimensions:
- feature / endpoint
- model (reasoning vs non-reasoning)
- reasoning_overhead_bucket (low, medium, high)
- customer / tenant (for external products)
From this you can answer: "Which features are paying for thinking they do not need?" The answer is usually surprising. Simple Q&A, extraction, and classification endpoints often show high reasoning overhead because they were routed to a reasoning model by default.
Controlling reasoning costs
Four levers, in order of impact:
1. Model routing. Route simple tasks to non-reasoning models. A support ticket classifier does not need o3. Route it to GPT-4o-mini or Claude Haiku. Reserve reasoning models for tasks that fail without them: multi-step math, code debugging, complex analysis.
2. Reasoning effort caps. OpenAI supports reasoning_effort: low|medium|high. Set it explicitly per endpoint. Low effort reduces reasoning tokens by 50-80% for tasks that need some thinking but not exhaustive deliberation.
3. Prompt design. Tell the model when to think. "Think step by step" invites long reasoning. "Answer directly" suppresses it. For tasks where you want brevity, say so.
4. Fallback chains. Try a non-reasoning model first. If confidence is low or the task is flagged complex, escalate to reasoning. This keeps simple tasks cheap and only pays for thinking when needed.
When reasoning is worth it
Reasoning tokens pay for themselves when they prevent errors that cost more than the tokens. A code review that misses a bug costs engineering time. A financial analysis that makes a math error costs credibility. A legal document that misreads a clause costs risk.
The test is not "did output quality improve?" The test is "did the improvement prevent a downstream cost?" For customer-facing products, that cost might be churn. For internal tools, it might be engineering time. For regulated industries, it might be compliance.
Decision framework
Before enabling reasoning for an endpoint:
- Does the task require multi-step logic, math, or code? If no, use a non-reasoning model.
- Is the output high-stakes (customer-facing, financial, legal)? If no, use a non-reasoning model.
- Can you measure reasoning_tokens separately? If no, implement metering first.
- Is the reasoning overhead ratio >2.0 for this endpoint? If yes, test with reasoning_effort=low or a non-reasoning model.
Reasoning is a scalpel, not a hammer. Use it where thinking prevents expensive mistakes, not where it makes answers sound more thorough.
Related
- LLM usage metering and billing - how to meter reasoning tokens alongside input and output.
- AI cost optimization - the broader optimization framework.
- Model routing - routing simple tasks to cheaper models.
- Agent spend guardrails - preventing runaway reasoning loops in agents.