Picking a model, effort, and thinking
Model choice is not a vibe. On this paper it is a constraints question, and there is exactly one model on the current list that is disqualified by a capability rather than by price.
The lineup
The current 5-family models are claude-opus-5, claude-sonnet-5 and claude-fable-5, documented at 1M context and 128k output.
Then there is claude-haiku-4-5-20251001: 200k context, 64k output, and no adaptive thinking.
Model ids and limits move faster than any exam guide. Learn the shape of the constraint rather than trying to memorise a table that will be stale by the time you sit.
Adaptive thinking and effort
Adaptive thinking is GA. So is output_config.effort, and its default is high.
Think of effort as a compiler optimisation level you forgot you set, except the direction is inverted: you did not opt into the expensive setting, you inherited it. High effort is the deep-and-careful end, and it is what you get if you never touch the field.
In a one-shot call that is completely fine. In an agent loop, you are paying it on every turn, including the turns that are just “call the tool I already decided on three steps ago”. Twenty turns is twenty helpings of maximum effort, most of them spent on decisions that were never hard. If your loop is slower and pricier than your arithmetic said it should be, effort is the first place to look, not the last.
The migration that fails loudly
The old extended-thinking shape looked like this:
{
"thinking": { "type": "enabled", "budget_tokens": 8000 }
}On 4.7 and newer models that returns a 400. Not deprecated, not warned, not quietly ignored. Rejected.
Loud failure is the good outcome here. A silently-ignored thinking parameter would mean an agent that quietly stopped reasoning while all your integration tests stayed green, and you would find out from a user. When you see thinking.type and budget_tokens in a code sample, you are looking at pre-4.7 code, and that is a useful dating tool when you inherit a repo.
How to answer a model-choice question
Work the constraints in this order, because it is the order the marks fall in.
Capability first. Does it need adaptive thinking? That is the only question that can eliminate a model outright.
Limits second. How much context are you actually feeding it, and how long is the output? 1M against 200k is a real difference for a loop that accumulates tool results forever, and tool results accumulate faster than people expect.
Cost and latency last. They are the loudest considerations in real life and the least likely to be the answer on an exam question, because they are the ones with no crisp right answer.
Try it yourself
The Haiku constraint
You are picking a cheap fast model for a long-running agent loop that needs to reason carefully at each step about which tool to call next.
Show answer
Correct answer: C — Not claude-haiku-4-5-20251001, because it does not support adaptive thinking
claude-haiku-4-5-20251001 has no adaptive thinking, and that is a hard model capability, not a parameter you can switch on. The latency answer is the trap: it is the right instinct for a cheap model and completely wrong here, because the requirement said careful reasoning at each step. The context answer is wrong for a different reason: 200k is genuinely fine for plenty of loops, so context is not what rules it out.
What effort defaults to
A one-fact card, and exactly the shape of thing a timed exam likes.
What is the default value of output_config.effort, and what are you trading when you change it?
Reveal answer
The default is high. Effort is GA alongside adaptive thinking. Lowering it trades reasoning depth for speed and token spend, so the default is the expensive-and-careful end, which means an unexamined agent loop is already paying for maximum effort on every single turn.
The two limit pairs
Four numbers across two rows. A timed paper likes these because they are quotable back at you with one digit changed.
Give the documented context and output limits for the 5-family models, then for claude-haiku-4-5-20251001.
Reveal answer
The 5-family models, claude-opus-5, claude-sonnet-5 and claude-fable-5, are documented at 1M context and 128k output. claude-haiku-4-5-20251001 is 200k context and 64k output, and separately it has no adaptive thinking. Ids and limits move faster than any exam guide, so the durable thing to carry is the shape rather than the digits: a current family with a very large window, and an older cheap model with a much smaller one plus a hard capability gap.
Spot what fails
This request body ships against a current model. One field in it makes the call fail outright.
{
"model": "claude-sonnet-5",
"max_tokens": 4096,
"thinking": { "type": "enabled", "budget_tokens": 8000 },
"output_config": { "effort": "low" },
"messages": [{ "role": "user", "content": "Plan the migration." }]
}Show answer
Correct answer: B — The thinking block is the legacy shape and returns a 400 on 4.7 and newer models
The legacy extended-thinking shape, thinking.type set to enabled plus budget_tokens, returns a 400 on 4.7 and newer models. The nothing-is-wrong answer is the designed trap, because output_config.effort really is the current field and really is set legitimately, and a single modern-looking field is enough to make a whole request body read as up to date at speed. Effort defaults to high but low is a valid setting, and a max_tokens well below the ceiling is a normal choice rather than an error.
The thinking API that now errors
This one is a genuine breaking change, which is why it is such good exam material.
Show answer
Correct answer: B — It returns a 400 on 4.7 and newer models
The old extended-thinking shape, thinking.type set to enabled plus budget_tokens, returns a 400 on 4.7 and newer. The silently-ignored answer is the tempting one because that is how APIs usually retire a field, gracefully, and because a silent no-op would be the kinder migration. It is not what happens: the request fails outright, which is actually better, because a silent downgrade is a bug you find in production.