Reasoning models think before they answer, and the thinking is billed. On OpenAI o-series models, Claude with extended thinking, Gemini 2.5 thinking models and DeepSeek's reasoner, those internal tokens are charged at the output rate even though the user never sees most of them. A cost model that counts only visible text will be wrong by a multiple.
How big the gap is
Take an o3 request with 3,000 input tokens and a 500-token visible answer. If you count only what you can see, the call costs $0.0100. The usage block reports 6,000 reasoning tokens as well, all billed at $8.00 per 1M, so the real cost is $0.0580, 5.8x the naive figure.
Reasoning length varies with the difficulty of each request, so the multiple is not stable either. Two tenants on the same feature can have very different reasoning profiles because their questions differ.
Measure it per request
Providers report reasoning usage separately: OpenAI includes reasoning tokens in the output token details, Gemini reports thought tokens in its usage metadata, and Anthropic counts thinking within output tokens. Record reasoning tokens as their own class on every event so you can see which tenants and features drive them. PALM SOUQ does this from the provider usage block on every response.
Lever 1: effort and thinking budgets
OpenAI reasoning models accept a reasoning effort setting of low, medium or high. Claude extended thinking takes an explicit thinking token budget. Gemini 2.5 models accept a thinking budget, and Flash models can turn thinking off. Lowering effort is the fastest saving: if low effort cut reasoning from 6,000 to 1,500 tokens on the request above, the cost would fall from $0.0580 to $0.0220.
Lever 2: cap output tokens with care
A maximum output token limit bounds the worst case, but on reasoning models it counts reasoning tokens too. If the limit is reached during reasoning, you pay for the reasoning and get little or no visible answer. Set caps from the observed distribution, at a high percentile of total output, and alert on responses that end because of the limit.
Lever 3: route only hard requests to reasoning models
Many features send every request to a reasoning model when only a minority need it. A small router, or a rule on the feature header, can send easy requests to a non-reasoning model and hard ones to the reasoning model. Switching the same request to o4-mini, at $1.10 input and $4.40 output, would cost $0.0319 even with the same reasoning length.
Lever 4: breakers for reasoning loops
Agents built on reasoning models can loop like any agent, and each step is more expensive. Token velocity limits are especially useful here, because reasoning bursts produce high token rates without repeated tool calls. Set the velocity threshold per feature from observed traffic, and keep tool thrashing and step limits enabled.
features:
research_agent:
models: ["o3"]
reasoning_effort: medium
max_output_tokens: 16000
breakers:
token_velocity: { max_tokens_per_second: 30000, window_seconds: 10 }
max_steps: { limit: 40 }
quick_answer:
models: ["gpt-4.1-mini"]Reporting
- Reasoning tokens as a share of output tokens, per feature, week over week.
- Cost per successful task, not per request, for agent features on reasoning models.
- Responses truncated by the output cap, which signal a cap set too tight.
Pricing reasoning features to customers
Because reasoning cost varies per request, flat per-request pricing for a reasoning feature carries more risk than it does for an ordinary chat feature. Three structures work well. You can sell reasoning as a premium tier with its own monthly allowance, so heavy users pay for what they use. You can charge per task with an envelope that bounds your cost per task. Or you can expose an effort choice to the user, with deep analysis consuming more of the allowance than a quick answer.
Whichever you choose, set it from measured reasoning distributions per feature, not from the visible output length, and revisit it whenever a provider ships a new reasoning model, since reasoning behavior often changes more between versions than prices do.
Meera Krishnamurthy
CTO, PALM SOUQ
IISc (MTech, CDS). Built low-latency edge proxies at a CDN provider and rate-limiting infrastructure for a payments network handling 9,000 TPS. Owns the gateway and breaker engine.