The 4 Types of Loops in Claude Code (and When to Use Each)

What Counts as a Loop in Claude Code

Ask ten people on X what a "loop" is and you'll get ten different answers. The Claude Code team's own definition, from a recent ClaudeDevs article, is the cleanest one available: a loop is an agent repeating cycles of work until a stop condition is met.

What changes between loop types is how they're triggered, how they stop, which Claude Code primitive drives them, and what kind of task each one fits. Claude Code ships four built-in ways to run one — you don't need external orchestration for most of them. This post walks through all four, plus how to keep quality up and token spend down as loops get longer-running. (See the original ClaudeDevs article for the source, and What Is Loop Engineering? for the vendor-agnostic version of these same ideas.)

Turn-Based Loops

• Triggered by: a user prompt.
• Stops when: Claude judges the task complete, or needs more context from you.
• Best for: shorter tasks that aren't part of a regular process.
• Keep it efficient by: writing specific prompts and using skills to improve self-verification, so it takes fewer turns.

This is the loop you're already running every time you prompt Claude. Claude gathers context, acts, checks its own work, repeats if needed, and responds — the "agentic loop." Ask it to add a like button and it reads your code, makes the edit, runs the tests, and hands back something it believes works. You check the result and write the next prompt.

You can tighten the verification step by encoding your own review checklist as a skill, so Claude checks more of its own work before handing it back. Give it tools to actually see, measure, or interact with the result — the more quantitative the check, the more reliably Claude can self-verify. For example, a SKILL.md:

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---

# Verifying frontend changes

Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:

1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome DevTools MCP, run a performance trace and audit Core Web Vitals.

If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

Goal-Based Loops (/goal)

• Triggered by: a manual prompt, in real time.
• Stops when: the goal is achieved, or a max number of turns is reached.
• Best for: tasks with a verifiable exit condition.
• Keep it efficient by: setting explicit turn caps — "stop after 5 tries."

A single turn isn't always enough, especially for harder tasks. /goal lets Claude keep iterating past one turn by having you define what "done" looks like up front, instead of letting Claude decide unilaterally when it's good enough:

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work if it isn't met yet. This is why deterministic success criteria — number of tests passing, a score threshold — work so much better than vague ones.

Time-Based Loops (/loop and /schedule)

• Triggered by: a fixed time interval.
• Stops when: you cancel it, or the underlying work completes (PR merges, queue empties).
• Best for: recurring work, or interfacing with something outside your project.
• Keep it efficient by: using longer intervals, or triggering on events instead of time where possible.

Some work is genuinely recurring — summarize Slack every morning. Other work depends on watching an external system change — a PR that might get review comments or fail CI. /loop re-runs a prompt on an interval to handle both:

/loop 5m check my PR, address review comments, and fix failing CI

/loop runs locally, so it stops when your machine does. To move the same idea to the cloud and have it run without your laptop open, wrap it in a routine with /schedule.

Proactive Loops

• Triggered by: an event or schedule, no human involved in real time.
• Stops when: each individual task's goal is met; the routine itself keeps running until you turn it off.
• Best for: recurring streams of well-defined work — bug triage, migrations, dependency upgrades.
• Keep it efficient by: routing routine work to smaller, faster models and reserving your most capable model for judgment calls.

Proactive loops compose the other primitives — plus auto mode and dynamic workflows (research preview) — into something that runs unattended. For handling incoming bug reports, that composition looks like:

1. /schedule (research preview) runs a routine that checks for new reports.
2. /goal defines what "done" means; skills document how to verify it.
3. Dynamic workflows orchestrate agents that triage, fix, and review each report.
4. Auto mode lets the routine run without stopping to ask permission at each step.

Put together, a single prompt can set the whole thing up:

/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Keeping Loop Output High-Quality

A loop is only as good as the system around it:

• Keep the codebase clean — Claude follows the patterns and conventions already present in it.
• Give Claude a way to verify its own work — encode what "good" means for your team as a skill.
• Keep docs reachable — up-to-date framework and library docs mean fewer wrong guesses.
• Use a second agent for review — a reviewer with fresh context is less biased by the implementer's own reasoning. Use the built-in /code-review skill, or Code Review for GitHub.

When a result falls short, don't just fix that one instance — encode the fix into the system so every future iteration benefits.

Managing Token Usage

Longer-running loops need explicit boundaries:

• Match the primitive and model to the job — small tasks don't need multiple agents or a loop at all; some can use cheaper, faster models.
• Define clear success and stop criteria — specific enough that Claude converges quickly, but not so loose it stops too early.
• Pilot before a large run — dynamic workflows can spawn hundreds of agents; test on a small slice first.
• Use scripts for deterministic work — running a script is cheaper than re-deriving the same logic in a reasoning step every time.
• Don't poll more often than the thing you're watching actually changes.
• Review usage as you go — /usage breaks spend down by skill, subagent, and MCP; /goal with no arguments shows turns and tokens so far; /workflows shows per-agent spend and lets you stop any of them.

Which One Do You Reach For?

• Turn-based — you hand off the check. Use it when you're exploring or deciding. Reach for custom verification skills.
• Goal-based — you hand off the stop condition. Use it when you know what done looks like. Reach for /goal.
• Time-based — you hand off the trigger. Use it when the work happens outside your project, on a schedule. Reach for /loop or /schedule.
• Proactive — you hand off the prompt. Use it when the work is recurring and well-defined. Reach for all of the above, plus dynamic workflows.

To get started, look at work you're already doing by hand and pick one piece to hand off: can you write the verification check? Is the goal clear enough to state up front? Does the work show up on a schedule? Run the loop, watch where it stalls or over-reaches, and iterate from there.

For more detail, see Claude Code's docs on running agents in parallel, plus the /loop, /schedule, /goal, and dynamic workflows pages — or browse MCP.so's Loops directory for ready-to-paste kickoff prompts that work with any of the four patterns above.