Claim

An agent burns through its token budget and dies at its turn cap, so you raise the cap. It is the wrong lever. A runaway token bill is a defect-diagnosis problem, not a budget-sizing problem. Roughly 99% of an attempt’s tokens are context re-carried, turn after turn — the model’s own writing is the other 1% — so a defect that strikes early and takes twenty turns to shake out is charged again on every turn that follows it. The arithmetic on your stack is the same as on mine: the bill measures how long a known failure went unrecognized.

The receipt

Two governed runs had burned 5M and 8M tokens, and I wanted to know why we were taking so many turns. Rather than resize caps on intuition, we read one failed attempt turn by turn. Its anatomy is the whole argument:

flowchart LR
    R["Recon<br/>11 turns"] --> I["Implement<br/>4 turns"]
    I --> S["Debugging spiral<br/>20 turns<br/>re-deriving a filed defect"]
    S --> F["Fix + test<br/>4 turns · one line<br/>350 tests green"]
    F --> W["Wrap-up<br/>10 turns"]
    W --> X(["Dead at the cap<br/>51 turns, 49 categorized<br/>50-turn limit"])
    style S fill:#f2d0d0,stroke:#b03030

Twenty of the fifty-one turns were a spiral — the run re-deriving a defect we had already filed, a fresh-install dependency drift parked at proposed. About 40% of the budget went to rediscovering something already on file. The work itself took eight turns, the two blocks flanking the spiral. And the attempt finished: at turn 49 the full suite was green — 350 tests, including the 8 that had been failing from the drift all along — the change committed. It died at the cap during final verification, and the ledger recorded a failure over finished work. A bigger cap would have delivered this attempt — and left the spiral in place to tax the next one.

Measurement changed the decision. I repriced the finding from proposed to High, and the fix was one line: the project pinned typer but let click float, so every fresh install resolved a click release that breaks the test runner. The next comparable run did the same class of work in 290k tokens with zero failed attempts. This one spent 42× that. The full chronology — the turn where the executor asked whether its own edits were even running, the turn where it named the cause itself — is in the lab record, docs/lab/turn-economy-audit.md, the audit this piece argues from.

What to check Monday

Before you resize a cap, read one failed run’s transcript turn by turn. Categorize the turns — recon, implementation, debugging, wrap-up — and put a number on each. Then cross-check the debugging block against your own findings backlog. The bet worth making is that the agent spent its afternoon rediscovering something you had already written down, and the cheapest fix on the table is closing the finding that started the spiral.


Agent-drafted under the editorial loop (docs/editorial-loop.md) in the operator’s assumed voice (voice-profile v2), from the merged lab record above; every number is sourced from that audit note. Published after the chief-editor spot-edit — the voice gate, the fact gate, and the publish checklist.

Related notes

More on this topic