Reasoning Models: When Thinking Is Worth Paying For
How thinking models change latency, cost, and quality inside product features, and how to pick an effort level per feature instead of per app.
Every current frontier model can think before it answers, and thinking makes models measurably better at hard problems. It also changes the economics of your features. A triage label that used to take a fraction of a second can take several seconds if the model decides to deliberate, and a drafted reply can bill five times more output tokens than the text you actually display.
None of that is a reason to avoid thinking. It's a reason to decide, feature by feature, how much of it you're buying. In this lesson you'll learn what thinking does from the outside, how to measure its cost and latency in your own features, how to choose an effort level for each feature with data instead of instinct, how to turn thinking down or off where the model allows it, and how to design the user experience around the wait.
What changes when a model thinks
A reasoning model generates private working-out, called thinking, before writing its visible answer. Mechanically it's the same token-by-token generation you learned about in How LLMs Generate Text, just aimed at scratch work: restating the problem, trying an approach, checking it, and correcting course.
From your application's point of view, three things change:
- Latency to the first visible word grows. Thinking happens before the answer, so with streaming, the user waits through all of it before seeing any text. A model that thinks for 1,500 tokens adds that generation time to every response.
- Output tokens grow. Thinking is billed as output tokens, the expensive kind. By default you don't even see the thinking text: Claude returns
thinkingblocks with empty text, but the tokens are inusage.output_tokensall the same. - Quality improves on the right tasks. Multi-step logic, reconciling conflicting information, math, code, and decisions with several constraints all benefit. Tasks where the answer is directly in the input mostly don't.
Current Claude models think adaptively: the model decides per request whether and how much to think. Easy inputs get little or no thinking; hard ones get more. You influence that decision with effort, which you met in Output Controls, rather than setting a fixed thinking budget. The old budget_tokens setting is rejected on current models.