OpenAI structured outputs: 5000 properties, 10 levels, vs Sume

OpenAI's Structured Outputs guide allows up to 5000 object properties and 10 levels of nesting in a schema. Sume's output_schema uses the same two numbers, rejecting an over-limit schema with max_properties or max_depth, but its enum and string-length limits are counted differently, so a schema that fits on OpenAI can still trip a Sume limit.

Both numbers below come from vendor pages read on 2026-10-02: OpenAI's guide and Sume's Structured output page. Where the two pages describe a limit in different words, this post quotes each rather than assuming they match.

What are the four limits on each side?

OpenAI's guide lists limits on nesting depth and size, on total string size and on enum size. Sume lists four named violations.

Where can a schema pass on one and fail on the other?

The string budget is the likeliest gap. Sume describes it as a document-wide budget rather than a per-field cap, and says long description annotations on a large schema can exhaust it even when no single string is remarkable. OpenAI's wording lists names and enum and const values, not descriptions, so a schema with heavy descriptions is worth measuring before you assume it ports.

The enum limit reads differently too: OpenAI's is a total across all enum properties, Sume's is per enum. Count your enums against both before you port a large classifier schema.

Does a self-referencing definition use up the depth?

On Sume, no. The page says the depth limit counts literal nesting in the document, so a $defs entry that refers to itself does not consume it. Recursion must go through a named #/$defs/* target; $ref: "#" is rejected.

How do I find out which limit I hit?

Send the schema. A rejected output_schema returns 400 output_schema_invalid with details.violations[], and every problem is listed, not only the first. Each entry has a path, a stable rule such as max_depth, and a message. Nothing runs and nothing is charged.

If the schema is large because the object is large, split it: have the run fill a smaller object and keep the rest of your record on your own side, keyed by the run id.