OpenAI vs Anthropic Structured Outputs: Strict-Mode Schema Rules

Short Answer

Structured outputs constrain a model to emit JSON that conforms exactly to a JSON Schema. OpenAI does this with a strict json_schema response format (and strict: true on tools) — now the production default; JSON mode is legacy. Anthropic does it with Structured Outputs and strict tool use, generally available in 2026 (the old structured-outputs-2025-11-13 beta header is no longer required). Both accept only a subset of JSON Schema, and the two subsets differ:

• Shared by both: every object must set additionalProperties: false, and every property must effectively be declared. Optional fields are expressed as nullable ("type": ["string", "null"]), not by omission.
• OpenAI is permissive but silent: it accepts range/pattern keywords like minimum, maximum, and pattern but does not enforce them. Root anyOf is forbidden; max nesting is 5 levels.
• Anthropic is strict and loud: it rejects minimum, maximum, multipleOf, minLength, and maxLength with an API error. It has no recursive schemas, and caps tools and parameters per request.

The portable move is to write to the intersection: declare every property, mark optionals nullable, set additionalProperties: false everywhere, and do all value-range and pattern validation in your own code after the call. Confirm specifics against the official docs — both providers iterate on these rules.

Side by Side

The rule sets at a glance. Where they disagree is exactly where schemas break.

Structured Outputs vs JSON Mode vs Tool Calling

Three related features get conflated constantly. They are not the same thing:

• JSON mode guarantees the response is valid JSON — but not a specific shape. The model could return {}, an array, or any keys at all. On OpenAI this is the legacy mechanism, superseded by structured outputs.
• Structured outputs guarantee the response matches your exact JSON Schema — the right keys, types, enums, and nesting. This is what you reach for when downstream code depends on the shape.
• Function / tool calling is the model deciding to call a tool and producing arguments for it. With strict tool use, those arguments are constrained by the same JSON Schema rules described here — so a tool''s parameters schema must obey the strict-mode subset, exactly like a response schema.

In short: JSON mode is "valid JSON," structured outputs is "this schema," and strict tool calling applies "this schema" to a tool''s arguments. The schema rules in this guide govern the latter two on both providers.

The Shared Rules

Start with what both providers demand, because most of a portable schema lives here. Two rules dominate:

1. Every object must set additionalProperties: false. No exceptions, at every level of nesting.
2. Every property must effectively be declared, and optionality is expressed by making a field nullable — not by leaving it out of required.

OpenAI states this directly: list every property in required, and to make one optional, add "null" to its type. Anthropic arrives at the same place from the other direction — it treats every non-nullable property as required, so a nullable type is exactly how you opt a field out of being mandatory. The upshot is one shared idiom:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "title":    { "type": "string" },
    "priority": { "type": "string", "enum": ["low", "medium", "high"] },
    "assignee": { "type": ["string", "null"] },
    "due_date": { "type": ["string", "null"] }
  },
  "required": ["title", "priority", "assignee", "due_date"]
}

Here title and priority are genuinely required; assignee and due_date are "optional," expressed as nullable unions and still listed in required. This object validates against both providers'' strict modes.

OpenAI''s Rules

OpenAI''s strict mode is structurally rigid but value-permissive. The structural rules it enforces:

• All properties in required. Mark a field optional by making it nullable ("type": ["string", "null"]).
• additionalProperties: false on every object.
• Root cannot be anyOf. The top level must be an object. anyOf is fine on nested properties.
• Max nesting depth of 5 levels. Deeper schemas are rejected.
• $defs supported for shared/internal definitions.
• Types limited to string, number, integer, boolean, array, object, null.

The trap is value constraints. OpenAI accepts pattern, format, minLength, maxLength, minimum, maximum, and multipleOf — but silently ignores them. They make your schema look validated when it isn''t. A schema like this compiles fine and enforces none of the numeric or string bounds:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "quantity": { "type": "integer", "minimum": 1, "maximum": 100 },
    "sku":      { "type": "string", "pattern": "^[A-Z]{3}-[0-9]{4}$" }
  },
  "required": ["quantity", "sku"]
}

The model is constrained to emit an integer and a string, but nothing stops quantity: 999 or a malformed sku. If those bounds matter, enforce them in your own code after the call.

Anthropic''s Rules

Anthropic''s structured outputs are the mirror image: it rejects what OpenAI ignores, so unsupported keywords surface loudly as API errors rather than quietly doing nothing.

