Stop conditions and the budget

Three exits

A loop with one exit is a loop that will, sooner or later, run forever. The research on loop design agrees on three.

1. Stop on evidence. The condition names something observable: the tests pass, the score is at least 90, the verifier approves.
2. A hard cap. A limit on turns, time, tokens or cost, for the day the evidence never arrives.
3. Stop on repeated failure. If the same check fails twice for the same reason, the loop stops and explains instead of trying a third time.

Marek Kaput adds a fourth for unattended loops: surprises escalate to a human. An unrelated file changing, or a verifier that cannot run, is not something the loop should decide about alone.

Writing the condition as evidence

Compare two stop conditions.

• "Stop when it looks good."
• "Stop when npm test exits with code 0 and the Lighthouse score is at least 90."

The first is the agent's opinion about its own work, and models are generous about that. The second is something a program can check. Kaput's rule is blunt: stop on specific evidence, never "until it looks good".

The Claude Code team's example shows both halves in one line: a Lighthouse score at least 90, capped at 5 tries. The evidence ends the happy path. The cap ends the others.

Why the cap is not optional

The cap protects you from a loop that is working perfectly on a task that cannot be won. These are the cost numbers from the research, with what each one measured.

• The C compiler run. About 2,000 sessions, about 2 billion input and 140 million output tokens, just under 20,000 USD. The result was about 100,000 lines of Rust that builds Linux 6.9 on x86, ARM and RISC-V. Money well spent, but only because it was planned.
• The retro game maker. Alone, the agent took 20 minutes and 9 USD and produced something broken. The full harness took 6 hours and 200 USD and produced something playable. That is more than twenty times the cost.
• A music workstation run with a newer model and a simpler harness: about 3 hours 50 minutes and 124.70 USD.
• Multi-agent research. About 4 times the tokens of a chat for an agent, and about 15 times for a multi-agent system.

None of these is a warning against loops. They are scale references so that your cap is a number you chose, not a surprise.

Keeping the bill honest

The Claude Code team's cost advice fits on a short list.

• Use the simplest primitive and a cheaper model when possible. Model and effort are the largest levers.
• Pilot big runs small first, because dynamic workflows can spawn hundreds of agents.
• Put deterministic steps in scripts instead of paying a model to do them.
• Match a routine's interval to how often the watched thing changes. A check every minute on something that changes daily is waste.
• Watch /usage, /goal and /workflows.

Sub-agents multiply tokens, so Addy Osmani suggests them only where a second opinion pays.