Output Handling

Output Handling accounts for 2.6% of the blueprint, one or two scored questions, and it has the best facts-per-minute ratio in its domain because nearly every point is a precise, checkable mechanic rather than a judgement call.

The subject is the seam between a model response and the code consuming it, and that seam has three parts. Getting the response into a shape your code expects. Reading it correctly once it arrives. Behaving sensibly when the shape does not hold. The middle part is where working developers are most often caught out: a response body is a list of typed content blocks rather than a string, and assuming the answer is the first block is a bug waiting for the day somebody enables reasoning or the model decides to call a tool.

The third part is what the exam presses hardest. Constraining a format removes the ordinary failure and leaves the extraordinary ones, and each carries a distinct signal. A generation that ran out of room, a request that was declined, a turn that ended because a tool is wanted: your parser should never see any of them, because a branch upstream should already have decided what happens next.

Learn the block structure and the stop signals and this becomes free marks.

What the exam tests here

• •Reading a response as an ordered list of typed blocks rather than as a single string
• •Branching on the stop signal before any parsing or downstream effect happens
• •Assembling a streamed response, including tool arguments that arrive as fragments of JSON
• •Separating schema conformance from semantic correctness during validation
• •Recovering from a generation that stopped short without repeating side effects

A response is a list of blocks

Content comes back as an ordered array of typed blocks. Text is one type, a tool request is another, and on a reasoning-enabled request the model's deliberation arrives in its own block type ahead of the answer. Any of these can be absent, and more than one text block can appear in a single response.

So indexing into the first element and reading its text is fragile in a specific, delayed way: it works throughout development and breaks the day reasoning is switched on or a tool is chosen, because position zero is no longer the answer. Filter by block type and join the text blocks you actually want. The same discipline applies when appending the assistant turn back into the conversation, where the whole list must be preserved rather than flattened.

Branch on the stop signal, then parse

Every response carries a reason it stopped, and each value implies a different next action. A normal completion is the only one where handing the body to a parser is correct. A generation that hit its ceiling is truncated and its JSON will not close. A turn that paused to call a tool has no final answer yet and belongs back in the loop. A declined request returns successfully with little or nothing usable, and no exception handler will catch it because nothing was thrown.

Structure the consuming code accordingly: read the stop signal, dispatch on it, and let only the completed case reach the parser. Code that wraps everything in a try block instead conflates truncation, refusal and genuinely malformed output into one path and applies the same retry to all three.

Streaming changes assembly, not semantics

A streamed response arrives as a sequence of events: blocks opening, deltas appending to them, blocks closing, and a final event carrying the stop reason together with the token usage. Nothing is complete until its block closes, and one consequence catches people out.

Tool arguments stream as fragments of JSON text, appended piece by piece, so a fragment is not parseable on its own and a parser run per delta fails on every one of them. Accumulate first, decode once. The final event is also where the stop reason lives, which means a client that stops listening the moment it has enough text to display has discarded exactly the field it needs to decide whether the answer was finished.

Valid is not correct

A schema guarantees structure and says nothing about truth. A response can satisfy every constraint you wrote while containing an invented order number, a date outside the range its source supports, or a total that does not match its own line items. Constrained generation moves the failure from parse errors to plausible-looking wrong values, which is a better place for it and not the end of the work.

Keep a semantic layer behind the structural one: check identifiers against the systems that own them, compute arithmetic in code rather than trusting a generated total, and confirm that quoted material appears in the source. This is also why enumerations and required fields earn their keep, each converting a class of semantic error into a structural one you can catch mechanically.

Where candidates go wrong

Common questions