Structured outputs and citations

You want JSON out. Historically you asked nicely, prefilled an open brace, and wrote a parser with a retry. Two of those three are now unnecessary and one of them returns 400.

Then there is the sentence that ruins somebody's architecture diagram roughly once a quarter: the two features in this lesson do not compose.

output_config.format is the current spelling

Structured outputs is GA for Claude 4.5 and later, no beta header. You declare the shape you want and the response conforms to it.

The field is output_config.format. You will also encounter output_format, which is transitional: it exists, it turns up in older examples, and it is not what you should write in new code. Note the precise claim there, because the difference matters and the exam knows it. Transitional means superseded and still working. It does not mean removed, and it does not mean 400.

This is the proper replacement for last-turn assistant prefill. Prefill forced a format by exploiting completion behaviour and gave you no guarantee. Structured outputs is a declared contract. And since prefill on the final assistant turn now returns 400 on Claude 4.6 and later, the migration is not optional for anyone on a current model.

Citations

Citations is also GA. It makes the model attribute claims back to spans in the documents you supplied, rather than asserting things and leaving you to trust it.

The design value is specific: an unattributed answer and a hallucinated answer look identical. Citations turn that into something checkable. If your requirements say anything about verifiability, provenance, or "the user must be able to see where this came from", citations is the feature the question is fishing for.

The combination that returns 400

The design answers, if you hit this in real life:

Split the call. One request with citations to gather and attribute, a second cheap call to reshape the result into your schema. Two calls, more tokens, but both halves work.

Drop the schema and parse. Take citations, accept prose, and extract afterwards. You lose the guarantee.

Drop citations and carry provenance yourself. Keep the schema, add a field for source ids, and instruct the model to fill it. You lose the real attribution and gain a field the model can be wrong about, which is worse than it looks: a provenance field the model populates has the shape of evidence without the substance of it, and reviewers will trust it exactly as if it were real.

There is no fourth option where both work, and a question offering you one is offering you the distractor. Notice the failure direction though: 400 is loud. You find this in development, not in a customer's hands, which is the difference between an annoying constraint and an incident.

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "output_format": { "type": "json_schema", "schema": { "type": "object" } },
  "messages": []
}

{
  "model": "claude-sonnet-5",
  "max_tokens": 1024,
  "output_config": { "format": { "type": "json_schema", "schema": { "type": "object" } } },
  "messages": []
}