Claude Code's guide to loops: the hard part is defining done

The Claude Code team published a guide to loops, the pattern of letting an agent repeat a work cycle until a stop condition is met. They split it into four kinds. Turn-based loops are the familiar case: you ask, and Claude iterates until it judges the task done. Goal-based loops run until a checkable condition is reached, like /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. Time-based loops run on a schedule, such as /loop 5m check my PR, address review comments, and fix failing CI. Proactive loops fire on events with no human watching, for streams like bug triage or dependency upgrades.

Most of the practical advice is about stop conditions. The team writes that deterministic criteria, a number of tests passed or a score threshold cleared, work far better than asking Claude to decide when something is good enough, because subjective judgments make the loop quit early or run too long. They also push using plain scripts for deterministic steps, since running code is cheaper than reasoning through it, and matching a loop's interval to how often the underlying thing actually changes. Usage stays visible through /usage, /goal, and /workflows.

Why it matters

If you are moving from chatting with Claude Code to leaving it running unattended, the design choice that matters most is how you define done. Write success as something a script can check, or you will pay for wasted turns and get inconsistent stops that are hard to debug after the fact.