By the time Anthropic shipped /loop in Claude Code v2.1.71, a GitHub user named jshchnz had already built the solution the community actually needed: a scheduler plugin with 461 stars that launched new sessions from outside the terminal, survived process exits, and pushed results to a git branch. The community tool was created in January 2026. It predated /loop. Now /loop exists, and the community tool still has the stars, because the two tools solve different problems.
That gap is worth understanding. Not because /loop is bad (it is genuinely useful for what it does), but because its constraints are precise, and precise constraints tell you exactly what the author was and was not trying to solve.
What /loop Actually Does
/loop is a task scheduler built into the Claude Code CLI. You invoke it as a slash command with an interval and a prompt. Claude creates a recurring task that fires on the specified schedule and executes while your session is running.
# Check CI status every five minutes
/loop 5m check if the build passed and tell me the status
# Remind yourself to commit every hour
/loop 1h remind me to commit my work if I have unstaged changes
# Watch a deployment
/loop 2m check the deployment logs for errors and summarize any new onesThe syntax is minimal: a duration string followed by a plain-language prompt. No cron expressions. No task IDs to manage. The underlying implementation uses three tools that shipped alongside the feature: CronCreate, CronList, and CronDelete. You can manage scheduled tasks directly with those tools if you prefer, or you can let /loop handle the bookkeeping.
The experience of using it is closer to setting a phone reminder than configuring a job scheduler. You type a sentence, Claude confirms the schedule, and the task starts firing. When a task fires, Claude becomes idle between your normal turns and executes the prompt. If you are in the middle of a conversation, Claude waits until you are done before executing the next scheduled task.
For mid-session interactive polling (watching a long-running process, catching when a test suite goes green, reminding yourself of something after an hour of focused work), this is exactly right. Minimal friction. No context switching. Claude handles the watching so you can stay focused.
The default interval, if you do not specify one, is 10 minutes. One-shot tasks scheduled at the top of the hour or the half-hour fire up to 90 seconds early due to jitter; if the timing matters, schedule at :03 or :33 instead. Recurring tasks jitter by up to 10% of their period, capped at 15 minutes. If Claude is busy when a task fires, it waits until the next idle moment rather than queuing up a backlog.
Where the Session Ends
Every /loop task is session-scoped. When you close your terminal, all scheduled tasks disappear. There is no persistence layer, no external process keeping the schedule alive. The tasks live inside the Claude Code session and die with it.
The official documentation is explicit about this. Tasks expire after 72 hours regardless of session state. The session limit is 50 concurrent tasks. There is no catch-up mechanism for missed fires: if Claude is busy when a task should have run, it executes once when Claude next goes idle and then resumes the normal schedule. There is no environment variable to extend the 72-hour window. There is one to disable the feature entirely: CLAUDE_CODE_DISABLE_CRON=1.
| Constraint | Value |
|---|---|
| Session scope | Deleted on terminal close |
| Maximum lifetime | 72 hours |
| Task limit | 50 per session |
| Recurring jitter | Up to 10% of period, max 15 min |
| One-shot jitter at :00/:30 | Up to 90 seconds early |
| Missed-fire catch-up | None |
| Default interval | 10 minutes |
One behavior the documentation does not mention: Claude rewrites the scheduled prompt after the first execution. The task fires with your original text, Claude runs it, and then modifies the stored prompt based on what it learned from the first run. This is either an optimization or a bug. Either way, it means the task that runs at minute 10 may not be exactly what you typed at minute 0.
The session-scope constraint is not a technical limitation Anthropic is working around. It is a design boundary. /loop is built for the interactive session. Everything outside that boundary requires a different tool: overnight automations, multi-step pipelines, tasks that need to survive a laptop sleep.
What the Community Built While Waiting
The 461-star number on jshchnz/claude-code-scheduler is a demand signal. The plugin predates /loop by several months and solves a different set of constraints. It launches Claude Code sessions from outside the terminal using --dangerously-skip-permissions for fully autonomous execution. Tasks run in git worktrees so they commit to a branch and open a PR instead of modifying your working tree. The schedule survives terminal close because the scheduler is an external process.
The plugin authors were not building a better version of /loop. They were solving the case /loop does not address: you want something to happen tonight, you want to close your laptop, and you want to come back to a commit.
A macOS GUI app called runclauderun.com appeared around the same time, targeting the same gap. Free, no signup, process-external. Same core idea as the plugin: keep the schedule alive after you leave.
Two independent tools converging on the same missing capability before Anthropic shipped their own scheduler is not a coincidence. It is a measurement. The community identified the gap, built around it, and published tools that have now accumulated hundreds of stars. The gap was real.
The Three-Layer Progression
There is a recognizable pattern in how developer tools evolve around a new capability. Ephemeral comes first, then durable, then orchestrated.
/loop is ephemeral scheduling. It is the first layer: you can automate a recurring task inside your session. The constraint is deliberate. Anthropic is shipping the on-ramp before the highway.
The community tools represent the durable layer: scheduling that survives the session. This is what developers immediately build when given the ephemeral version, because the first question anyone asks after using /loop is "can I run this overnight?" The answer today is "not with /loop."
The orchestrated layer is where I have been working. The Via orchestrator has run 200 missions as of this writing, at a 91% success rate across 5 domains. The longest pipelines decompose into 7 phases, each running a different persona with a different model tier, coordinated by a Go binary that treats each agent as an isolated OS process communicating through SQLite. Tasks do not die when a terminal closes because they are not running in a terminal. They are running as supervised subprocesses managed by the orchestrator, writing to a shared database, and resuming on the next phase when the current one completes.
The difference between /loop and the orchestrator is not just persistence. It is the ability to pass state forward. A /loop task runs the same prompt every N minutes with no memory of what it found last time. An orchestrated phase receives the output of the previous phase as input. The researcher's findings become the engineer's context. The engineer's code becomes the reviewer's artifact.
The three layers are not in competition. They serve different needs at different points in the automation lifecycle. /loop is correct for the interactive session. The community tools are correct for overnight single-step jobs. The orchestrator is correct for multi-step work that needs to survive failures, branch on conditions, and build on its own output.
What v2.1.71 Actually Signals
Anthropic shipping /loop matters less for what it does than for what it represents. A team that was building a coding assistant has now shipped a scheduler. The CronCreate, CronList, and CronDelete tools are first-class primitives in the API. That is not the work of a team that thinks scheduling is someone else's problem.
The 72-hour expiry and session-scope constraint are not permanent limitations. They are the first iteration's scope. The team chose the smallest useful version and shipped it. The next iteration will likely persist across sessions. The one after that will probably allow tasks to pass output to subsequent tasks. The one after that will probably look more like what the community tools already do.
The on-ramp is there. The ecosystem is already layering persistence on top of it. In six months, the question will not be whether Claude Code can run scheduled tasks. That question is already answered. The question will be how much state those tasks can share, and how many steps they can coordinate.
The community built the answer to that question in January. Anthropic will ship it in an official changelog sometime after that.