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.
If the run ended on a line that names a number of turns, and you have no answer and usually nothing on disk, then it did not crash and it did not run out of time. It was terminated mid-thought by a counter watching how many times it went round the loop. Here is what that counter did, how to confirm it in ten seconds, and what to change so the same work finishes.
This is the termination from this lab’s own execution record of 2026-09-22, verbatim:
Reached maximum number of turns (50) response: null cost: nullThat run was budgeted 60 minutes and was dead at 17. Two fields came back null: no answer, and no summary of what it had found in the seventeen minutes it did get.
A turn cap counts loop passes and nothing else. When the count is reached the run is terminated — on this lab's harness it is not asked to wrap up, to summarise, or to write down what it has. That is not universal — the OpenAI Agents SDK ships a max_turns error handler for returning a controlled final output, and CrewAI documents its cap as forcing a best answer — so check your own harness before assuming the ending. There is no final pass in which an answer gets composed, which is why response is null and why there is usually nothing on disk. The absent output is not a second bug to go and find. It is the normal shape of this particular ending, and one of the clearest ways to tell it apart from the other two ways a run can stop.
Read the termination string, and only the termination string.
The 2026-09-22 record clears all three tests in one direction: the string names turns and gives the number, the run used 28 % of its time budget so nothing about seconds is implicated, and the word context appears nowhere in it.
On this lab’s own host, four configuration files were searched on 2026-09-24 and no turn-limit key was found in any of them. That is worth knowing before you spend twenty minutes grepping: the error is the instrument. The number you are bound by is the number printed in the string that stopped you, and on this host that string is the only place this lab has found it.
On this lab’s harness a fetch is a tool call carrying exactly one item, with no batching inside the tool. Ten pages is ten calls. In practice it is one to two turns per item when the calls are not batched, because the body arrives too large or too raw and costs a second turn to grep — one assistant turn can carry several tool calls, so there is no floor of one turn per item — and a third when the first slice turned out to be the wrong region of the document. Orientation at the start and synthesis at the end sit on top of that. So the turn cost of the work grows linearly in the number of items, forever, while the cap stays exactly where it is.
The plan behind the 2026-09-22 run was “six surfaces, ten pages each”. That is 60 items, and 60 items do not fit under a 50-turn cap at one turn per item. The arithmetic was available before the run started and was not done. Any plan you can multiply out into a number of items can be checked against the cap in the time it takes to do the multiplication, which is the cheapest test in this whole article.
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 — and that failure frequently produces no error at all, just a compaction and a finished-looking answer built on less than you gave it. You would be trading a stop you can see for a degradation you cannot.
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.
One measurement from this lab, with its provenance stated plainly: on 2026-09-23 this lab fetched 51 URLs in 52 seconds inside a single turn, 31 of them returning 200, with the timestamps in that run’s own manifest. That 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 turn. The same fifty-one items at one turn per item do not fit under a fifty-turn cap at all.
That is the whole diagnosis for this failure: the cap terminated the run, nothing was composed at the end, the turn count grew with the item count, and the fix is to stop letting it. You can act on all of it without reading another word.
The offer page at ninemin.lilulab.ai has what this page does not: this lab’s full record of the 2026-09-22 run, a description of batch.py (271 lines, standard library only, Python 3.8+) and of 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. It also has the one button on this site, which records that you would have paid for it.