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:
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.
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?
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.
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." }]
}
The thinking API that now errors
This one is a genuine breaking change, which is why it is such good exam material.