/loop Is A Watchdog, /schedule Is An Alarm Clock — Pick The Right Claude Code Automation For The Job

Part of the Claude Code workflow series. Start with the install primer; then what to do after install; then this post when you're picking between /loop and /schedule for your first automated task.

/loop and /schedule look similar — both accept a time interval and a prompt, both run that prompt repeatedly. They are not substitutes for each other. The difference is where they live and what dies when your laptop goes to sleep.

/loop runs inside a currently-active Claude Code session. It's a recurring prompt that fires every N minutes while the session is open. Close the terminal, the loop stops. Think of it as a watchdog that sits at your side while you work.

/schedule is a remote agent routine — a cron-like job that fires on a schedule regardless of whether you're logged in. It runs on Anthropic's infrastructure, spins up a fresh agent, does its work, stores the output, and shuts down. Your laptop can be off for a week and the morning report still lands.

You can misuse either. Below are the patterns that work for each, and the sharp edges to watch for.

/loop — while you're working

/loop shines at short-feedback tasks you want humming in the background while you're heads-down on the main task.

Use it for:

• Polling a build or test suite. /loop 30s run the test suite and summarize any new failures since last check. You keep coding; Claude tells you when something breaks.
• Watching a deploy. /loop 45s check the latest Netlify deploy status at <site> and stop looping once it's live or failed. A self-terminating loop is legal and nice.
• Keeping session state tidy. /loop 5m check if the context window is over 70% full and summarize whatever can be compacted without losing decisions. A self-cleaning session.
• Catching regressions during a refactor. /loop 2m run the targeted test for the file I'm editing and diff the output against the last pass. Fast feedback without leaving the terminal.
• Summarizing what you just worked on. /loop 10m capture what the last 10 minutes of changes accomplished in one sentence for the daily log. Your standup writes itself.

What kills a /loop:

• Closing the terminal.
• Ending the session (/exit, Ctrl+C, etc).
• A system restart or logout.
• The loop's prompt returning an error three times in a row (harness will pause and surface it to you).

The dependence on an active session is the trade-off. In exchange, /loop is essentially free — it's piggybacking on your current prompt cache, so a 30-second poll costs a fraction of a normal turn.

Tuning the interval:

• Under 60s — only for things you need to know fast. Compilation polling, deploy tracking.
• 1–5m — most things. Test summaries, context-window checks, git status.
• 10m+ — low-frequency ambient tasks. Summary generation, log rollups.

Loops that fire too often drown the main thread in interruptions. Loops that fire too rarely miss the window where they were useful. Default to 10m and tune down only when you notice the information is stale.

/schedule — running without you

/schedule is for things you want done whether or not you're at the keyboard. It spins up a clean agent at the specified cron time, does the work, stores the result somewhere you'll find it, and exits.

Use it for:

• Morning triage. /schedule '0 8 * * *' "Summarize new GitHub issues and PRs in <repo> from the last 24h, flag anything waiting on me." At 8am you have a one-page brief.
• Nightly test runs. /schedule '0 2 * * *' "Run the full test suite against main branch and email a summary to <address>." Flakes and regressions surface overnight.
• Weekly dependency audit. /schedule '0 9 * * 1' "Run npm audit + check for outdated deps + flag anything with a security advisory." Monday morning you have a dependency report waiting.
• Deploy verification. /schedule '*/15 * * * *' "Hit https://<site>/healthz and report if non-200." Poor-man's uptime monitor that also explains what's wrong.
• Content refresh pipelines. /schedule '0 6 * * *' "Regenerate the daily market summary from the RSS feeds and commit to /content/market/." The pipeline runs without you.

What /schedule can and can't do:

• Can access local repos you have authorized through the remote-control config. Can commit, push, open PRs.
• Can send output to email, Slack, webhooks, or save to files. Configurable per routine.
• Can't do anything interactive. If the task needs approval or a prompt, it'll pause and wait for you — defeating the point. Schedule only tasks that are truly autonomous.
• Can't exceed the agent's context or tool limits. Long-running or state-heavy tasks need to be decomposed into multiple schedules that hand off via files.

