Off the Leash

Two posts ago I called /loop a clock wired into a session you're sitting in — bounded by the terminal being open, the seven-day cap, the Esc key. I argued the leash was the feature: the loop dies the moment you close the laptop, and that's exactly what keeps a runaway from running away.

/schedule is the same recurring-automation idea with the leash cut.

It doesn't run in your session. It doesn't run on your machine. It runs on Anthropic's cloud, on a clock, whether your laptop is open, asleep, or shut in a bag at 35,000 feet. Close the terminal — it still fires. End the session — it still fires. That's the feature and the danger in one sentence, and the rest of this post is about both.

What it actually is

/schedule creates a Routine: a durable, cloud-hosted Claude Code session that wakes on a trigger and runs to completion without you. You set one up in plain English —

/schedule every weekday at 9am, review open PRs and leave inline comments
/schedule nightly, bump dependencies and open a PR if the tests pass
/schedule clean up the legacy feature flag in one week

— and Claude converts your sentence into a five-field cron expression, shows you the parsed time, and waits for your OK before saving. Manage them with /schedule list, /schedule update, and /schedule run to fire one immediately. It's been a research preview since April 2026, on every paid plan.

Under the hood it's the thing ops engineers have wanted from cron for twenty years and never got: a cron job that can think — one that clones your repo, reads the issue tracker, writes code, and opens a PR, then disappears until next time.

How a run actually happens

This is where the cloud model bites, so be precise about it.

• Fresh clone, every time. Each run starts from a clean checkout of your repo's default branch. It does not see your local files, your uncommitted changes, your .env, your running services. If the work depends on something, that something has to be committed or reachable over the network. Push first, or to the routine it doesn't exist.
• Fully autonomous. There are no permission prompts — there's no one sitting there to answer them. The routine runs with exactly the repo and connector access you granted when you created it. It works on claude/-prefixed branches and opens PRs; it won't touch main unless you let it.
• Stateless between runs. A routine has no memory of last night. Run 14 knows nothing run 13 learned. The prompt has to be self-contained and re-derive the world each time — read the open issues, diff the branches, check the logs — because “what did I do yesterday” is not a question it can answer. Write the prompt for a brilliant amnesiac.
• Three ways to wake it. A cron schedule is one. The other two are where it gets interesting: an HTTP API trigger (POST to the routine's fire endpoint with a per-routine token, so your CD pipeline can summon Claude the second a deploy finishes) and GitHub webhooks (run on every PR opened, every merge). The clock is just the default door in.

A few hard edges before you trust one. The minimum interval is one hour — sub-hourly cron is rejected outright. Runs are staggered up to 30 minutes past their scheduled time, so 0 9 * * * means “sometime in the 9 o'clock hour,” not 9:00:00. There's a per-account daily cap on recurring runs (one-off /schedule run and single-timestamp jobs don't count against it). And the API token is shown once — lose it and you recreate the routine.

The family, finally complete

Three posts, three commands, and they finally line up into one decision. The question is never “which command is best” — it's what wakes the work, and where does it live.

Read it as a flowchart. A stop condition? /goal. A clock, while you're working and watching? /loop. A clock that needs your local files and tools? A desktop task. A clock that has to fire whether or not you exist at that moment? /schedule. The axis that matters most is the one in bold: is your machine the substrate, or isn't it. /loop and desktop tasks are tethered to hardware you own. /schedule is the first one that isn't — and that single fact changes everything about how you have to think about safety.

The leash was load-bearing

Here's the part the launch post leaves out. When /loop runs in your terminal you get three guardrails for free: you can see it, you can Esc it, and it dies when you close the lid. None of those survive the move to the cloud. A routine you set up in thirty seconds on a Tuesday is still firing next month — autonomously, with no prompts, opening PRs against your repo while you're on a beach. The leash you removed was doing real work.

So you replace it with boundaries that don't depend on you being in the room:

• Scope the access. A routine has exactly the repos and connectors you handed it. Give it the minimum. A docs-drift checker does not need write access to prod.
• Keep the PR boundary. The sane default is that routines propose — open a PR — and never dispose: merge, deploy, send. Branch protection is the backstop, so even an off-the-rails routine only gets as far as a PR a human still has to approve.
• Write the prompt defensively. It's stateless and unattended, so it does exactly what the words say, to an amnesiac, 30 times a month, with no one to sanity-check run 14. Bound it hard: “open at most one PR,” “if the tests don't pass, do nothing and stop,” “never touch files outside docs/.”
• Watch the meter. Every run draws from your subscription. An unattended thing that wakes hourly and fans out into subagents is an unattended thing that spends. Read the run history and your usage the way you'd read a cron job's logs — except this cron job has a credit card.

What it's genuinely great at

Cynicism aside, the use cases are real, and they're the boring-but-valuable kind:

• Nightly backlog grooming — read new issues, label them, assign, post a digest to Slack before standup.
• Alert triage — wire the API trigger to your error tracker; on a spike, Claude correlates the trace to recent commits and drafts a fix PR before you've finished your coffee.
• Post-deploy verification — CD calls the fire endpoint, the routine runs smoke tests against the live deploy and reports back. One caveat: the cloud has to be able to reach your deploy — if it sits behind a VPN or an internal mesh, durable isn't omnipresent.
• Docs-drift detection — weekly, diff merged PRs against the docs and open update PRs for whatever went stale.
• Dependency hygiene — nightly bump, run the suite, open a PR only if it's green.

Notice the shape: every one is recurring, tightly bounded, and ends in a PR you review. That's the sweet spot. The moment a routine's job goes open-ended — “improve the codebase” — you've built a slow, expensive, unsupervised intern with commit access. Don't.

Hot takes

1. /schedule is the first Claude Code primitive where your machine stops being the substrate. That's the whole feature. Everything good and everything scary about it falls out of that one fact.
2. The leash you loved to hate on /loop was a safety feature. Cutting it is the point of /schedule — which means you now owe the system the guardrails the terminal used to give you for free.
3. Write every routine prompt for a brilliant amnesiac. It is stateless and unattended; “remember what you did last time” isn't available, and neither are you.
4. Routines should propose, not dispose. Open PRs, never merge or deploy unattended. Branch protection is the line between a useful robot and a 3 a.m. incident.
5. A cron job with a clone of your repo and a model behind it is the cron we always wanted. An unsupervised agent with write access and no off-switch is the cron we should fear. It's the same routine — the prompt and the scopes decide which one you built.