The Loop on a Leash

Claude Code’s /loop is useful for narrow repeated work: checking a deployment, watching a review queue or monitoring a build. Its defining property is that the work runs in an existing session.

Convenient repetition also multiplies activity. A forgotten loop can keep consuming resources, so define the job, its stopping condition and the evidence you will inspect before starting it.

What /loop actually does

/loop re-runs a prompt — or another slash command — automatically, inside your current session. Three shapes: /loop 5m check the deploy runs every five minutes on a fixed schedule. /loop check the deploy lets Claude self-pace — it picks its own delay each round. And bare /loop runs a built-in maintenance loop: continue unfinished work, tend the branch's PR, run cleanup passes when nothing else is pending. You can loop a command, not just prose: /loop 20m /review-pr 1234 re-runs a saved skill every twenty minutes.

The load-bearing phrase is in your session. Unlike a bash while true; do claude -p …; done, a /loop shares your loaded context, your MCP servers, and your permission mode. It isn't a fresh agent each time — it's the same conversation, woken on a timer.

Two engines under one command

Give /loop an interval and it is, literally, cron. It converts 5m to */5 * * * *, registers a session-scoped scheduled task, and fires your prompt between turns — never mid-response. Standard five-field cron, max 50 tasks per session, with a little jitter (up to half the interval on sub-hourly jobs) so a thousand loops don't all stampede at :00.

Without an interval, Claude can choose a delay for each iteration. Where Monitor is available, a background script can provide events instead of repeated polling. Whether that reduces cost depends on the workflow. The model can decide to stop, but its decision is not independent proof of task completion.

The autonomy family

/loop has two siblings, and reaching for the wrong one is the single most common mistake. /goal fires the next turn the moment the previous one finishes, and stops when a condition holds — trigger is a state. /loop fires on a clock, and stops when you stop it, or, self-paced, when Claude decides it's done — trigger is time. /schedule (cloud Routines) runs on Anthropic's cloud, survives a closed laptop, with a minimum scheduled interval of one hour — trigger is time, durably.

The decision collapses to one question: what's the trigger? A condition routes to /goal. A clock, with your machine on and the session open, routes to /loop. A clock that has to survive you closing the laptop routes to /schedule. The community even draws it as a ladder — a raw bash while loop at the bottom, /loop as the managed scheduler above it, /goal adding a model that decides done, full workflows at the top. /loop is the rung where it stops being a hack and starts being a feature.

What repeated work costs

A session loop reuses conversation state. The cost depends on actual model calls, input and output tokens, cache behavior, compaction, tools and billing mode. Context reuse does not mean every iteration pays the uncached rate for an ever-growing verbatim history.

A one-minute schedule has 480 nominal trigger opportunities over eight hours. That is not 480 API calls: a run can make multiple calls, and busy sessions, jitter and scheduling rules affect execution. Measure actual activity and distinguish a billed invoice from an API-price estimate of subscription usage.

Keeping it on the leash

Cancel fixed scheduled tasks explicitly through the task controls. Esc cancels a pending self-paced wakeup, but does not delete every scheduled task. Seven-day expiry is a duration bound, not a spending budget. Use a cadence justified by the expected events, inspect usage, and enforce independent limits for unattended work.

It is not Ralph

The internet's favorite autonomous-loop technique is "Ralph" — Geoffrey Huntley's while :; do cat PROMPT.md | claude-code; done. It's been used on greenfield repo-generation and even compiler and language projects; Anthropic shipped an official ralph-loop plugin too — though that one is an in-session adaptation, and the technique people usually mean is the raw bash version. So it's natural to assume /loop is just the built-in Ralph. It isn't, and that difference is the most important thing here.

An external fresh-process loop and a session loop retain context differently. Neither has a universally superior cost curve: fresh workers re-read necessary sources, while persistent sessions can reuse cached context or compact it. Compare accepted outcomes and measured usage for the same workload.

The leash is the feature

A local loop depends on a running process and the machine’s actual power behavior. Closing a terminal or lid is not a universal cancellation mechanism, especially for background sessions. List active tasks and explicitly stop the intended one. Narrow scope and observable results matter more than a reassuring command name.

Hot takes

Shared context is a convenience with a measurable cost. Account for caching, compaction and the work actually executed.

Pick by trigger. A condition is /goal, a clock is /loop, a clock that survives a closed laptop is /schedule. Most "/loop is broken" complaints are someone who wanted one of the other two.

Fresh-process and session loops make different tradeoffs in continuity and repeated reads. Evaluate them on the same task before claiming a saving.

Where reliable events are available, Monitor can reduce idle polling. Compare actual usage, latency and missed-event behavior with a fixed schedule before choosing.

Loop a skill, not a sentence. The loop is only as safe and scoped as the thing it re-runs: /loop 5m /babysit, never /loop 5m fix stuff.

The 7-day expiry is a backstop, not a budget. If your only stop condition is "the session dies in a week," you've already lost the money.

The feature is useful when its scope and stopping behavior are explicit. Keep the work inspectable and the usage measurable.

Sources: Claude Code scheduled tasks and /loop. Documentation checked September 20, 2026.