Cron syntax refresher (the part people forget):

* * * * *
| | | | |
| | | | +- day of week (0-6, Sunday = 0)
| | | +--- month (1-12)
| | +----- day of month (1-31)
| +------- hour (0-23)
+--------- minute (0-59)

Common patterns:

• 0 8 * * 1-5 — 8am every weekday
• */15 * * * * — every 15 minutes
• 0 */4 * * * — every 4 hours on the hour
• 30 3 1 * * — 3:30am on the 1st of every month

Use crontab.guru to sanity-check before scheduling.

The decision tree

Does the task need to run when I'm not logged in? → /schedule.

Does the task need to finish before I need the result (minutes or less)? → /loop.

Does the task involve an approval or a prompt for more info? → Neither. Do it manually or build a skill.

Is the task essentially free in context (polling a cached response)? → /loop — no reason to pay for a cold agent when the live one already has the context.

Does the task need to happen at a specific clock time (8am briefing, 11pm backup)? → /schedule.

Is the task "run this every N minutes forever" without a clock anchor? → Either works; pick based on whether you'll always be at the machine when it should run.

Patterns that combine both

Real workflows often use /loop and /schedule together.

Build pipeline:

• /schedule '0 2 * * *' runs the full test suite at 2am and commits a coverage report.
• At 9am when you start work, you /loop 2m run the fast-test suite since the 2am coverage report. The overnight schedule establishes the baseline; the loop watches for regressions against that baseline while you code.

Content production:

• /schedule '0 5 * * *' pulls new RSS items each morning at 5am.
• When you sit down to write, /loop 15m check for any new RSS items since 5am and summarize them as draft bullets. Morning batch + in-session incremental.

Deploy tracking:

• /schedule '0 */6 * * *' runs a site-wide audit every 6 hours and stores the report.
• During active deploy, /loop 30s poll the deploy status until live or failed. Schedule for baseline; loop for the specific deploy you care about right now.

Gotchas

• /loop dies when you close the terminal. Not a bug — a feature. Don't use loops for anything you need to still be running an hour after you walk away.
• /schedule can't ask for approval. If a scheduled task hits an approval prompt it pauses until you log in. Schedule only auto-approval-safe work.
• Schedules accumulate silently. After a few weeks you'll have 15 active schedules and forget what half of them do. /schedule list shows them all; delete the ones you don't use.
• Time zones matter. /schedule uses your configured time zone at creation, not at execution. If you travel or change time zones, re-verify the actual fire times.
• Context reset between runs. Each /schedule firing starts from a cold agent with no conversation memory. Everything it needs must be reachable via repo files or tool calls.

What to try today

• Replace one manual checklist task (morning PR triage, nightly test run, weekly dep audit) with a /schedule.
• Replace one watchdog behavior (refreshing the deploy dashboard, re-running tests on save) with a /loop.
• Delete any /schedule you haven't reviewed the output of in the last 30 days.
• After a week, run /insights and check whether loops or schedules showed up as friction-reducers (they should).

Related reading

• AI Terminal Kickstart — install prereq.
• CLI installed — now what? — overview that introduces both commands.
• /insights-driven iteration — measure whether your loops and schedules are actually saving time.
• Hooks implementation guide — schedules that hit approval prompts pause; the right hook removes the prompt entirely.
• Adversarial subagents + worktrees — schedules that spawn review agents on nightly builds.

Fact-check notes and sources

• Official: Claude Code docs on scheduled tasks.
• Paddo: From Ralph Wiggum to /loop: The Absorption Continues — the evolution of /loop from community tooling to first-class command.
• Reddit: Anthropic just made Claude Code run without you — launch discussion for /schedule.
• LinkedIn: Introducing /loop — launch post.

Informational, not engineering consulting advice. Cron syntax and /schedule behavior reflect Q1 2026 surface. Verify against the official changelog before depending on specific behaviors in production. Mentions of Anthropic, Claude Code, linked publications are nominative fair use.