A short answer does not mean a small generation cost. Here is how reasoning tokens work, and when the extra cost is actually worth it.
A reasoning model does more work before producing the answer you see. It generates internal reasoning tokens to work through the problem, consider alternatives, and arrive at a response, and for providers that bill reasoning as output tokens, those internal tokens are charged even when they aren't included in the visible response. This guide covers how reasoning tokens actually work, why a short visible answer doesn't necessarily mean a small generation cost, and how to tell when reasoning mode is worth paying for.
Key takeaways
When a standard model receives a prompt, it generates its response directly, token by token, with each token representing genuine progress toward the final answer. A reasoning model, given the same prompt, does something different first: it generates internal reasoning tokens, sometimes described as chain of thought in the research literature, though the two terms aren't perfectly interchangeable, breaking the problem into steps, considering approaches, checking its own logic, before producing the response you actually see. Those internal reasoning steps also consume generated tokens, even though they aren't necessarily returned as visible text.
For providers that bill reasoning as output tokens, those internal tokens are charged even when they aren't included in the visible response. OpenAI, for example, bills reasoning tokens as output tokens, and its API documentation shows this explicitly: a completion's usage object includes a completion_tokens_details field with a reasoning_tokens count, generated by the model but not shown in the visible response. Anthropic's own documentation on extended thinking similarly confirms that the billed output token count reflects the full thinking process, including thinking tokens, not just whatever summary the response displays.
For some providers, these aren't three independently priced buckets: reasoning tokens are counted inside the same output-token usage total as the visible response, which is exactly why they're easy to miss when estimating cost from the answer length alone.
A short, simple-looking answer can conceal a substantial number of reasoning tokens generated to arrive at it. Suppose a request sends 2,000 input tokens, generates 8,000 reasoning tokens internally, and returns a 500-token visible answer. The user sees only the 500 generated tokens they read, but the provider's billed output-token count may include the 8,000 reasoning tokens as well. The visible answer, on its own, gives no indication of how much generation happened to produce it.
The exact amount varies substantially by task, model, and reasoning setting, and no single ratio applies universally. Microsoft's Azure OpenAI documentation states that a single request can consume anywhere from a few hundred to tens of thousands of reasoning tokens depending on how hard the problem is. A short visible answer, in other words, does not necessarily imply a small generation cost behind it; a genuinely hard, multi-step problem can land toward the higher end of that range, while a straightforward question routed to a reasoning model unnecessarily can still generate meaningful overhead for comparatively little benefit.
⚡ Output tokens already carry a higher price at many providers
Reasoning tokens add volume to the output side of the bill. Because generation is autoregressive and requires repeated decoding steps, output tokens are often priced higher than input tokens. The exact price difference varies by provider and model, and pricing reflects more than just this mechanical distinction, including hardware utilization, batching, and provider-specific serving economics. Reasoning tokens don't introduce a new pricing tier of their own; they add volume to a side of the bill that was already priced higher, which is part of why the effect is easy to underestimate from the outside.
How much of the reasoning process a provider actually shows you differs meaningfully. Some providers hide the internal reasoning entirely, returning only the final answer along with a token count that reveals how much reasoning happened without showing its content, exactly the reasoning_tokens field OpenAI's API documents. Others surface the reasoning as a visible block the response includes directly, sometimes marketed as extended thinking or a thinking mode feature, or as a partial summary rather than the full internal process, which is how Anthropic's thinking_tokens are exposed. What the evidence from these two providers actually shows is narrower than a universal rule: for providers that bill reasoning as output tokens, hidden or summarized tokens can still be billed in full. Billing treatment itself can vary by provider, so this isn't a claim that every provider everywhere handles reasoning cost identically, only that visibility and billing are separate decisions a provider makes.
Reasoning mode is a genuine capability tradeoff, not a strictly better mode to leave on by default. It tends to earn its cost on tasks that genuinely benefit from multi-step deliberation: non-trivial math, multi-step logical reasoning, code that requires tracing through several dependent steps, or problems where a wrong first instinct needs to be caught and corrected before the final answer. Microsoft's own documentation reflects this same differentiation, describing lower reasoning effort as suited to latency- and cost-sensitive tasks, with higher effort reserved for complex reasoning, debugging, and planning.
It tends to be a poor fit, cost-wise, for tasks a standard model already handles well: formatting, simple factual lookups, short classification tasks, or straightforward conversational replies. Sending every request to a reasoning-enabled endpoint by default, rather than reserving it for tasks that actually need the extra deliberation, is one of the more common and avoidable ways teams inflate their own bill. For teams serving mixed workloads, that makes routing part of cost control: simple requests can stay on lower-cost, non-reasoning models, while harder requests are sent to reasoning models only when the quality gain justifies the additional token usage.
Getting a handle on reasoning cost is mostly a measurement problem before it's a tooling problem. Start by measuring reasoning tokens separately from visible output, using the provider's own usage metadata where it's exposed, rather than estimating cost from the length of the answer alone. Compare that reasoning-token figure against visible output across a representative sample of real traffic to get a workload-level picture of how much overhead reasoning is actually adding. From there, route by task complexity: default simple, low-stakes requests to a non-reasoning model, and reserve reasoning mode for the requests where the extra deliberation is genuinely likely to change the answer.
packet.ai's Token Factory is designed around this kind of visibility, exposing token-level usage so reasoning overhead shows up as a measurable, trackable component of inference spend rather than a mystery in the monthly total. It's currently in private preview, with the specific model catalog and pricing still being finalized.
Join the waitlist for early access once it opens.
Last reviewed: September 4, 2026. For the broader mechanics of how tokens translate into cost generally, see the packet.ai LLM inference cost guide.
Same models. Same API. Fraction of the cost. Start free — no credit card required.
Start Building →
