The Loop on a Leash

/loop re-runs a prompt on a timer, inside your session — Boris Cherny babysits his own PRs with it. The catch: it's the same conversation, so a forgotten loop can quietly run up a serious bill.

The Loop on a Leash — AI

Boris Cherny, the engineer who built Claude Code, has said he runs a handful of loops on his own machine. /loop 5m /babysit — every five minutes, auto-address his code-review comments and rebase his open PRs. /loop 30m /slack-feedback — every half hour, put up PRs for Slack feedback. He calls /loop and /schedule "two of the most powerful features in Claude Code," and he's blunt about where it leads: "I don't prompt Claude anymore. I create loops — and the loops do the work. My job is to create loops."

Now the other story: a forgotten loop left running overnight reportedly ran up a roughly $6,000 usage spike. Both are the same feature. The distance between them is everything this post is about.

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.

Omit the interval and it swaps engines entirely. Now Claude self-paces: after each round it picks a delay between one minute and one hour based on what it just saw — short while a build is finishing, long when nothing's pending — and prints the delay and the reason. Better, it can arm a Monitor: a background script that streams its output back and can wake the loop from that stream instead of polling. That's push, not poll — cheaper and faster. And in self-paced mode Claude can end the loop on its own when the work is provably done. No timer required.

CommandFires onWhere it lives
/goala condition (state) — "until the tests pass"your session; stops when a model confirms it
/loopa clock (time) — "every 5 minutes"your session, machine on; stops on Esc, 7 days, or (self-paced) when done
/schedulea clock, durablyAnthropic cloud; survives a closed laptop; minimum once an hour

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, minimum once an 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.

The $6,000 night

Here's the property that makes /loop convenient and the property that makes it dangerous — and they are the same property. It's the same conversation. Every fixed-interval fire injects a fresh prompt into your growing transcript, which means every round re-uploads the entire accumulated context. A loop running every 30 minutes overnight doesn't run sixteen cheap little tasks. It runs sixteen increasingly expensive ones, each dragging the full, ballooning history behind it.

That's the $6,000 story: a forgotten loop running overnight, context swelling into the hundreds of thousands of tokens, re-sent dozens of times over a day. (A separate Claude Code bug report describes a pathological loop burning roughly four million tokens in under five minutes — keep that one mentally filed apart from /loop.) "A one-minute loop running for eight hours is 480 API calls" — true, but it undersells it: they're not the same 480 calls, they're 480 calls each bigger than the last. The convenience (shared session context) is the cost (shared session context). One property, two faces.

Keeping it on the leash

Never walk away from a fixed-interval loop without a stop. Esc clears a pending fire — but don't lean on prose like "end after N turns" as a hard cap; for a fixed interval, cancel the task or press Esc yourself. The 7-day session expiry is a backstop, not a budget. Shrink before you multiply: /compact before a long loop, and watch /cost every few cycles — you're paying for the history. Prefer self-paced + Monitor over a tight fixed interval: push beats poll, and a five-minute cron that mostly finds nothing is pure overhead; if you must go fixed, go wide — 15 to 30 minutes, not one. And loop a skill, not a sentence — Cherny's pattern is /loop 5m /babysit, a saved, scoped skill, not a vague paragraph. The loop is only as safe as the thing it re-runs.

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.

Ralph is an external loop: every pass is a brand-new process with a fresh, empty context reading the same spec file. Context resets every iteration — and that's the entire trick. It's how Ralph beats context rot on long greenfield builds. /loop is an internal loop: same process, same conversation, context accumulates. Opposite cost curves. Opposite jobs. Ralph is for "build this whole thing from a spec, overnight, from zero." /loop is for "watch this thing and react while I work." Run Ralph when you want amnesia between passes; run /loop when you want memory. Confuse the two and you'll lose either your context or your wallet.

The leash is the feature

/loop is not trying to be the autonomous AI that runs your company while you sleep. It's a clock wired into a session you're sitting in — deliberately bounded by the terminal being open, the 7-day cap, and the Esc key. That leash isn't a limitation; it's the design. The person who built Claude Code uses it to babysit his own PRs, in a window he can see, that stops firing the moment the session closes. That's the mental model — not "set it and forget it," but "set it and stay in the room." The moment you treat a session loop like a durable cloud job and walk away, the meter is running on the entire conversation. That's how a polling loop becomes a $6,000 alarm clock. /loop isn't overhyped; it's under-disciplined. Give it a narrow job, a sharp command, and a reason to stop — then let it keep watch.

Hot takes

/loop's killer feature and its $6,000 trap are the same property: it re-runs in your session, so it shares your context — and re-pays for all of it, every round.

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.

/loop is not Ralph. Ralph resets context every pass (external while-loop); /loop accumulates it (one session). Opposite cost curves — don't confuse the amnesiac with the elephant.

Self-paced + Monitor beats a tight fixed interval. Push, don't poll. A five-minute cron that usually finds nothing is just paying to ask.

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.

When the engineer who built Claude Code automates his own PR babysitting with /loop 5m /babysit, the feature is real. When someone wakes up to a $6k bill, the leash is too. Both, always.

📖
Related Reading

Define the Finish Line — /loop's sibling, when the trigger is a condition instead of a clock

You Can't Authorize Autonomy — externalizing the stop condition, and why Ralph-style loops finish

Above the Model — the components above the model that decide output quality

Off the Leash — /schedule: recurring work in the cloud, even with your laptop closed.

Stop Babysitting the Babysitter — combining /goal, /loop and /schedule into hands-off autonomy.

Amnesia as a Feature — Ralph — the external, fresh-context loop /loop is the deliberate opposite of.
💬
Working with a team that wants to adopt AI-native workflows at scale? I help engineering teams build this capability — workflow design, knowledge architecture, team training, and embedded engineering. → AI-Native Engineering Consulting