Why does a reasoning model like DeepSeek V4 quietly inflate the output-token bill?

**Reasoning models** are trained to emit an internal chain-of-thought before they emit the visible answer. The thinking pass is real generation: the model produces tokens one at a time, just like the final reply, through the same decode loop and the same HBM bandwidth. Those thinking tokens are billed. The provider charges per output token generated, not per token shown to the end user. So even though the UI hides the chain-of-thought, the bill still includes it. A final answer that looks 200 tokens long can hide 2,000 to 10,000 thinking tokens behind it, which is why the output-token bill jumps by 10-50x when a workload switches from a non-reasoning model to a reasoning one. The API usually exposes this directly. Look at the usage block of the response. You will find a separate counter, often called reasoning_tokens or thinking_tokens, that aggregates the hidden pass. If you only watched completion_tokens before, that counter was zero and the cost looked manageable. With a reasoning model, that counter dominates and your old monitoring misses the spike entirely. The mitigations are routing and budget control. Cap the reasoning budget per request when the task does not need deep thinking. Route only the hard tail to the reasoning tier, and use a cheaper non-reasoning model for the rest of the traffic. Watch the reasoning-token counter as a first-class metric, the same way you watch latency or error rate.

**The cost driver is the hidden chain-of-thought.** Reasoning models like DeepSeek V4 are trained to emit an internal thinking pass before the visible answer. Those tokens are generated by the same decode loop as the final reply, occupy the same HBM bandwidth, and are billed by the provider as output tokens regardless of whether the UI shows them. That is why a final answer that looks 200 tokens long can hide 2,000 to 10,000 reasoning tokens. Output-token amplification of 10-50x is typical depending on task difficulty: easy tasks barely think, hard tasks generate long internal monologues. Either way, the visible completion length tells you almost nothing about the bill. The API exposes the hidden pass explicitly. The usage block of the response typically carries a separate counter, often named reasoning_tokens or thinking_tokens, alongside the familiar completion_tokens. The two roll up into a total output-token line that drives billing. A team that only watched completion_tokens before the switch will miss the cost regression entirely until the monthly invoice arrives. Mitigations follow the framing. **Cap the reasoning budget per request** where the API exposes that knob; for easy tasks, a low budget or disabled reasoning gives you the model's quick-thinking output at non-reasoning cost. **Route by difficulty** so only the genuinely hard tail of traffic uses the reasoning tier, and the rest goes to a cheaper non-reasoning model. **Instrument the reasoning-token counter** as a first-class metric per route, so a regression is visible the day it happens, not at month-end. The teams that get this right treat reasoning tokens as a budget line, not a hidden side effect.