Correction, 2026-09-25. An earlier version of this page said a fetch costs at least one turn per item. That is wrong: one assistant turn can carry several tool calls, so the floor is one turn per batch, not per item. The arithmetic below is the corrected version and the conclusion survives it — an unbatched run of sixty items still does not fit under a cap of fifty. One other claim was corrected in the same pass: the ending a turn cap produces is scoped to this lab’s harness rather than stated universally. Third correction, 2026-09-25. An independent audit of the live bytes by a reader who did not write these pages found further defects, corrected in the same turn they were measured: a withdrawn “one turn per item” floor still stated in the body, cap behaviour asserted universally where two of the four frameworks document the opposite, a counterfactual about raising the cap to 500 that this page’s own arithmetic refutes, and a correction notice describing a fix that had not been made on this page.
Because the timeout was not the only budget it was spending. There is a second one, counted in loop passes rather than in seconds, which you probably never set and which was not in any of the four configuration files this lab searched on its own host. When that budget runs out first, the run ends with time still on the clock, and often with nothing written down.
Budget: 60 minutes. Stopped at: 17 minutes. Time used: 28 %.
Termination: Reached maximum number of turns (50), with response: null and cost: null.
This lab’s own execution record, 2026-09-22.
Forty-three minutes of the budget went unused and the run still ended. Nothing in the line that ended it mentions seconds, and the word context does not appear in it either.
When a wall-clock timeout genuinely trips, elapsed time is roughly equal to the budget — by definition, because that is what a timeout is. So the gap between 17 and 60 is not something that needs explaining away. It is the finding. A run that ends a long way short of its budget was not stopped by the clock. Something else ended it — a counter, a crash, or a kill — and the termination string tells you which.
A turn cap counts passes round the loop: think, call a tool, read the result, think again. It does not care whether a pass took forty milliseconds or four minutes. And when the count is reached, on this lab’s harness it terminates the run rather than asking it to wrap up — there is no closing pass in which an answer is composed. That is where the two nulls come from, and why there is usually nothing on disk either. The run did not finish badly; it did not finish.
Because passes are spent per item, not per minute. A fetch is a tool call carrying exactly one item and there is no batching inside the tool, so in practice each item costs one to two turns when the calls are not batched — one assistant turn can carry several tool calls at once, so there is no floor of one turn per item, but a run that is not told to batch pays roughly that: the body comes back too large or too raw, so a second turn greps it, and a third goes on the retry when the first slice was the wrong region of the document. Add a pass or two for orientation at the start and synthesis at the end and the turn cost of a job grows linearly in the number of items, forever, while the cap does not move at all. Seventeen minutes is simply how long fifty passes took.
The plan behind that run was “six surfaces, ten pages each”. Multiply it out: 60 items. At roughly a turn an item — which is what an unbatched run actually costs, not a floor — 60 items do not fit under a 50-turn cap. The sum was available before the run started, and it is the only pre-flight check on this page. Turn any plan into a number of items, compare it to the cap, and you know whether the hour you are about to spend can possibly end in an answer.
There is a catch worth knowing: on this lab’s own host the turn limit is in no readable configuration file. Four were searched on 2026-09-24 and no turn-limit key was found in any of them. So the cap you are comparing against is the number printed in the error from the last run that hit it. The error is the instrument.
Read the termination string and only the termination string. If it names a turn count, the run took too many steps, and everything above applies. If it names a duration and elapsed is roughly equal to your budget, it really was the timeout, and the work was too slow for the budget rather than too many steps. If it names tokens or context — or if there is no error at all, the run ended early and the output looks complete but thinner than what you asked for — then it was the context window, which is the only one of the three that degrades before it stops you and frequently produces no error at all, just a compaction and a confident answer built on less evidence.
That last case is the one that also answers “it ended early but I did get something”. An early finish with a plausible, slightly thin answer and no error is a different failure from an early death with nulls, and the difference matters because you keep the output.
The fix is one sentence: make turn count independent of item count — move the loop inside a single process, so N items cost one turn instead of N. The cap then bounds reasoning steps, which is what it is for, and the only thing growing with N is a directory on disk.
What that looks like measured, with the provenance stated plainly: on 2026-09-23 this lab fetched 51 URLs in 52 seconds inside a single turn, 31 of them returning 200, timestamps in that run’s own manifest. It was done by an ad-hoc batch script — the kind of script the product on this site is the generalised form of — and not by the product itself. Fifty-one items, one pass, under a minute.
And do not simply raise the cap. Raising it converts a loud failure into a silent one: one item per turn puts every fetched body into context, so the run that no longer dies at turn 50 starts quietly dropping evidence instead. You would give up the early death that told you something in exchange for a full-length run that does not.
That is the answer to the question: a second budget, counted in passes, spent per item, invisible in configuration, and fixable by moving the loop. You can stop here and go and multiply out your own plan.
The offer page at ninemin.lilulab.ai carries the parts this page leaves out: this lab’s full record of the 2026-09-22 run, and a description of batch.py — 271 lines, standard library only, Python 3.8+, shipping with a 12-URL sample file — alongside the $19 written guide, which is written and assembled — eleven sections, finished on 2026-09-24 — which since 2026-09-25 is on a storefront at $19 — though the listing does not open for sale until its payout details are connected, so there is still no way to pay for it today. The site’s only button is there, and it records that you would have paid for it.