Claude Code's /loop, explained — and how it differs from routines, hooks, and Goal Mode

Something quietly converged over the last three weeks: every major coding agent now ships a way to say “do this again later, without me.” Claude Code has /loop and cloud routines. Cursor 3.5 shipped a skill literally also called /loop (May 20). GitHub Copilot’s CLI added /every and /after (June 2, still experimental). Google’s Antigravity 2.0 lists “scheduled tasks for background automation” among its launch features.

Same five steps, same recurrence primitives — convergence strikes again. This piece does two things: explains how Claude Code’s /loop actually behaves (it’s the best-documented of the bunch, and a few widely-repeated claims about it are wrong), and then maps the whole family — because “run it again” turns out to be four different questions wearing one trenchcoat.

/loop in ninety seconds

/loop is a bundled skill (added in Claude Code v2.1.71; the docs list v2.1.72 as the minimum version) that re-runs a prompt inside your current session — same conversation, same context, same machine. Three forms, straight from the docs:

You type	What happens
/loop 5m check the deploy	The prompt runs on a fixed schedule
/loop check the deploy	The prompt runs at an interval Claude chooses each iteration
/loop	The built-in maintenance prompt runs — or your loop.md if one exists

The details that matter in practice:

• Intervals can lead (30m) or trail (“every 2 hours”); units are s/m/h/d. Seconds round up to a minute (cron granularity), and awkward intervals like 7m or 90m get rounded to the nearest clean cron step — Claude tells you what it picked.
• The prompt can be another command. /loop 20m /review-pr 1234 re-runs a saved skill or slash command each iteration. This is the composition trick: anything you’ve packaged as a command becomes schedulable.
• Stopping: press Esc while the loop is waiting and the pending wake-up is cleared. One subtlety worth knowing: tasks you scheduled by asking Claude directly (the underlying cron tools) are not affected by Esc — those persist until deleted.
• Everything expires in 7 days. A recurring task “fires one final time, then deletes itself.” You’ll see “3 days” repeated in several blog posts; the official doc says seven.
• /proactive is an alias for /loop (since v2.1.105), and CLAUDE_CODE_DISABLE_CRON=1 turns the whole scheduler off if you want it gone.

Self-paced mode is the interesting half

Omit the interval and /loop stops being cron and becomes judgment. Per the docs: after each iteration Claude “picks a delay between one minute and one hour based on what it observed: short waits while a build is finishing or a PR is active, longer waits when nothing is pending” — and it prints the chosen delay and the reason at the end of each iteration, so the pacing is inspectable rather than mystical.

Two more self-paced behaviors worth knowing:

• It can end itself. In self-paced mode Claude can stop scheduling wake-ups “once the task is provably complete.” A fixed-interval loop never decides it’s done; it runs until you stop it or the 7 days elapse. That’s the practical difference between “watch this until it’s green” and “check this every 5 minutes forever.”
• Sometimes it skips polling entirely. When you ask for a dynamic loop, Claude may reach for the Monitor tool instead — running a background script and streaming its output line by line, which the docs note “is often more token-efficient and responsive than re-running a prompt on an interval.” You asked for a loop; you might get something better than a loop.

One platform caveat: on Bedrock, Vertex AI, and Microsoft Foundry, a no-interval prompt runs on a fixed 10-minute schedule instead — no self-pacing there.

/loop vs routines: same vendor, opposite trade-offs

Claude Code’s other recurrence primitive is routines (research preview): a saved configuration — prompt, repositories, MCP connectors — that runs as a fresh cloud session on a schedule, managed from claude.ai/code/routines or /schedule in the CLI. The docs’ own line draws the boundary: routines “keep working when your laptop is closed.”

	/loop	Routine
Where it runs	your session, your machine	Anthropic-managed cloud
Context	continues — remembers previous iterations	fresh session, fresh clone, every run
Minimum interval	1 minute	1 hour (“expressions that run more frequently are rejected”)
Local files	full access	none — each repo “is cloned on every run”
Survives laptop sleep / closing the terminal	no	yes
Permission prompts	your session’s rules	none — runs autonomously
MCP	your local servers	claude.ai connectors only (local claude mcp add servers don’t travel)
Lifespan	7-day expiry	until you disable it
Triggers	time only	schedule, API endpoint, or GitHub events

