Claude Code Routines vs /loop: What's the Difference?

Claude Code now has three ways to run on autopilot

As of August 2026, Claude Code can run a prompt automatically in three genuinely different ways: a cloud Routine, a Desktop scheduled task, or a session-scoped /loop. They solve overlapping problems (recurring PR review, nightly dependency audits, checking back on a deploy) but they run in different places, survive different things, and reach different data. Picking the wrong one is the difference between a task that quietly keeps working for weeks and one that vanishes the next time you close a terminal.

This piece works through what each one actually is, where the real differences sit, and which to reach for.

The three options at a glance

Anthropic's own comparison table lines them up directly:

There's a fourth option this article doesn't cover in depth: GitHub Actions, for teams that want scheduled Claude Code runs to live alongside their existing CI config rather than in any of Claude Code's own scheduling surfaces.

What a Routine actually is

A Routine is a saved Claude Code configuration: a prompt, one or more GitHub repositories, and a set of MCP connectors, packaged once and triggered automatically. Routines execute as full Claude Code cloud sessions on Anthropic-managed infrastructure, or on your organisation's self-hosted environment when routed there, so a Routine keeps running whether or not your laptop is anywhere nearby.

Each Routine can carry one or more triggers, and a single Routine can combine them:

• Scheduled: a recurring cadence (hourly, daily, weekly) or a single run at a specific future time
• API: an HTTP POST to a per-Routine endpoint, authenticated with a bearer token, starts a new session on demand
• GitHub: pull request or release events on a connected repository start a new session automatically

Create a Routine at claude.ai/code/routines, from the Desktop app's Routines sidebar (choosing Cloud rather than Local), or from the CLI with /schedule:

/schedule daily PR review at 9am

/schedule in 2 weeks, open a cleanup PR that removes the feature flag

Routines run with no permission-mode picker and no approval prompts during the run itself. What a Routine can reach is scoped entirely by the repositories you add, the cloud environment's network access, and the connectors you include, so it's worth trimming connectors down to what a given Routine actually needs rather than leaving every connected service attached by default.

A Routine belongs to your individual claude.ai account rather than a team. It isn't shared with teammates, and commits, pull requests and connector actions it takes all carry your identity, the same as if you'd done them yourself.

Triggering a Routine over the API

The API trigger is the detail that makes Routines useful for more than scheduling. Once you've added one from the web UI and generated a token, a POST to the /fire endpoint starts a session immediately:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

That lets a monitoring tool, a deploy pipeline, or an internal service kick off a Claude Code session directly, without anyone opening a terminal. Anthropic wraps the text field in a <routine-fire-payload> block that Claude treats as untrusted data rather than a direct instruction, so a Routine's own saved prompt has to explicitly opt in to acting on it, for example "investigate the alert described in the routine-fire-payload block". Anyone holding the bearer token can send text, so this wrapping matters if the token ever leaks: fire text from a stolen token still arrives labelled as data to be treated with suspicion, not as a command.

The /fire endpoint currently ships under the experimental-cc-routine-2026-04-01 beta header, and Anthropic is explicit that request and response shapes, rate limits and token semantics may still change while Routines are in research preview.

What /loop actually is

/loop is a bundled skill that reschedules a prompt inside your current session. It doesn't create anything that outlives the conversation: tasks are session-scoped, and starting a fresh conversation clears every one of them. Resuming with --resume or --continue restores any task that hasn't expired, meaning a recurring task created within the last 7 days, or a one-shot task whose fire time hasn't passed yet.

What you pass to /loop changes how it behaves:

/loop 5m check if the deployment finished and tell me what happened

runs on a fixed cron schedule you set explicitly. Leave the interval out and Claude picks one dynamically instead, based on what it observes each iteration, waiting only a minute while a build is finishing and much longer once things go quiet:

/loop check whether CI passed and address any review comments

Run /loop with nothing at all and Claude falls back to a built-in maintenance prompt: continue unfinished work, tend to the current branch's pull request, then run cleanup passes like bug hunts once nothing else is pending. A loop.md file, at .claude/loop.md for a project or ~/.claude/loop.md for your account, replaces that default with your own instructions.

