One turn cap for every task, what number do you give

L2WorkingEstimate8 minScreenSystem design

RolesAgent Systems EngineeringCustomer AI Deployment

The question

The product team wants a single maximum number of turns that applies to every run of your agent. The agent handles one-line edits, multi-file refactors, and unattended runs that drive a computer for hours. What number do you give them, and how do you defend it?

Answer it first, aloud or on paper. Then open the answer.

The answer

Show short answer

There is no single number, and the estimate shows why. Agents run 40 to 400 steps per task, and a computer-use task runs dozens to hundreds of steps as a normal case. A cap that fits a one-line edit stops every refactor, and a cap that fits an unattended run lets a stuck edit spend hundreds of turns. Give one cap per task class, set each from the trace distribution of successful runs in that class, and pair every cap with a wall-clock budget and a cost cap.

Show full answer

Why one number fails

Task classNormal lengthEffect of one shared cap
One-line editA handful of turnsA high cap lets a stuck run burn hundreds of turns before anyone sees it
Multi-file refactorTens of turnsA low cap ends the run with half the files changed
Unattended computer useDozens to hundreds of stepsA low cap makes the mode unusable

The lesson's rule is to pick a cap that fits the task class, not one size for all.

How to set each cap

  1. Pull the traces for the class and read the turn counts of the runs that passed the gate.
  2. Set the cap above the longest passing run with a margin, and below the point where the traces show repeated actions.
  3. Treat the cap as a yield, not a kill. When the loop reaches it, the caller sees the partial state and decides whether to extend.
  4. Review the caps when the traces move. A new model or a new tool changes the distribution.

The other two budgets

A turn cap alone misses two failure shapes. A run can spend few turns and a lot of wall-clock time, waiting on slow tools. A run can spend few turns and a lot of money, with long contexts on an expensive model. The unattended mode in the lesson ships a turn cap, a dollar cap that aborts the session, and action-count limits per tool. A 24-hour unattended run needs all three, plus an allowlist, and each number needs a written reason.

What to tell the product team

Give them a table, not a number: one row per task class with the turn cap, the wall-clock budget, the cost cap and the per-tool limits, and the trace data that each row came from. Offer one default for an unclassified task, set low, so that an unknown task yields early and a human decides.

Follow-ups

  1. L2WorkingA run reaches the cap with the task almost done. What happens?

    Show expected answer

    the loop yields with a budget reason, the caller inspects the partial state, and the caller extends the budget or closes the session with a handoff.

  2. L2WorkingWhy should the fallback cap for a task with no class be small?

    Show expected answer

    an unknown task is the one most likely to loop, and an early yield costs a human decision while a late one costs hours.

  3. L3SeniorHow do you tell a long run from a stuck run before the cap?

    Show expected answer

    a repeat detector over the action and observation hashes, so that five near-identical actions in a row pause the run early.

  4. L3SeniorThe traces for a class show two clusters of turn counts. What does that tell you?

    Show expected answer

    the class is two classes, and each needs its own cap.

Wrong answers

Show the wrong answers that interviewers hear
  • “Set it high so that no legitimate task is cut off.”

    A high cap on a short task class lets a stuck run spend hundreds of turns, and the point of the cap is to catch the stuck run.

  • “Set it low and let users retry.”

    A low cap on a refactor ends every run with half the work, and a retry starts from zero.

  • “The turn cap is enough, because turns are what cost money.”

    Turns are one axis, and a run can be slow in time or expensive in tokens with few turns.

Taught in

The agent loop lesson sets the cap per task class, and the permission modes lesson pairs it with a cost cap and per-tool limits.