Structured outputs, effort and streaming
Output handling is 2.6% of the exam, which is small, but it is dense with exactly the kind of fact that multiple choice loves: field names, defaults, and availability lines.
Structured outputs are GA from 4.5
Structured outputs are generally available for Claude 4.5 and later. That is the boundary. It matters because "structured output" as a phrase has meant several different things over the last couple of years, including "prompt hard and parse hopefully" and "abuse a tool definition as a schema".
Those hand-rolled approaches still work. They are just no longer the answer, and if you have a retry loop that strips markdown fences and re-parses, that is code you are maintaining to compensate for a feature that now exists. Deleting it is a genuine win on your own systems, and it is the sort of deletion that only happens if somebody notices the boundary moved.
The field name, and the one that is on the way out
This is a naming question and it is worth being exact.
output_config.format is the current field. output_format is transitional.
The exam trap here is that the transitional name is shorter and more memorable, so it is what people recall. Reach for the nested one.
effort defaults to high
output_config.effort defaults to high, and the docs are explicit that passing high yourself behaves identically to omitting the field.
The value set is documented, so learn it rather than planning to look it up: low, medium, high, xhigh, max. Two caveats that are worth more than the list. First, xhigh is newer than max, so support is not a clean ladder: some models that accept max reject xhigh (Opus 4.6 and Sonnet 4.6 are the ones to remember; Opus 4.7 and later and Sonnet 5 take all five). Second, adaptive is a thinking mode and not an effort level, and passing it here is a documented mistake.
Now the implication, which is the part people get backwards in both directions. The default is high, so most people's instinct (turn it up for hard tasks) is usually unnecessary. But high is not the ceiling: xhigh and max sit above it, and on current models xhigh is the recommended starting point for coding and agentic work. So a request that never touches the field is not "paying for maximum effort", it is sitting one rung below the top with real headroom in both directions.
That makes the field a genuine two-way lever. Down to medium or low when the task does not need the ceiling and you want speed and cost back; up to xhigh or max when it does. The one thing that is not true is that leaving it alone is either the cheapest or the strongest option.
Streaming is GA
Streaming is generally available. Nothing exotic to say about it, which is itself the point: it is not a beta you need to gate behind a flag or a header, and treating it as experimental is out of date.
The practical note is that streaming and structured output are not in tension. You can stream a response that is constrained to a schema. What you cannot do is parse a partial JSON document as though it were complete, which is a client-side problem and always has been.
The combination that hard-fails
One thing to hold onto here and we go deeper on it next lesson: citations plus structured outputs returns a 400.
Not a degraded response. Not citations silently dropped. A rejected request.
That is worth flagging now because it is the shape of the whole next lesson. The current generation of models has moved a set of behaviours from "quietly does something reasonable" to "refuses". That is better engineering and worse for anyone whose integration was relying on the quiet reasonable thing.
Try it yourself
Which field is current
You are writing new code that asks for a JSON-shaped response. Two field names appear in material you have read. Which do you write?
The effort default
You never set output_config.effort. What value is in play?
Modernise this call site
An inherited call site, now pointing at a current model. The schema itself is fine; the code around it has two problems.
const res = await client.messages.create({
model: CURRENT_MODEL,
output_format: ticketSchema,
messages: [
{ role: "user", content: prompt },
{ role: "assistant", content: "{" },
],
})
Which change list is correct?
Where structured outputs are GA
There is a version boundary here, and the useful form of this fact is the boundary rather than a list of models. Anything that moves you across the line changes what the feature guarantees.
For which models are structured outputs generally available?
The one combination that 400s
Both features work perfectly well on their own, which is what makes this pairing worth committing to memory rather than deriving. It also previews the whole of the next lesson.
Which feature conflicts with structured outputs, and what is the failure mode?