Four kinds of loop and how to pick one

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.

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.

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.