The Output Cap Is the Batch Size

Fifty-five items per run mostly failed. Twelve never did. The limit was not context — it was the response ceiling, and the safe batch turned out to be a fifth of what the best run proved possible.

A product catalogue needed 827 items described, in two languages, from structured source fields. One approved sample of 25 existed. The rest was delegated to parallel agent runs, one batch per run, and the whole thing was instrumented because nobody here had a number for what a job that size actually costs.

Elapsed: 3 hours 33 minutes. 827 items, 1,654 texts, 292,767 words. 53 runs launched.

The finding: batch size is set by the response ceiling, not the context window

The first wave used batches of 54–58 items. Two of five delivered complete files. One crashed outright, one produced a file with an unclosed bracket, and one delivered 45 of 54 and stopped.

The failure was always the same error: the run exceeded its 64,000-token response ceiling. Not the context window — the output limit. Writing 55 items × 2 languages into a single file is itself an output of roughly that size, so the instruction "write it in one call" was working against the constraint it was meant to satisfy.

Three sizes, measured:

The half-size batches did not merely fail less. They did not fail once.

Forty-five of the 53 runs are in that table. The other eight were redistribution runs — the ledger sized them from whatever items were still missing, so they belong to no arm and are left out rather than rounded into one.

What the table cannot carry

The three sizes were not run concurrently, and not in random order. The 12–13 arm ran last, on items that had already failed at least once, under a brief that had gained two rules during the day. Ten for ten is a real result, but it is ten results, collected under the most practised conditions the job ever had.

What the day rules out is a batch of 55. What it does not establish is 13-good-25-bad as a constant. The number that would settle that is a second run of the same job at one fixed size, which has not been done.

Sizing the next one without repeating the experiment

The useful part is not the number 12. It is that the ceiling can be used as the measuring instrument, which removes the need for a tokenizer nobody has.

Two first-wave runs did complete. One emitted 127,073 bytes for 58 items, the other 119,616 for 54 [measured]. Both fit under the same 64,000-token cap, so that output cost at most 1,103 tokens per item, and this content runs at no less than 1.99 bytes per output token. The cap is the ruler.

Then the part the arithmetic cannot reach. Runs of the same nominal size did not get the same distance. One delivered all 58. Another stopped at 45 of 54. A third emitted a file that would not parse, and a fourth wrote nothing at all. Same instruction, same batch size, same cap.

So per-item cost is not the binding variable. The budget is shared with everything else the run emits on the way to the file — and that share is invisible from outside and varies run to run. The cap has no partial-credit mode either: at 90% of it the file is truncated, not shortened.

Which sets the rule: size against the worst run you have seen, not the best, then halve it. The best here proved 58 was possible; the size that never failed was 12, about a fifth of it [derived]. Anything sized off the good run would have been sized off luck.

What it cost

Forty-two runs reported their consumption. Eleven crashed and reported nothing, so the true total is higher than anything below.

Reported: 6,905,286 tokens across 42 runs. Mean 164,412 per run, range 45,289 to 245,735. Against the delivered artifact that is 8,350 tokens per item and 23.6 tokens per finished word — a ratio worth holding onto, because it prices this class of work without needing anyone's rate card.

460,519 of those tokens — 6.7% — bought nothing. Three runs burned a full budget and wrote no file; a fourth was a probe against a tool that turned out to be unavailable. That is the honest overhead line, and it is the one most likely to be missing from an estimate written before the job starts.

Three runs reported success and had written nothing

This is the part that changes how the work should be supervised.

A run finished, returned a completion summary, and the target file did not exist. Another delivered 45 records of 54 and its message read as done. A third wrote a file that would not parse.

None of that is visible from the report. It is only visible from the artifact — the same layer mistake as checking the wrapper instead of the thing inside it.

So the tracking never asked the runs how they did. A script re-read every output file, parsed it, counted valid records — a record needing both languages and at least seven bullets to count — and derived progress from what was on disk. After any crash, re-running it redistributed exactly the missing items. Fifty-three runs, eleven of them dead, and nothing was lost or written twice, because the ledger was the filesystem rather than the reports.

An agent's self-report is a claim about an artifact, not the artifact. At one run that distinction is pedantic. At fifty-three it is the difference between a finished job and a job that looks finished.

What the gates caught that the runs did not

Every text was checked against its own source row: each number appearing in the text had to exist in the data it came from. Zero blocking errors survived to delivery. Thirteen warnings did, all verified by hand as legitimate — arithmetic (four cords at 3.2 m described as "nearly 13 metres"), unit conversion (35 mm written as 3.5 cm), and serving estimates.

Two classes of defect were found only because the whole set was checked together, which no individual run could do:

• Six recycled openings. Two runs each wrote near-identical intros for products that genuinely differ — two pan sizes, two grinder plates. Individually defensible; as a set, duplicate content.
• Seven cross-product claims. Sentences like "the larger sibling of the 500 ml model" — a statement about a different item, which the run had no data for and cannot be checked. Both were fixed and both became written rules.

The first version of the number check reported 366 violations. All 366 were false: it was reading digits out of a system placeholder and out of a sentence the assembler appends itself. A gate that fires on every item is not a strict gate, it is an ignored one — it was fixed before it buried the eleven findings that were real. A gate that reports everything and a gate that reports zero fail in the same direction: nobody reads either one.

What is not known

The orchestrating session's own consumption is not in the 6.9M figure, and neither is the spend of the eleven runs that died. The per-item cost above is therefore a floor, not a measurement. A second run of the same job at batch size 12 would produce the number that is actually missing here.

[The Output Cap Is the Batch Size](https://stillvalid.dev/architecture/the-output-cap-is-the-batch-size) — stillvalid, SV-1669 (benchmark, verified 2026-08-18)