What does strict mode on a tool schema guarantee, and what does it cost?

## What the mode is Without strict mode, a tool's parameter schema is strong guidance. The model has read it, usually honours it, and occasionally does not — a missing required key, a number rendered as a string, an extra field it thought would be helpful. Your code parses, validates, and either repairs or hands the failure back. Strict mode, sold under names like strict schemas or structured outputs, changes the mechanism. The schema is compiled into a constraint over the token stream, and at each decoding step only tokens that could still lead to a valid instance are permitted. The result is not a validated output; it is an output that could not have been invalid. Free-form generation is unaffected — only the argument JSON is constrained. ## What it guarantees - **Key set.** Only declared properties can appear. With `additionalProperties: false`, an invented `notes2` alongside a declared `notes` is unreachable, not just improbable. - **Presence.** Every property the schema demands is emitted. - **Types.** A string field cannot come back as a bare number, an array cannot arrive as a comma-joined string. - **Closed vocabularies.** An `enum` becomes a hard restriction, so out-of-set category values stop appearing. - **Well-formedness.** The JSON parses, always — no truncated braces from an unlucky sample. Collectively that removes the retry-on-parse-failure branch that otherwise sits around every tool call, and removes the normalisation layer that maps eight spellings of a category to one. ## What it does not guarantee Shape is not meaning. Strict mode has no opinion on whether: - the value is true — a well-formed policy number can belong to nobody, or to a different customer; - the value came from the conversation rather than the model's imagination — a required string is filled either way; - the *right tool* was chosen — constraint applies to arguments, not selection; - cross-field logic holds — a claim dated after today, or a location inconsistent with the stated policy, passes a schema happily. So the handler still validates. Strict mode changes what your validation is for: it stops being a parser and becomes a semantics and authorisation check. Candidates who say strict mode lets them drop server-side validation are describing a security bug. ## What it costs **A restricted schema vocabulary.** Constrained decoding needs a schema it can compile, so providers accept a subset of JSON Schema. Support for validation keywords — string patterns, numeric bounds, format assertions, and the more exotic composition keywords — varies and has changed repeatedly. Anything unsupported has to move out of the schema and into your handler, or into the field's description as a natural-language instruction. **Structural demands.** A common requirement is `additionalProperties: false` on every object, plus every declared property listed in `required`. That collides with genuinely optional fields, and the standard workaround is to declare them as a nullable union type — the key is always present, and the model signals absence with an explicit null. Your handler then treats null and absent identically. It is workable, but it means "optional" is expressed differently under strict mode than without it, and a schema written for one will not simply drop into the other. **Latency and caching.** Compiling a schema into a decoding constraint is not free; the first use of a novel schema can carry noticeable extra latency, with subsequent uses served from a cache. This is invisible in steady state and very visible if you generate schemas dynamically per request, which is a good reason not to. **A small behavioural cost.** Constraining the token distribution can nudge output quality on the margin, and an over-tight schema can force the model to fabricate rather than decline — if there is no legal way to express "I don't know", the constraint guarantees it emits something. The mitigation is to design the schema so uncertainty is expressible: a nullable field, an `unknown` enum member, or a separate path for asking the user. ## When to use it Turn it on by default for tools whose arguments flow into systems where a malformed call is expensive, and for anything with a categorical field you were previously normalising by hand. It matters most where the schema is deep or the enum set large, since those are where unconstrained models drift. Relax it when you need schema features the strict subset does not accept and cannot express another way, or when the tool's arguments are tolerant free text where the retry cost is trivially low. Reflecting practice as of mid-2026: the supported subsets differ across providers and continue to move, so treat any specific list of accepted keywords as something to verify against current provider documentation rather than something to memorise.