# Stop conditions and the budget

A loop needs three exits: a stop written as evidence, a hard cap for when the evidence never comes, and a rule for repeated failure. The cost numbers from real runs show why the caps are not optional.

## 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.

```terminal
$ claude
> Make the dashboard pass the audit. Stop when the score is 90 or more, or after 5 tries, or if the same failure repeats twice.
* Try 1: score 71, change image sizes
* Try 2: score 84, defer a script
* Try 3: score 84, same failing audit item
* Try 4: same failing item again for the same reason
# Stops and explains, instead of trying a fifth time.
```

**Question:** Which stop condition is written as evidence?

- Stop when the page looks fast
- Stop when the work seems complete
- Stop when the Lighthouse score is at least 90
- Stop when the agent says it is done

**Answer:** Stop when the Lighthouse score is at least 90. A score is something a program can check. The other three are the agent's opinion of its own work.


## 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.

> **The loop can kill its own brakes**
In the compiler run, one agent killed its own loop with `pkill`. Another problem was time blindness: Claude cannot judge elapsed time, so the author added a fast sampling mode and kept progress output sparse. A cap measured in minutes is only as good as the harness that enforces it. Put the cap outside the agent.


> **Cancel a scheduled loop by asking**
To stop a fixed-interval `/loop`, ask Claude to cancel it. Esc and Ctrl+C do not.


**Question:** The same check fails twice for the same reason. What should the loop do?

- Retry until the cap is reached
- Stop and explain, instead of trying again
- Lower the bar for the check
- Switch to a bigger model silently

**Answer:** Stop and explain, instead of trying again. A repeated identical failure means another try is unlikely to help. Stopping and reporting is cheaper, and it hands the problem to a person.