A JSON schema written out in English
Describing your output shape in prose costs more than declaring it, and works less well.
Every major provider now supports constrained output: a JSON schema attached to the request, or a tool definition the model is forced to call. When you use one, the format is enforced by the decoder rather than requested politely in the prompt.
Prompts written before that existed still carry two hundred tokens of "the response must be a JSON object with a key called summary whose value is a string of at most three sentences, and a key called priority whose value is one of low, medium or high". That paragraph is doing a job the schema field does better.
You keep paying for it twice: once for the description, and again for the retry when the model emits prose around the JSON anyway. Constrained decoding removes the second cost entirely.
Move the shape into the schema and leave only the semantics in the prompt — what "priority" means for your domain is worth explaining; what type it is, is not.
Respond with valid JSON containing a "summary" key (string, max 3 sentences) and a "priority" key which must be exactly one of "low", "medium", or "high". Do not include markdown fences...Set priority by customer impact, not by how upset the message sounds.
(shape moved to a response schema)Check your own prompt
The analyser checks this pattern along with the other 25, prices each finding against your request volume, and hands back a rewritten prompt. It runs in your browser — nothing is uploaded.
Run the analyserMore on tools & schemas
- JSON indented for a human readerPretty-printing JSON in a prompt adds 20-30% tokens for whitespace nobody reads.
- What your tools cost before anyone calls oneTool schemas are re-sent on every request, plus a provider system prompt you never see.
- Tool schemas carrying dead weightLong descriptions, JSON Schema boilerplate, and enums with a hundred values.