The rule of thumb falls out of the table: if the value of iteration N depends on remembering iteration N−1, you want /loop. Watching a flaky CI run, nudging a long migration, babysitting a PR through review — the loop’s accumulated context is the feature. If each run stands alone — nightly triage, a weekly dependency report, “open a PR every morning” — a routine is strictly better, because it doesn’t die with your terminal.

The wider family: four questions, not one

Zoom out across vendors and the “automation” features sort into four genuinely different primitives. Mixing them up is how you end up with a cron job doing a hook’s job badly.

1. Time-driven recurrence — “do it again later.” Claude’s /loop and routines; Cursor’s /loop (“run a prompt repeatedly on a local schedule, until a certain outcome is achieved, or until you stop it” — and “if you don’t specify a fixed interval, the agent decides when or what event should wake it,” i.e., the same two modes as Claude’s, under the same name); Cursor Automations (cloud-side, multi-repo or no-repo, marketplace templates — the routine analogue); Copilot’s experimental /every and /after (recurring and one-shot, with a schedule manager); Antigravity’s scheduled tasks.

2. Event-driven execution — “when X happens, do Y.” Hooks: “user-defined shell commands, HTTP endpoints, or LLM prompts that execute automatically at specific points in Claude Code’s lifecycle.” Not a schedule — a trigger. If what you actually mean is “after every edit, run the linter” or “before any bash command, check it,” polling for it on a loop is the wrong shape; hooks fire exactly when the event does, deterministically. (Routines blur in here too: their GitHub trigger starts a fresh cloud session per repository event.)

3. Objective persistence — “don’t forget what we’re trying to do.” OpenAI Codex’s Goal Mode: as of CLI 0.133.0 (May 21), “Goals are now enabled by default, backed by dedicated storage, and track progress across active turns.” The cookbook describes a goal as “a durable, thread-scoped state” where “resuming a thread can restore the objective” — and is explicit that “continuation is event-driven rather than a simple loop,” checked only at safe boundaries (turn finished, nothing pending, thread idle). There is no schedule anywhere in Goal Mode. It answers “what are we working toward,” not “when do we run next.” Claude Code grew its own /goal command in the same vein (v2.1.139). If you’ve seen Goal Mode described as a scheduler — it isn’t; that’s the trenchcoat problem.

4. Parallelism — “do several things at once.” Background agents (claude agents) and agent teams are about concurrency, not recurrence, and the docs make the cleanest possible statement of the difference: “A routine runs a session on a schedule in Anthropic’s cloud, not in parallel on your machine.” Different axis entirely. (We’ve written a whole field guide on running that axis well.)

Picking the right one, fast

Ask the question your task is actually asking:

1. Does iteration N need to remember iteration N−1? → /loop (self-paced if there’s a completion condition, fixed interval if it’s a pure watch).
2. Should it keep running with the laptop closed, or on a calendar? → routine (or Cursor Automation / /every on those stacks). Accept the fresh-context cost.
3. Is the real trigger an event, not a time? → hook (or a routine’s GitHub trigger if the event is a repo event).
4. Is the problem forgetting the objective across long work? → /goal — persistence, not scheduling.
5. Is the problem too much work for one session? → background agents / teams — parallelism, not scheduling.

And one honest cost note: a fixed-interval /loop re-runs a prompt against your context every tick, whether anything changed or not. The docs’ own nudge toward the Monitor tool is the tell — when a streaming check can replace a polling loop, it’s cheaper and faster. Reach for 5m intervals because the task needs them, not because five minutes feels responsible.

Companion reading

• Every popular Claude Code workflow is the same five steps — the convergence lens; Cursor shipping a same-named /loop two weeks after Claude’s is exhibit N+1.
• Running a fleet of long-lived AI agents — the parallelism axis: memory isolation and reboot survival for the agents your loops and routines spawn.
• Claude Code hooks — the event axis, including the fail-open trap.

Sources: Claude Code scheduled-tasks docs (three forms, interval rounding, Esc semantics, 7-day expiry, self-pacing range and printed reasons, Monitor note, Bedrock/Vertex/Foundry fixed 10-minute fallback); Claude Code changelog (v2.1.71 /loop, v2.1.105 /proactive alias, v2.1.139 /goal); routines docs (1-hour minimum, fresh clones, connectors, triggers); hooks reference; agents docs; Codex changelog 0.133.0 and Goals cookbook; Cursor changelog — Shared Canvases and /loop and Automations (both May 20, 2026); GitHub changelog — Copilot CLI (June 2, 2026); Google I/O 2026 developer highlights. All quotes verbatim from the linked primary sources, verified June 4, 2026.