Sume output_schema limits: depth 10, 5000 properties, 120,000 chars

Sume's output_schema caps nesting at 10 levels, 5000 properties, 1000 enum values and 120,000 characters of strings. See which rule fires and how to shrink.

5 min readSume
All posts

A Sume Format output_schema has four size limits: 10 levels of nesting, 5000 properties across the whole document, 1000 values in any one enum, and 120,000 characters of strings summed over the document. Crossing one returns 400 output_schema_invalid with the rule max_depth, max_properties, max_enum_values or max_string_length.

Most schemas never get near these numbers. The one that surprises people is the last: it is a document-wide budget, not a per-field cap, so long description text on a large schema can spend it even when no single string looks big.

What are the exact limits?

The numbers come from the structured output page. Each limit has its own rule token, so the violations[] array tells you which one you crossed. Nothing runs when one fires, so nothing is charged.

The budgets count differently, which is worth knowing before you shrink anything. Properties are counted across the whole document, not per object. String length sums every property name, key and string value, so it grows with annotations as well as data.

output_schema size limits, read 2026-10-02
LimitValueRule token
Nesting depth10 levelsmax_depth
Total properties5000, whole documentmax_properties
Enum values1000 per enummax_enum_values
Total string length120,000 charactersmax_string_length

Why do long descriptions break a small schema?

Because description, title and examples are annotations, and annotations are strings. The 120,000-character budget sums every property name, key and string value, so a schema with thousands of properties and a paragraph on each can cross it without any one field being unusual.

Descriptions help the run fill a field correctly, so do not strip them blindly. Cut the repeated ones first: if forty scene fields carry the same sentence, define the scene once in $defs and reference it.

Does recursion use up the depth limit?

Not through a named definition. A $defs entry may $ref itself, and the depth limit counts literal nesting in the document, so a self-referential definition does not consume it. Root recursion with $ref: "#" is rejected, which is a separate rule; recurse through #/$defs/* instead.

That makes $defs the main tool for staying under the property and string budgets as well: define a shape once and reference it, rather than pasting it ten times.

How do I check a schema locally before submitting?

The sample reads a schema file and prints the two budgets it can measure cheaply: total string length and the number of declared properties. It is an approximation of the server's count, so treat a result near a limit as a prompt to test against the API, not as proof.

A schema that is close to 5000 properties is usually modelling the wrong thing. The run only needs to report what your system will store.

import json, sys

def walk(node, acc):
    if isinstance(node, dict):
        for k, v in node.items():
            acc["chars"] += len(k)
            if k == "properties" and isinstance(v, dict):
                acc["props"] += len(v)
            walk(v, acc)
    elif isinstance(node, list):
        for v in node:
            walk(v, acc)
    elif isinstance(node, str):
        acc["chars"] += len(node)

schema = json.load(open(sys.argv[1]))
acc = {"chars": 0, "props": 0}
walk(schema, acc)
print(acc, "of 120000 chars, 5000 properties")

Sources

Related posts

More in Formats

All Formats posts

Written by Sume