• Rejected outright (API error): minimum, maximum, multipleOf, minLength, maxLength.
• minItems may only be 0 or 1 — any other value is rejected.
• pattern is supported, but cannot use backreferences, lookahead/lookbehind, or \b.
• No recursive schemas and no external $ref — only internal #/$defs references.
• Per-request hard limits: at most 20 strict tools, at most 24 optional parameters, at most 16 union-typed parameters.
• Required properties are reordered before optional ones in the schema the API uses.

So the OpenAI example above fails on Anthropic — minimum and maximum trigger an error. The Anthropic-safe version drops them and keeps a backreference-free pattern:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "quantity": { "type": "integer" },
    "sku":      { "type": "string", "pattern": "^[A-Z]{3}-[0-9]{4}$" }
  },
  "required": ["quantity", "sku"]
}

The quantity bounds now live in your application code. The pattern is allowed because it uses no backreferences or lookaround — but remember it is only enforced on Anthropic, since OpenAI ignores pattern entirely.

One Schema That Passes Both

Write to the intersection of the two subsets and you get a schema you can send to either provider unchanged. The portable rules:

• Make the root an object (never anyOf at the root — OpenAI forbids it).
• Set additionalProperties: false on every object.
• List every property in required; express optional as nullable (["T", "null"]).
• Drop all numeric and length keywords — minimum, maximum, multipleOf, minLength, maxLength (Anthropic rejects them, OpenAI ignores them, so they buy you nothing portable).
• Use pattern only if it has no backreferences, lookahead/lookbehind, or \b — and treat it as advisory, since OpenAI won''t enforce it.
• Keep nesting at or under 5 levels and use only internal $defs (no recursion, no external $ref).
• Keep minItems at 0 or 1 if you use it at all.

A portable schema for an extracted support ticket:

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "subject":  { "type": "string" },
    "category": {
      "type": "string",
      "enum": ["billing", "bug", "feature_request", "other"]
    },
    "priority": {
      "type": "string",
      "enum": ["low", "medium", "high"]
    },
    "tags": {
      "type": "array",
      "items": { "type": "string" }
    },
    "assignee": { "type": ["string", "null"] }
  },
  "required": ["subject", "category", "priority", "tags", "assignee"]
}

Every value constraint that matters here is expressed through enum and type, which both providers enforce. The "optional" assignee is nullable. There are no range keywords to trip Anthropic and nothing for OpenAI to silently ignore. This schema is safe to send to either API as-is.

Common Rejection Causes

When a schema that "looks fine" gets rejected — or quietly under-validates — it is almost always one of these:

• A missing additionalProperties: false on a nested object. Both providers want it on every object, not just the root.
• A property left out of required on the assumption that omission makes it optional. It doesn''t — use a nullable type instead.
• minimum / maximum / minLength / maxLength sent to Anthropic. These are hard rejections, not warnings.
• Expecting OpenAI to enforce pattern or minimum. No error, but no enforcement either — a silent correctness bug.
• A root anyOf on OpenAI. Wrap the union in an object property instead.
• Nesting deeper than 5 levels on OpenAI. Flatten the schema.
• Recursive or external $ref on Anthropic. Inline the definition or restructure to internal #/$defs only.
• More than 20 strict tools, 24 optional params, or 16 union params on Anthropic. Split the request or reduce the surface.
• A pattern using \b, lookahead, lookbehind, or backreferences on Anthropic. Rewrite it without those constructs.

The painful part is timing: both providers validate at request time, so these surface as opaque API errors — or, on OpenAI, as constraints that just never fire — after you''ve built and shipped the integration. Catch them before the API does.

Validate Before You Ship

The whole class of failure above is avoidable by checking the schema locally before it ever hits an API call. The workflow that prevents the late-night rejection:

1. Generate or write the schema targeting the portable subset (object root, additionalProperties: false everywhere, nullable optionals, no range keywords).
2. Validate it against both providers'' strict-mode rules locally — checking for a root anyOf, missing additionalProperties, properties absent from required, rejected keywords, illegal regex constructs, and nesting depth.
3. Only then wire it into the API call. A schema that passes the local check passes the provider''s check.

Because both providers iterate on these rules, re-confirm anything that breaks against the current OpenAI and Anthropic documentation — the strict-mode subset is a moving target, and a keyword that''s ignored today may be enforced (or rejected) tomorrow.