Forcing an output format that holds
The phrasings that actually constrain output, and the ones people use that do not. Tested by asking for the same thing twenty times and counting the failures.
Tested on Claude Sonnet · 4.5 ·
| Command | What it does | Worth knowing |
|---|---|---|
Reply with a single JSON object and nothing else. |
Reliable JSON on every model tested | The words "nothing else" are what stops the explanation appearing before it |
Return JSON matching this schema: {...} |
Reliable structure and key names | Paste a filled-in example, not a type description - it works better |
Reply with a Markdown table and no text before or after it. |
Reliable table | Without "no text before or after" you get an introductory sentence roughly half the time |
Answer in at most three sentences. |
Works | A sentence count holds far better than a word count, which models estimate badly |
Be brief. |
Fails | It produces a shorter preamble, not a shorter answer |
Output only the code, no explanation, no comments. |
Works | Drop "no comments" if you want inline comments kept |
Reply with a mermaid flowchart in a code block. |
Works, syntax is usually valid | Name the diagram type. Just saying "a diagram" gets you ASCII art |
If you cannot answer in this format, say FORMAT_FAILED and nothing else. |
Turns a silent format break into a detectable one | The single most useful line here if you are parsing the output in code |
Format instructions fail silently: you get the right shape four times and prose on the fifth, usually in the longest and most important response.
Notes from the author
That last row is the one worth stealing. A parser that sees FORMAT_FAILED can retry; a parser that gets a friendly paragraph where JSON should be throws an exception at three in the morning.
Tagged