You can also pass a skill as the prompt, so /loop 20m /review-pr 1234 re-runs that skill on the interval you set, provided it's a skill Claude is actually allowed to invoke on its own. Skills marked disable-model-invocation: true, or withheld through a skillOverrides setting, reach Claude as plain text instead of executing.

Under the hood, /loop uses three tools directly: CronCreate schedules the task, CronList shows what's currently scheduled, and CronDelete cancels one by its 8-character ID. A session can hold up to 50 scheduled tasks at once, and every recurring task expires automatically 7 days after creation, firing once more before it deletes itself, which bounds how long a forgotten loop can keep running.

Where /loop genuinely wins

/loop is the only one of the three with direct read access to your session's actual state: whatever files are open, whatever a subagent just found, whatever's in the conversation so far. A Routine, by contrast, always starts from a fresh clone of the repository's default branch, so it never sees uncommitted changes. If the task is "watch what I'm doing right now and check back in five minutes," that's /loop. If the task is "do this reliably every night, whether or not I remember to open my laptop," that's a Routine.

Desktop scheduled tasks: the third option

Desktop scheduled tasks sit between the two. Created from the Desktop app's Routines sidebar by choosing Local instead of Cloud, they run on your own machine on a schedule (hourly, daily, weekday, weekly, or a custom cadence you describe in plain language), starting a fresh session under a Scheduled heading in the sidebar whenever they fire.

Because they run locally, Desktop tasks have direct access to local files and tools the same way /loop does, but they don't require an open session the way /loop does: Desktop checks the schedule every minute while the app is running and starts a new session on its own. The trade-off is that they only fire while your computer is awake. If your machine sleeps through a scheduled time, Desktop runs exactly one catch-up session for the most recently missed time when it wakes, and discards anything older than seven days.

Each Desktop task's prompt lives as a real file you can edit directly, ~/.claude/scheduled-tasks/<task-name>/SKILL.md, with YAML frontmatter for name and description and the prompt itself as the body.

Which one should you actually use

• Use a Routine for anything that needs to run reliably regardless of whether your laptop is open: nightly backlog grooming, a PR review that should fire the moment a pull request opens, a deploy-verification check triggered from your CD pipeline. This is the only option of the three that survives your machine being off.
• Use a Desktop scheduled task when the work needs direct access to local files, uncommitted changes, or tools only your machine has configured, and you're comfortable it only runs while your computer is awake.
• Use /loop for quick, disposable polling inside a session you already have open: watching a build finish, babysitting a PR you're actively working on, checking back on something in the next hour rather than next week.

Troubleshooting

/schedule returns "Unknown command." This usually means your CLI is authenticated in a way Routines don't support. A Console API key, an Anthropic profile, a federation credential, or a cloud-provider login (Bedrock, Vertex, Foundry) all block /schedule, since Routines require a claude.ai subscription login specifically. Check whether ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, or apiKeyHelper is set, since any of those take precedence over a claude.ai login even if you're also signed in. DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, and DISABLE_GROWTHBOOK also block it, because they disable the feature-flag fetching /schedule depends on.

A /loop task didn't fire on time. The scheduler checks every second for due tasks but enqueues them at low priority, and a scheduled prompt only fires between turns, never mid-response. If Claude was busy on a long request when the task came due, it fires once Claude goes idle rather than catching up on every interval it missed. A deterministic jitter offset, derived from the task's own ID, can also delay a recurring task up to 30 minutes past its nominal time, so pick a minute that isn't :00 or :30 if exact timing actually matters.

A Routine's GitHub trigger never fires. The Claude GitHub App has to be installed on the specific repository you're subscribing to, separately from repository access for cloning. Running /web-setup grants clone access but doesn't install the GitHub App or enable webhook delivery, so a trigger configured without that extra step stays silent. During the research preview, GitHub webhook events are also subject to per-Routine and per-account hourly caps; events beyond the limit are dropped until the window resets.

Where to go next

Routines, Desktop scheduled tasks and /loop all run Agent Skills the same way an interactive session does, so anything already installed keeps working unattended. For the underlying skill format none of this changes, see the SKILL.md format explained. If you're weighing how much autonomy to hand a Routine given it runs with no permission prompts at all, Claude Code's auto mode and the Agent Skills security guide are the relevant companion pieces. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code.