A reasoning model spends tokens thinking before it writes the answer, and you pay for those tokens whether or not you can read them. That one fact explains most of the surprises teams hit with reasoning models: bills that rise without longer answers, responses that arrive empty, and caches that stop hitting after a harmless-looking settings change. This guide explains what the thinking is, what the effort setting does at Anthropic and OpenAI, and how to configure both so cost and latency stay predictable. For the basics of how tokens turn into cost, see tokens, context windows and what an AI request costs.
What a reasoning model does differently
The idea has a research origin. Wei et al. showed in 2022 that prompting large language models with examples that include intermediate reasoning steps, which they called chain-of-thought prompting, improved performance on arithmetic, commonsense and symbolic reasoning tasks.[5] Current reasoning models move that behaviour inside the model: it produces reasoning before the answer without you writing the examples.
The API consequences are what matter day to day. OpenAI's documentation says reasoning models use internal reasoning tokens that help with planning, tool use and multi-step tasks, that these tokens are hidden from the API but still use context window space, and that they are billed as output tokens.[4] Anthropic's documentation says the same about its models: tokens used while thinking are billed as output tokens.[1]
Hidden does not mean free
Both vendors separate what you are billed for from what you can see.
| Question | Anthropic (Claude API) | OpenAI (API) |
|---|---|---|
| How are thinking tokens billed? | As output tokens[1] | As output tokens[4] |
| Can you read the raw reasoning? | You receive a summary; billing covers the full thinking, not the summary[1] | Raw reasoning tokens are not exposed; a summary is available if you opt in[4] |
| Where is the count reported? | usage.output_tokens_details.thinking_tokens[1] | output_tokens_details.reasoning_tokens[4] |
Anthropic puts the consequence bluntly: the billed output token count does not match the visible token count, because you are billed for the full thinking process, not the content shown.[1] If you log only the length of the text you display, you will under-estimate spend. Log the reasoning-token field from the usage object instead.
Anthropic also notes that prior thinking blocks that remain in context are billed as input tokens, with the default depending on the model.[1] In a long agent loop, that is a second place where thinking shows up on the invoice.
What the effort setting controls
On Anthropic's API, effort is set at output_config.effort and has five levels: low, medium, high, xhigh and max.[1][2] Anthropic's wording is worth quoting because it corrects a common assumption: "Effort is a behavioral signal, not a strict token budget."[2] At lower levels Claude still thinks on sufficiently difficult problems, but thinks less. The parameter also affects all tokens in the response, including text and tool-call arguments, so lower effort means fewer and terser tool calls.[2]
Defaults differ by model. As of the 2026-10-12 read of the effort page, medium is the default on Claude Opus 5.5 and Claude Haiku 5.5, and high is the default on the other models that support effort.[2] Setting the default explicitly behaves the same as omitting it.[2] Because defaults moved between model generations, a request that omits effort can run one level lower after an upgrade, which is a reason to set it explicitly and re-test.
OpenAI's reasoning.effort accepts none, minimal, low, medium, high, xhigh and max, with availability depending on the model.[4] The documentation notes model-specific limits, for example that one listed model rejects none with an HTTP 400 and another defaults to medium.[4] Lower effort favours speed and fewer tokens; higher effort gives more complete thinking at the cost of latency and tokens.[4] OpenAI also describes effort as a tuning knob rather than the primary way to recover quality, and recommends giving the model a clear goal, constraints and output format instead of prescribing every intermediate step.[4]
"Thinking budget" is going away on newer Claude models
Older Claude integrations set a fixed budget with thinking: {type: "enabled", budget_tokens: N}, with a minimum of 1,024 tokens.[3] Anthropic's current documentation says this is deprecated on the Claude 4.6 models and that Claude 4.7 and later models reject it with a 400 error; the replacement is adaptive thinking plus an effort level.[3] Under adaptive thinking, Claude decides per request whether and how much to think, so a simple question may get no thinking block at all.[1]
Two practical consequences follow. First, do not write application logic that assumes every assistant turn starts with a thinking block.[1] Second, if you need predictable thinking cost, your levers are now the effort level and the output cap rather than a token target.
Set the output limit for thinking plus answer
Thinking tokens count toward the output limit. Anthropic states that max_tokens is a hard cap on total output, thinking and response text combined, and that a limit sized for a response with no thinking is often too small once the model starts thinking on hard requests.[1] If a response stops with stop_reason: "max_tokens", Anthropic gives two remedies: raise the cap, or lower the effort so more of the budget is left for the answer. Which is right depends on whether the truncated requests needed the reasoning.[1]
OpenAI documents the same failure more sharply. max_output_tokens caps all generated tokens including reasoning tokens, and when the limit is hit the response status is incomplete with reason max_output_tokens, which "might occur before any visible output tokens are produced."[4] That is the empty-response symptom. OpenAI recommends reserving at least 25,000 tokens for reasoning and outputs when starting out, then adjusting from observed usage, and notes that reasoning can range from a few hundred to tens of thousands of tokens.[4] For Anthropic's highest levels, its guidance for several recent models is to start around 64k tokens at xhigh or max and tune from there.[2]
Why changing effort can break your prompt cache
Anthropic's documentation says the resolved effort value is rendered into the prompt, so changing it between requests invalidates cache breakpoints.[1] Its worked example shows a second request reading 3,546 tokens from cache and a third request, after effort moved from medium to low, re-creating the cache instead.[1] The same behaviour applies to the legacy thinking budget.[3]
The documented workarounds are to hold effort constant within a cached conversation, or, on models that support it, to use the per-message effort change, which is in beta and keeps earlier cache breakpoints intact.[2] Our reading: vary effort across workloads (routing easy and hard tasks to different configurations), not inside one long cached session unless the model supports the per-message form.
A practical way to choose a level
Vendor guidance converges on the same method: start from the documented default for your model, then sweep. Anthropic recommends running an effort sweep on your own evals rather than carrying settings over from an earlier model.[2] Its model-specific notes illustrate the range: for Claude Haiku 5.5 it suggests starting at medium and using low for chat and simple high-volume work, while warning that in long agent prompts the model is more likely to skip a search or a check at low.[2] For Claude Opus 4.7 it says max adds significant cost for relatively small gains on most workloads and can cause overthinking on structured-output tasks.[2]
A workable procedure, which is our suggestion rather than vendor guidance:
- Build a small eval set of real tasks with a pass/fail check each. See how to build LLM evals that survive production.
- Run every effort level you might ship, with an output cap large enough that nothing is truncated.
- Record pass rate, reasoning tokens, total tokens and latency per level.
- Pick the lowest level whose pass rate meets your bar, then re-run when the model changes. See how to build evals that survive model changes.
For model tiers and where a small model fits, see Claude Haiku 5.5: specs, pricing and when to use it.
What stays uncertain
Neither vendor publishes how many thinking tokens a given task will use, only that it varies widely. Effort levels are not comparable across models or vendors. And reasoning summaries are summaries; in our reading they should not be treated as an audit log of what the model computed. Pricing and defaults on these pages change with each model release; check the linked documentation before you rely on a specific value.
