Compute
Compute limits
The nine kinds of limit that bound a Compute request, where each current value is published, the text-profile token envelope, and the four capacity refusals you must never collapse.
Nine kinds of limit
Limits are not one number. Nine different kinds apply, and each is published by a different authority.
| Kind | What it bounds | Where the current value is published |
|---|---|---|
| Request body | The size of one submitted request | That operation's entry in the API description |
| Artifact | The size and count of files one job references | The workflow descriptor, repeated on your quote |
| Item | The size of one logical item | The workflow descriptor |
| Batch | The number of items in one batch | The workflow descriptor, repeated on your quote |
| Token | Input, output and combined context | The model profile bound, shown below |
| Concurrency | How many jobs you may run at once | Developer settings in the portal |
| Rate | How often you may call an operation | That operation's entry in the API description |
| Budget | What you may spend before approval is required | Your spend and approval settings |
| Retention | How long a bundle stays downloadable | That bundle's result-manifest.json |
There is no universal ceiling to code against. Read the descriptor for the workflow you actually use.
Batch and item ceilings are per workflow
The maximum item count for a workflow is stated on its descriptor and repeated on your quote. It is not a platform constant, and it differs between workflows.
Any scale figure you see in an architecture or test context is a target for Lithi's own testing. It is not your capacity.
Token bounds on the released text profile
input_tokens <= 9,600
output_tokens <= 1,200
combined_context <= 10,800
input_usable = 9,600 - fixed_input_blocks - required_context_overlap
output_usable = 1,200 - fixed_output_framing
Fixed framing and any required context overlap come out of those ceilings first. What is left is what your content can use.
How many items are grouped into one unit of work is bounded four ways. The input fit, the output fit, the resource fit and the workflow's own bound all apply, and the smallest wins.
When one item does not fit
Four responses are permitted, and only four.
- A registered deterministic sectioning strategy splits the item the same way every time.
- A declared preprocessing stage reduces the item before the work runs.
- An approved larger profile carries it.
- A typed refusal tells you it does not fit, with a next action.
Required evidence is never truncated. Schema and rubric instructions are never removed. The model is never swapped, and a continuation is never invented to make an item fit.
Concurrency, rate and budget refusals
Four refusal classes exist and are deliberately distinct. No retry policy may collapse them into one rate-limit state, because the correct response differs.
EDGE_ABUSE_LIMITED— perimeter load shedding. Back off, then retry the same request.CANONICAL_ADMISSION_LIMITED— your key or account's request authority is exhausted. Lower concurrency, or raise the limit in the portal.CANONICAL_BUDGET_EXHAUSTED— spend or reservation authority is exhausted. Approve more spend, then resubmit.CELL_CAPACITY_UNAVAILABLE— current capacity is unavailable. Retry, or extend the deadline inlimits.
Treating all four as "slow down" leaves a budget refusal retrying forever against a limit that only an approval can lift.
What a breach returns
A limit breach is refused at submission. It is never truncated at execution, so you never receive a quietly shortened result.
Every non-success carries a safe reason and a non-empty next action. Read the next action first, then see the refusal vocabulary for the code you received.