Model tier isn't the only optimisation lever — within a single model, the effort parameter, adaptive extended thinking, and (on some models) a task budget all let you tune how much work the model puts into a response, trading cost and latency against thoroughness on a per-request basis rather than a per-deployment one. A high-autonomy coding task genuinely benefits from more effort; a short, well-scoped extraction task doesn't need it and pays only the cost. On current models (Fable 5, Opus 5, Sonnet 5), the older fixed budget_tokens approach to controlling thinking has been removed — effort and adaptive thinking are the current mechanism.
Three different knobs, not one
Effort (output_config: {effort: "low"|"medium"|"high"|"xhigh"|"max"}) scales thinking depth and tool-call behaviour together — lower effort means fewer, more-consolidated tool calls and terser output, not just shorter reasoning. Adaptive thinking (thinking: {type: "adaptive"}) controls whether the model reasons step-by-step before answering at all; on current models it's the only supported "on" mode, replacing the older fixed-budget approach. A task budget (beta, on select models) is a separate, higher-level control: it gives the model a token ceiling for an entire agentic loop so it paces itself across many turns and finishes gracefully, rather than being cut off mid-task. These three are independent — you can raise effort while keeping a tight task budget, or vice versa.
Sweeping effort correctly
Effort should be swept against an evaluation set, one setting at a time, keeping every other request field byte-identical — including the prompt itself, since changing effort mid-conversation invalidates the prompt cache for that conversation going forward. How much effort actually buys varies sharply by workload shape: on research and knowledge-style tasks the accuracy curve tends to be nearly flat, so a lower effort level often captures most of the accuracy at a fraction of the cost. On long-horizon coding and agentic work, effort is a genuine trade-off — dropping from the default to a lower setting can give up real accuracy in exchange for real savings. On tasks that sit right at a model's reasoning ceiling, every additional step of effort can keep buying measurable quality, with no obviously "free" cut available. The exam expects you to know that this curve has to be measured per workload, not assumed.
Exam trap: disabling thinking instead of lowering effort
On Opus 5, thinking is on by default and can be explicitly disabled only at effort high or below. Doing this to save cost has a real failure mode: with thinking disabled, the model can occasionally write what should be a tool call into its visible text instead of a proper tool_use block — the turn completes successfully, the intended tool call never actually runs, no error is raised, and in an agentic loop that stray text can pollute later turns. Lowering effort instead of disabling thinking achieves a similar cost reduction without this failure mode.
Re-running failures at higher effort
When a workload has a usable pass/fail signal — tests, a validator, a checker — one of the most effective effort strategies isn't picking a single setting at all: run everything at a low effort level first, and only re-run the cases that failed at a higher setting. Because most requests succeed on the first, cheap attempt, and only the harder tail needs the expensive retry, this pattern captures most of the accuracy of always running at the higher setting while paying the higher cost only where it's actually needed. It trades the saving for extra wall-clock time on the failed cases (since those pay for two attempts, not one) and it depends entirely on having a cheap, reliable way to detect failure — without that signal, this strategy can't tell a real failure from a plausible-looking wrong answer, and shouldn't be used.
Task budgets vs. max_tokens
These are easy to conflate but solve different problems. max_tokens is an enforced per-response ceiling — the model has no awareness of it, and hitting it truncates output abruptly. A task budget is advisory and token-denominated: the server injects a countdown the model can see during generation, so it paces its own work across a whole agentic loop and tries to land within the ceiling rather than being cut off. Task budgets have a floor (a minimum total of 20,000 tokens) and are set once at the start of a task — changing the budget mid-task, like changing effort mid-conversation, invalidates the cache. A generous budget gives up little accuracy for a modest saving; a very tight budget can meaningfully hurt pass rate and, in the extreme, produce refusal-like behaviour as the model runs out of room to work.
Key concept
Think of tier as "which model," effort as "how hard that model tries on this request," and task budget as "how much room it's given to try across an entire loop" — three separable decisions, not one.