# Four kinds of loop and how to pick one

Turn-based, goal-based, time-based and proactive loops differ in who or what starts the next turn. Picking the simplest one that fits is the first cost decision you make.

## One question separates them

Every loop answers the same question differently: what starts the next turn? The Claude Code team's post sorts loops into four kinds by that answer. The kinds are not a ladder where higher is better. They are tools, and the cheapest one that does the job is usually right.

## Turn-based

You steer each turn. Claude finishes, you read, you reply. This is how most people use Claude Code today.

It looks too ordinary to be a loop, but it is the baseline the others are measured against. If a task needs your judgment at every step, such as design choices or feature work, keep it turn-based. Marek Kaput makes the same point: feature work needs a human, so a loop there should return a draft plus evidence, not a silent merge.

## Goal-based

You state a finish line that can be checked, and `/goal` keeps Claude working until it is met or a turn cap is hit. A separate evaluator model checks after each turn whether the condition holds. Addy Osmani describes the condition as something you write yourself, such as tests pass or lint is clean.

The post's example: Lighthouse score at least 90, capped at 5 tries. Both halves matter. The first is the evidence, the second is the hard cap for the day the evidence never arrives.

```terminal
$ claude
> Set a goal: Lighthouse score at least 90, at most 5 tries
* Makes a change and runs the audit
* The evaluator checks the score after the turn
* Score is 84, so the goal is not met and the next turn starts
# The loop ends on evidence or on the cap, never on the agent's say-so.
```

## Time-based

The clock starts the turn. `/loop` re-runs a prompt on an interval, on your machine. The post's example is checking a pull request every 5 minutes. `/schedule` moves the same idea to the cloud as a routine.

From the Claude Code docs, three options exist: cloud routines with `/schedule` (they run without your machine, minimum 1 hour), Desktop scheduled tasks (your machine, 1 minute minimum when Claude sets it) and in-session `/loop`. With `/loop 5m prompt` you fix the interval, with `/loop prompt` Claude picks each interval, and a bare `/loop` runs a built-in maintenance prompt or your `loop.md`.

> **A timer is not enough**
A time-based loop is only useful if each run looks at fresh evidence. To stop a fixed-interval `/loop`, ask Claude to cancel it. Esc and Ctrl+C do not do it.


**Question:** You want Claude to keep improving a page until a Lighthouse score reaches 90, and give up after a few tries. Which kind fits?

- Turn-based
- Goal-based with /goal
- Time-based with /schedule
- Proactive

**Answer:** Goal-based with /goal. The finish line is checkable and the work should continue until it is met, with a turn cap. That is what /goal is for.


## Proactive

Nobody is present. An event or a schedule starts the work: triage, migrations, dependency upgrades. The post's example fans out three fixes in parallel worktrees and has a judge pick the best.

This kind is the most powerful and the one that most needs the next lessons. With no one watching, the check and the stop condition are the only supervision. For event-driven reaction instead of polling, the docs point to Channels.

## How to pick

Ask in this order.

1. Does it need your judgment each step? Stay turn-based.
2. Is there a checkable finish line? Use `/goal`.
3. Does something change over time that you must watch? Use `/loop`, or `/schedule` if your machine should not be required. Match the interval to how often the watched thing changes.
4. Should it run with nobody there? Go proactive, but only after the check and the caps exist.

The post's cost advice agrees with going down this list slowly: use the simplest primitive that works, and a cheaper model when possible.

> **Start read-only**
Kaput recommends starting a loop read-only and widening its permissions in steps. A first proactive loop that only reports is a safe way to learn what it would have done.


**Question:** Why is a proactive loop the one that most needs a good check and a stop condition?

- It uses a more expensive model
- Nobody is there to notice when it goes wrong
- It cannot use /goal
- It always runs for longer than an hour

**Answer:** Nobody is there to notice when it goes wrong. With no person watching, the verification step and the caps are the only supervision the loop has.