If you learned to use Claude's extended thinking by setting budget_tokens, I have news that'll either annoy or relieve you. On Opus 4.7, 4.8, and Fable 5, that parameter is gone. Send thinking: {type: "enabled", budget_tokens: 8000} to any of them and you get a 400. The whole model of "give the model a fixed token allowance to think" has been replaced by two newer controls that work better and confuse people at first. Let me walk through what actually changed and how to drive the new system.
The old model and why it died
Extended thinking with budget_tokens was a hard ceiling: you said "think with up to N tokens," and the model spent up to N tokens reasoning in a scratchpad before answering. It worked, but it was clumsy. You had to guess the budget per task, and the model couldn't decide for itself that an easy question needed almost no thinking while a hard one needed a lot. You were doing the model's job.
Adaptive thinking: the model decides how much to think
The replacement is thinking: {type: "adaptive"}. With adaptive thinking on, the model decides per-request how much to think and when — including interleaving thinking between tool calls automatically, no beta header needed. No budget to tune. An easy lookup gets a quick answer; a multi-step reasoning problem gets deeper thought. The model calibrates.
One thing that trips everyone up: on Opus 4.7 and 4.8, adaptive thinking is off by default. If you just omit the thinking field, the model runs without thinking. You have to set thinking: {type: "adaptive"} explicitly to turn it on. (Fable 5 is the exception — thinking is always on there, and an explicit disabled actually 400s.)
Effort: how hard to work overall
The second control is effort, and it's a different axis than thinking. It lives inside output_config, not at the top level:
output_config: {effort: "high"}
The levels are low, medium, high, xhigh, and max. Default is high. Effort controls thinking depth and overall token spend together — lower effort means fewer and more-consolidated tool calls, less preamble, terser confirmations. Higher means more exploration, more verification, more thoroughness.
The practical recommendations from working with these:
xhighis the sweet spot for coding and agentic work — it's literally the default in Claude Code.highis the minimum for anything intelligence-sensitive.mediumandlowfor routine or latency-sensitive work, subagents, simple classification.maxwhen correctness matters more than cost and you're willing to pay for the ceiling.
Here's a counterintuitive finding: on Opus 4.8, don't reflexively crank effort to xhigh. The intelligence ceiling is higher than prior models, so high is often plenty, and on agentic work, higher effort up front can reduce total cost because the model plans better and takes fewer turns. The relationship isn't monotonic. Sweep medium, high, and xhigh on your own evals and measure. I've seen medium match xhigh on tasks where the extra deliberation was pure waste.
A subtlety about thinking output that'll waste your afternoon
The thinking the model does and the thinking you see are separate. On Opus 4.7, 4.8, and Fable 5, thinking blocks still appear in the response stream, but their text is empty by default — display defaults to "omitted". The reasoning happens and gets billed the same; you just don't get the text back.
So if you stream reasoning to your users and you migrated from 4.6, your "thinking" UI suddenly renders nothing and looks like a long frozen pause before output. The fix is one parameter:
thinking: {type: "adaptive", display: "summarized"}
That gives you a readable summary of the reasoning. Note the field name on the block is still thinking — don't go renaming your response handler, the data's just empty unless you opt in. And the raw chain of thought is never returned on these models regardless; summarized is as much as you get.
Task budgets: the new way to cap a whole loop
There's one more lever, beta, for agentic loops: task_budget. This is not the old budget_tokens back from the dead — it's different. A task budget tells the model how many tokens it has for an entire agentic loop (thinking plus tool calls plus output), and the model sees a running countdown and paces itself to finish gracefully instead of getting cut off:
output_config: {effort: "high", task_budget: {type: "tokens", total: 64000}}
It requires the beta header task-budgets-2026-03-13, the minimum is 20,000 tokens, and you should stream because the large max_tokens would otherwise risk a timeout. The key distinction: max_tokens is a hard, enforced, per-response ceiling the model doesn't know about. task_budget is a soft, cumulative, whole-loop suggestion the model does know about and plans against. Use task_budget to make the model self-moderate; use max_tokens as the hard backstop.
How I actually set these now
For a chat or classification endpoint: adaptive off or thinking: {type: "disabled"} where supported, effort: "low", small max_tokens. Cheap and fast.
For a coding agent: thinking: {type: "adaptive"}, effort: "xhigh", generous streaming max_tokens, and a task_budget if it's a long autonomous loop.
For a one-shot hard reasoning task where I care about being right: adaptive on, effort: "high" and test max, display: "summarized" so I can audit how it got there.
The mental model that makes all of this click: adaptive thinking is when and how much to reason, effort is how hard to work overall, task budget is how much to spend across the whole job. Three knobs, three questions. Stop guessing token allowances and let the model do what it's now good at — deciding for itself.