Yes, reasoning models can cost far more than standard LLMs for the same visible answer, because you pay for hidden "thinking" tokens the model generates before it replies. Those tokens are billed at the output rate but never appear in the response, so a request that looks like 400 output tokens can bill like 4,000. The practical fix is to measure billed completion tokens rather than eyeballing answer length, then price each request with your model's actual input and output rates.
What Are Reasoning Models and Thinking Tokens?
A standard large language model (LLM) maps your prompt to a response in one pass: it predicts the next token, then the next, until it stops. A token is the unit models read and bill in — roughly three-quarters of a word in English, so "reasoning" is about two tokens. A reasoning model adds a stage before that response: it generates an internal chain of intermediate steps, sometimes called a scratchpad or reasoning trace, and only then writes the answer you see.
Those intermediate tokens are what people mean by thinking tokens (also called reasoning tokens). Whether you can see them depends on the provider: some return a summary of the reasoning, some expose the full trace, and some hide it entirely. In every case the model generated them, and generation is what you pay for.
The distinction that matters for budgeting is visible versus billed. Visible output is what lands in the response field. Billed output is everything the model generated, hidden trace plus final answer. On a hard math or logic prompt, the hidden portion can dwarf the visible one; on a trivial prompt, a reasoning model may barely think at all, so the overhead is not a fixed multiplier. It scales with problem difficulty, which is exactly why flat per-request estimates mislead.
Why Hidden Tokens Change Your Cost Model
API pricing usually has two rates: input tokens (your prompt, plus any conversation history you resend) and output tokens (everything the model generates). Thinking tokens are generated, so they bill at the output rate — typically the more expensive of the two. If output costs several times input, as is common, a hidden trace is billed at that premium.
Take a concrete estimate. Suppose a model charges $3 per million input tokens and $15 per million output tokens, and one request has a 1,000-token prompt and a 300-token visible answer. Billed naively, that is:
input: 1,000 × $3 / 1,000,000 = $0.0030
output: 300 × $15 / 1,000,000 = $0.0045
total: = $0.0075
Now assume the model actually generated 2,700 hidden thinking tokens. Billed output becomes 3,000 tokens:
output: 3,000 × $15 / 1,000,000 = $0.0450
total: = $0.0480
Same visible answer, roughly 6× the cost. The rates above are illustrative, not quoted prices — substitute your provider's real numbers.
Two second-order effects compound this. First, long traces enlarge the context the model attends to on every subsequent step, and providers that bill cached input (a KV cache stores attention state so repeated context is cheaper to process) may charge a reduced rate for reused context but still charge for the growing trace. Second, if your application is multi-turn, each new turn resends prior messages as input, so a verbose reasoning history inflates input cost on later calls too. Budget per conversation, not just per call.
Measuring Thinking Tokens with a Token Counter
Reasoning models often return a separate count for thinking tokens, but not every provider exposes it the same way. A reliable workflow is: run the same prompt through a token counter that understands the model's tokenizer, then compare the reported breakdown (prompt tokens, visible completion tokens, and reasoning tokens) against what the provider's usage object returns.
A token counter typically tells you three things:
- How many tokens your prompt consumes (input tokens).
- How many tokens the final answer contains (output tokens).
- For reasoning models, how many tokens were spent before the answer (thinking tokens), when the API exposes them.
If the API does not report thinking tokens directly, estimate them by subtracting visible output tokens from total billed output tokens:
estimated_thinking_tokens = billed_output_tokens - visible_answer_tokens
Practical steps:
- Send a fixed prompt to the model and record the usage fields from the response.
- Count the same prompt and the visible answer with a token counter.
- Compare counts; a large gap between billed output and visible answer tokens is your thinking overhead.
- Repeat across a few prompt types (simple lookup, multi-step math, code debugging) to see where overhead grows.
Caveat: reasoning tokens are often billed as output tokens even when hidden, and some providers include them in a single "completion tokens" number. Always check the usage object rather than guessing from the text length.
Estimating Real Cost per Request with the LLM API Cost Calculator
Cost per request depends on input price, output price, and how reasoning tokens are billed. Use this formula:
cost = (input_tokens / 1M * input_price_per_1M)
+ ((visible_output_tokens + thinking_tokens) / 1M * output_price_per_1M)
Worked example with stated assumptions (prices are illustrative, not real):
- Input price: $3 per 1M tokens.
- Output price: $15 per 1M tokens.
- Prompt: 800 input tokens.
- Visible answer: 400 tokens.
- Thinking tokens: 2,000.
Input cost: 800 / 1,000,000 * 3 = 0.0024.
Output tokens total: 400 + 2,000 = 2,400.
Output cost: 2,400 / 1,000,000 * 15 = 0.036.
Total: 0.0024 + 0.036 = 0.0384, about $0.038 per request.
A standard LLM with the same prompt and a 400-token answer at the same prices: 0.0024 + (400/1,000,000*15) = 0.0024 + 0.006 = 0.0084, about $0.008. The reasoning model here costs roughly 4.5x more, driven almost entirely by thinking tokens.
Checklist before trusting a calculator:
- Confirm whether thinking tokens are billed at input or output rates.
- Check if cached input tokens get a discount (KV-cache reuse).
- Include retries and failed requests in the estimate.
- Multiply per-request cost by expected monthly volume.
- Re-test after prompt changes, since reasoning length varies by task.
Frequently Asked Questions
What are thinking tokens in reasoning models?
Thinking tokens are the intermediate tokens a reasoning model generates internally before it produces the answer you actually see. Instead of replying immediately, the model writes out a chain of steps — restating the problem, testing approaches, backtracking — and this scratch work is billed as output even when the API hides it from the response. Standard LLMs can also reason step by step, but only when prompted to show their work; reasoning models do it by default, and the trace can run to hundreds or thousands of tokens per request.
Do reasoning models charge for hidden thinking tokens?
Yes, in most cases. Providers typically bill thinking tokens at the output-token rate, because the model genuinely generates them, and output pricing is several times higher than input pricing. Some APIs return a token-usage breakdown that separates reasoning tokens from visible output, while others only report a combined output count — which is exactly why hidden costs surprise people. Check your provider's usage object; if reasoning tokens aren't itemized, treat total output minus visible answer length as your thinking-token estimate.
How much more expensive are reasoning models than standard LLMs?
There's no single multiplier, but you can reason it out. Reasoning models usually carry a higher per-token price than standard models and emit far more output tokens per request, so a request that costs a fraction of a cent on a standard LLM can cost several times more on a reasoning model. A rough estimate: if a reasoning model's output price is a few times the standard model's and it generates 5–20x more output tokens, expect an order-of-magnitude difference on reasoning-heavy prompts. Simple factual queries usually don't justify that premium.
How does the KV-cache affect cost during long reasoning traces?
The KV-cache (key-value cache) stores attention states for tokens already processed so the model doesn't recompute them at every step. During a long reasoning trace, each new token attends to the entire cached context, and providers commonly price cached input tokens at a discount — but the cache still consumes memory proportional to trace length. Long traces therefore raise cost two ways: more billed output tokens, and more cached context carried through each step. Some providers also charge cache storage or expire it quickly, so repeated long sessions can cost more than a single call suggests.
Can I reduce reasoning token costs without losing answer quality?
Often, yes. Route simple queries to a standard LLM and reserve reasoning models for genuinely hard problems; cap or lower the reasoning effort setting where the API exposes one; and keep prompts tight so the model doesn't burn tokens restating context. Asking for a concise final answer doesn't shrink the hidden trace, but shortening the problem statement and avoiding ambiguous instructions does. Measure before and after with a token counter — quality drops are usually visible on a small eval set before they show up in production.