Design Output Schemas That Stop Wasting Tokens

When you ask a model for structured output, you pay for the structure — on every single call. A verbose schema is not just harder to read; it is more output tokens per response, multiplied across every request your product makes. At scale, the schema is a line item.

Where the tokens leak

Three habits quietly inflate every structured response:

• Long field names. "identifier" versus "id" is 4 tokens versus 1 — per field, per call. Across 100k calls with 8 fields, that is millions of tokens of pure formatting.

• Free-text where an enum belongs. A "sentiment" string can come back “very positive”, “mostly positive”, “kinda happy” — three spellings of one idea. An enum forces one of a fixed set: cheaper, parseable, no fuzzy matching downstream.

• No additionalProperties: false. Without it the model can invent fields nobody asked for — extra tokens you pay for and then have to ignore.

What the designer does

The Output Schema Designer takes a plain-English description of the output you want and returns a strict JSON Schema (draft 2020-12): short keys, enums where the value space is closed, capped arrays, and additionalProperties: false — ready to paste into your SDK call. It validates the structure so you are not shipping a schema that quietly fails.

See a worked example below ↓

When to run it

Reach for it any time you are about to wire a new structured-output call, and revisit your highest-volume existing calls — those are where a tighter schema compounds fastest. Descriptions inside the schema are free hints to the model, so a well-designed schema improves compliance and cost at the same time.

Tighten the schema, every call gets cheaper

You can design a schema from your own description in the tool. And if you would rather have token discipline built into your product instead of done by hand, tell us what you are building and we will scope it.