Contract rules
Chunked planning
A planner asked for 80 fully-specified items in one model call will eventually truncate, time out, or lose everything to one network blip. Steps that produce big lists declare a repeat contract instead: bounded calls, disjoint slices, deterministic merge.
The contract
| Property | Meaning |
|---|---|
maxPerChunk | The ceiling per call. The step expands into ceil(count ÷ maxPerChunk) calls — a 6-item pack is one call, 80 items is two, 200 is five. |
mergeKey | The array the chunks produce; results concatenate in chunk order, so output ordering is deterministic. |
| slices | The plan’s motif list is partitioned round-robin across chunks. Each call owns a disjoint slice and an explicit item range — siblings cannot overlap and never read each other’s output. |
Why not just raise the caps?
When one workload trips two unrelated ceilings — output tokens and wall-clock — the architecture is past its scale, and raising limits just moves the cliff. Chunking keeps every call inside proven limits at any pack size, and a failed chunk retries at chunk size instead of losing the whole plan.
Where you see it
The repeat declaration on a step in any contract page — e.g. plan-clipart-pack’s manifest step, badged chunked in the step topology.