Go / No-Go — When a Loop Earns Its Cost

A loop is not free iteration. It is a fixed setup cost plus per-turn waste — and it pays back only when four conditions all hold and the budget is bounded by one primitive that actually fires.

Why this, for you: the easiest way to lose a weekend and a token budget is to automate a task that should have stayed a single prompt. The loop runs, the bill climbs, and the work was never the kind that amortizes. This lesson is the gate you run before you build — and the budget cap you set after.

Every other lesson in this course asks how to build a loop. This one asks the upstream question: should you, and if so, what's the cheapest cap that still bites. A loop carries fixed costs — a verifier, persisted state, a skill capturing your conventions — and per-iteration waste a single prompt session never pays.

1 The four-condition gate

A loop earns its cost only when all four of these hold at once. Fail any one and the loop's marginal cost stays at or above the prompt-session cost forever — there is no iteration count that fixes it.

Condition	What it means	If absent
Task cadence	The same task shape recurs ~weekly or better	Setup never amortizes; one prompt is cheaper
Objective verification	An external gate (test, build, typecheck, CI) grades "done"	The loop stops on vibes; maker grades own homework
Absorbable budget	You can spend on retries and re-reads without it changing behavior	Per-iteration waste dominates the savings
Real tooling	The agent has logs, a repro env, and runs what it writes	Loop iterates on a stale view; convergence is theater

The mechanism is fixed-cost amortization. A loop wins only when its fixed cost spread across N runs, plus per-iteration waste, falls below an attentive prompt session at the same per-task cost. Cadence sets N; verification removes human grading; budget absorbs waste; tooling keeps the verifier ground-truth instead of advisory.

This sorts tasks cleanly. Good fits: CI failure triage, dependency bumps, repo-wide lint-and-fix, doc generation — all recur, all verify against a build or test the agent runs itself. No-go: architecture rewrites and auth/payment refactors (no automated verifier for "is this design right"), production deploys (the real environment is the verifier), and any solo, sub-weekly task where N is too small to amortize.

2 The operating metric: cost per accepted change

Tokens-spent is the wrong unit. Tasks-attempted is the wrong unit. The unit that captures both throughput and the reviewer time the loop actually consumes is cost per accepted, merged change.

The ~55% break-even line

A study of 567 Claude Code pull requests across 157 open-source projects measured the baseline: 83.8% of agent-assisted PRs are merged, but only 54.9% merge without further modification — roughly 45% of "successful" output still consumed reviewer time. Below ~55% no-modification acceptance, the loop is doing the review work it was supposed to remove.

The same metric catches the inverse trap: a smarter model with fewer turns at a higher per-token rate can be cheaper per accepted change than a cheap model burning 80 tool calls. Instrument cost-per-accepted-change weekly, and pull the loop if no-modification acceptance falls below that line.

A passing four-condition score does not override a saturated reviewer. A loop multiplies output by N; if review bandwidth was already the bottleneck, the loop's effective throughput is the reviewer's throughput minus the loop's triage overhead — the queue gets longer, not shorter.

3 Budget the loop that passed: one primitive that fires

Once the gate passes, bounding the loop is its own decision — and it's really two: which primitive caps the loop, and how budget is allocated across turns. Three primitives compete to fire first:

Primitive	Right when…	Wrong when…
Iteration count	An external grader certifies correctness; you just need a runaway guard	No grader — a fixed turn count may fire mid-deliverable
Token / cost budget	Cost predictability matters more than completion	Single-session loops where context grows non-linearly
Wall-clock	Latency SLOs bind harder than spend; interactive agents	Background or batch work — it forces a premature stop

One binding primitive beats three slack ones. Budgets that bind force discipline; budgets that never bind are decorative and teach the team nothing when the loop is structurally broken.

The flat per-turn token cap is the classic mistake

Per-turn cost in a single-session loop is not uniform — each turn re-sends the full accumulated history plus tool definitions, so the marginal cost of iteration N grows roughly with N. A 1,000-token-per-turn cap that works at turn 1 is broken by turn 8. Enforce token budgets across the whole loop, and expose (remaining_turns, remaining_tokens) to the controller so it can score the next action honestly.

Iteration caps are portable across model versions; token budgets need re-tuning on every model upgrade (tokens-per-decision shifts between models). That's why Anthropic's managed outcome primitive ships iteration-cap-only — max_iterations defaults to 3, caps at 20 — with the grader in a separate context.

4 Allocate across turns: front-loaded vs even split

With the cap chosen, how you spread compute across turns is the second lever. Front-loaded (the "reasoning sandwich") gives planning and verification extra-high compute and runs execution at high; even split gives every turn the same budget.

# Front-loaded allocation for an 8-turn research loop Turn 1 (planning): effort=xhigh # a wrong plan contaminates every later turn Turns 2-6 (execution): effort=high # follow the decomposition Turn 7 (verification): effort=xhigh # a missed inconsistency = false completion Turn 8 (commit): effort=high # final answer

The reasoning sandwich is the only allocation with published numbers: extra-high planning / high execution / extra-high verification scored 66.5% on Terminal Bench 2.0, beating uniform-high (63.6%) and continuous-maximum (53.9%, penalized by timeouts). Planning errors propagate while execution errors stay local — so concentrating compute where ambiguity is highest beats spreading it uniformly.

Front-loading needs clean phases

The 66.5% vs 63.6% gap is small, and it requires planning, execution, and verification to be separable. Exploratory debugging interleaves all three — there front-loading degrades to noisy uniform compute with routing overhead. For execution-dominated work (bulk refactors, mechanical migrations, lint-and-fix passes), even split is the right default.

↪ Your win: spend a turn only when it earns its cost

Run the four-condition gate first — cadence, objective verification, absorbable budget, real tooling; all four or it's a prompt session.
Measure cost per accepted change, not tokens or attempts — and watch the ~55% no-modification line.
Review capacity overrides a passing score — a loop past a saturated reviewer lengthens the queue.
Cap with one binding primitive — iteration caps are portable; flat per-turn token caps mis-price late turns.
Front-load compute only when phases are clean; even-split for execution-dominated work.

Retrieval practice — recall, don't peek

Question 1For a loop to earn its cost, how many of the four gate conditions must hold?

Question 2The operating metric for a loop is…

Question 3A flat per-turn token cap on a single-session loop is wrong because…

Question 4Front-loaded ("reasoning sandwich") allocation beats even split only when…

Question 5 · spaced recall from an earlier lessonFrom Termination & Convergence: you should stop a loop when…

Ask me anything. Want to run the four-condition gate against a real task you're tempted to automate, or pick the right budget primitive for your harness? Next in Part 3: Runaway Guardrails & Stuck-Loop Recovery — capping iterations, wall-clock, and spend, then breaking a stuck loop out with a recovery move.