What It Buys — and What It Costs
Lesson 3 of 3 in RL for Reasoning Models.
Where does reasoning training actually pay? Follow the reward signal. The best-documented gains sit exactly where the training signal was verifiable: competition mathematics, code against test suites, logic and structured multi-step problems. That is no coincidence — it is the same domains the checker could cover during training. Public reports, R1’s included, consistently show their largest improvements on checkable benchmarks of this kind.
Outside the checkable zone, be more careful. Some transfer to adjacent skills is plausible and often claimed — careful multi-step work is useful in many places — but the evidence for open-ended tasks is thinner and harder to measure by construction: if we had a reliable checker for “great strategy memo”, we would have trained against it. For writing quality, judgment calls, and taste, more thinking does not reliably mean better output, and published evaluations of those qualities lean on exactly the learned judges and human preferences whose limits this domain keeps flagging. One caution deserves italics: benchmarks are checkable by construction — the tasks where reasoning models look most dramatic are structurally the tasks most like their training signal. Your workload may not look like that. Test on your own traffic before you pay for thinking.
Bar chart with four bars of illustrative output-token counts. Extract an invoice date: standard model 40 tokens, reasoning model 650 tokens. Diagnose a multi-step logic bug: standard model 300 tokens, reasoning model 2,400 tokens. The chart shows the reasoning model multiplying output length on both tasks, whether or not the extra thinking was needed.
Now the bill. Output tokens are the expensive kind twice over: they are generated sequentially — one forward pass per token, so latency scales nearly linearly with output length — and on metered platforms they are typically priced above input tokens. Thinking tokens are output tokens, so a response that thinks ten times longer costs roughly ten times the output tokens and takes correspondingly longer to arrive, while its growing KV cache occupies serving memory the whole time. None of this involves new machinery — it is the ordinary economics of generation, multiplied by trained verbosity. The Inference & Serving domain prices these mechanisms precisely — batching, memory, time-to-first-token versus time-per-token; here the takeaway is a single design consequence: reasoning shifts spend from a per-model decision to a per-request decision. The same model, on the same task, can produce a cheap fast answer or an expensive careful one, and something in your system is choosing which.
In production
Reasoning modes turn accuracy into a per-request purchasing decision: the same hosted model can answer fast and cheap or slow and thorough, and the difference lands on your invoice as output tokens. Budget per-request, not per-model.
AWS
On Amazon Bedrock, models with extended-reasoning support surface thinking as part of the metered output — so enabling reasoning on a route multiplies that route’s output-token spend and latency, invisibly to callers unless you surface it. The evergreen defenses are architectural: set per-request output-token limits, route simple traffic to non-reasoning models or modes, and watch output-token distributions per route rather than per model, because one “thoughtful” endpoint can dominate an account’s spend.
Azure
In Azure AI Foundry, quota and throttling are denominated in tokens per minute, and thinking tokens count — a reasoning-heavy route burns through the same deployment quota several times faster than its request count suggests. Capacity planning inherited from standard chat models breaks quietly: plan deployments from measured thinking-inclusive token counts on real traffic, and set latency SLOs per route, since a reasoning request can legitimately take an order of magnitude longer than a standard one.
Google Cloud
On Vertex AI, models that support configurable thinking budgets let the request, not the model default, decide how much reasoning to buy — which is exactly where that decision belongs. Put the budget parameter in your request path under application control, log actual thinking-token consumption per feature, and audit which features’ answers actually improve with higher budgets; the rest are paying a thinking tax for nothing.
Tool: Token Cost Estimator — Put numbers on the multiplier: model a workload in the Token Cost Estimator and watch what happens to cost when output tokens grow 5–10x on a fraction of your traffic.
Interactive checkpoint quiz (1 questions) — open this page in a browser to take it.