Token bounds for the text workflow profile

The envelope

These bounds apply to one unit of work, not to a job or a batch. Your workflow descriptor names the profile each of its units runs under, and a different profile has different numbers.

Usable budget

The envelope is the ceiling. Your item never gets all of it, because fixed content is charged against the same budget.

input_usable  = 9,600 - fixed_input_blocks - required_context_overlap
output_usable = 1,200 - fixed_output_framing
items_per_unit <= min(input_fit, output_fit, resource_fit, workflow_bound)

The last line is why item count is bounded by whichever constraint binds first. A generous input budget does not raise the item count when output density is the limit.

What consumes the input budget

• Fixed instruction blocks the workflow always sends.
• The output schema you declared.
• Your rubric, when a custom evaluation preset is active.
• Required context overlap, where the workflow needs neighboring content for continuity.
• Your item's own content, from whatever remains.

Every one of those competes for the same 9,600 tokens. Narrowing your schema or shortening your rubric returns budget directly to your content.

What limits output

output_usable covers everything the unit returns for the items in it. Output density therefore decides how many items fit into one unit.

An unbounded array or string is the usual cause of a poor fit. A single unbounded field can push one item past the output bound while its input still fits comfortably.

Bound every array with a maximum item count, and every string with a maximum length. Bounded output is predictable output.

When an item does not fit

Four outcomes are possible, and the workflow declares which apply to it:

1. Registered deterministic sectioning. The item is divided the same way every time, and the sections are recombined exactly as declared.
2. A declared preprocessing stage. A released stage reduces the item before the work runs.
3. An approved larger profile. Available only where one is approved for your account and that workflow.
4. A typed refusal. The request refuses with a safe reason and a concrete next action.

Four things never happen, in any of those paths:

• Required evidence is never truncated silently.
• Schema or rubric instructions are never dropped to make room.
• The model is never changed to make an item fit.
• A continuation is never invented for content that did not fit.

That list is the point of the bounds. An over-limit item produces a refusal you can act on, never a quietly shortened answer that looks complete.

What this profile is not

It is not a general chat service. There is no free-form context window to fill and no session that carries context between units.

You do not select a model, and no request can change one. Each unit is bounded, declared and independent of every other unit in the run.

Check your fit before you quote

Measure your largest item, not your average one. Add the token cost of your declared schema and your rubric, then compare the total against input_usable.

lithi inspect
lithi dataset validate

Both run locally and send nothing. Your quote then repeats the bounds that apply and states the maximum charge, and approval remains a separate act after you read it.

To reduce what your schema costs, see narrowing an output schema. For the wider set of published bounds, see limits.