Claude Code now has four distinct ways to automate recurring work, and the first job is choosing who owns the runtime. Routines are the cloud branch: they keep running in an Anthropic-managed clone after your laptop closes. Desktop scheduled tasks stay on your machine, /loop stays inside the current session, and GitHub Actions stays in CI.
That split makes the route decision much simpler than the launch buzz suggests. Use routines when the workflow should keep running without your laptop and can live inside a cloud-owned repo runtime. Use Desktop scheduled tasks when the job depends on local files, local apps, or a local browser; use /loop when an open Claude Code session is enough; and use GitHub Actions when the workflow belongs to repo-native CI. If the job needs your machine, an open conversation, or CI-first auditability, routines are the wrong owner even if the work repeats.
Anthropic launched routines in research preview on April 14, 2026, which matters mainly because the current contract is still narrower than the headline implies. Routines support schedule, API, and GitHub triggers, but CLI /schedule only creates the scheduled kind, and the API route authenticates with a per-routine bearer token rather than normal Anthropic API-key auth.
The fastest route choice
Before you think about prompts, cron expressions, or webhook payloads, decide which runtime should own the workflow.
| If the workflow needs... | Best surface | Why it wins | Why routines lose |
|---|---|---|---|
| work that should keep running after the laptop closes | Routines | Anthropic hosts the run in a cloud clone and can wake it on a schedule, from API input, or from GitHub events | Routines are still preview-bound and not ideal for local-only dependencies |
| direct access to local files, local apps, or a local browser | Desktop scheduled tasks | The machine is the dependency, so the task should stay on the machine | A cloud clone cannot see the same local state |
| short polling or watch work inside the current coding session | /loop | It is lightweight, fast, and can run every minute while the session is open | It is session-scoped and recurring loops expire after seven days |
| repo-owned automation with CI logs, policy checks, and normal build semantics | GitHub Actions | The workflow belongs to the repo and should stay in CI | Routines are not a better version of CI just because they are newer |
Start with that route board, then use the rest of the article to pressure-test the edge cases before you automate a real workflow.
What routines actually own
The easiest mistake is to hear "automation" and assume the four surfaces mostly differ by trigger type. They do not. They differ first by runtime location and ownership. A routine is a saved Claude Code configuration made of a prompt, one or more repositories, and a set of connectors, then run automatically on Anthropic-managed cloud infrastructure. That means routines are not just scheduled prompts. They are autonomous cloud sessions with their own repo clone, cloud environment, and account-linked actions.
That runtime shift has practical consequences. The routine belongs to the individual's claude.ai account, not to the team by default. If the routine uses GitHub or another connected system, those actions show up as that user. Anthropic's current docs also say repositories are cloned for each run, with the default branch as the starting point unless the prompt says otherwise. In other words, routines are not "remote control for your current laptop session." They are fresh cloud executions built from saved configuration.
The second consequence is that routines own more of the environment than most local Claude Code flows do. Anthropic's docs describe cloud environments for network access, environment variables, and setup scripts. That is what makes routines valuable when the workflow should keep going after you leave. It is also what makes them wrong when the job depends on a local browser profile, local desktop software, a mounted private drive, or a machine-specific credential path that never exists in the cloud clone.
There is a third consequence that many launch summaries bury: routines are not free-form unattended shell access on your personal branch by default. Anthropic documents branch-restricted pushes under claude/ prefixes unless unrestricted branch pushes are enabled for the repository. That is a good sign. It shows routines were designed as a bounded cloud surface, not as a universal replacement for every local and CI automation tool.
When routines are the right route
Routines get more attractive the moment the laptop staying open stops being acceptable. If the real job is "check one repo every morning, look at stale issues, scan new PRs, and surface the next action," a cloud-owned routine is a natural fit. The same goes for recurring docs drift checks, recurring backlog triage, or a GitHub-event workflow where the important thing is that the work starts from the repo surface rather than from whatever session you happened to leave open last night.
The official launch examples point in this direction too. Anthropic talks about tasks such as issue triage, research, and recurring repo work because those are the workflows where cloud persistence matters more than local intimacy. You are not choosing routines because they are the most flexible automation surface. You are choosing them because the workflow benefits from a bounded cloud session that can wake up later and act from a repo clone.
Routines are also the right route when another system should wake the work up remotely. The API trigger exists for cases where a normal Anthropic API call is not the real abstraction you need. The useful mental model is not "call Claude from code." It is "fire a saved cloud workflow with a small extra instruction payload." That is narrower, but it is also cleaner when the workflow shape is stable and the wake-up event is what changes.
The bad fit is just as important. Routines are not the answer to every recurring job, and they should not be sold that way. If the workflow only makes sense while you are already inside a live Claude Code conversation, or if the workflow depends on the machine you are sitting at, the extra cloud surface buys you complexity without solving the real constraint. That is why the negative case needs to stay visible all the way through the article, not just in the FAQ.
When Desktop scheduled tasks, /loop, or GitHub Actions are better
Rejecting routines is often the correct decision, so the alternative routes deserve the same clarity as the routines branch.
Desktop scheduled tasks are for machine-bound work
If the workflow depends on local files, local applications, or a local browser profile, the decision is usually over before you worry about triggers. Keep the job on the machine. A Desktop scheduled task is the local persistent option because it can see the things your cloud clone cannot, and it remains the cleaner answer when you need a sub-hour local cadence that routines cannot provide. That matters for workflows like local screenshot capture, desktop-app exports, or anything that touches files and tooling that only exist on your workstation.
This is also where many "routines kill cron" takes fall apart. Cron-style repetition is not the important axis by itself. Runtime location is. If the machine owns the dependency, the machine should own the automation.
/loop is for live sessions, not unattended persistence
/loop is lighter than routines because it is smaller in scope. Anthropic's scheduled-task docs describe it as session-scoped scheduling, with recurring loops expiring after seven days. It can run every minute, which makes it much better than routines for short polling or watch work inside an active session. That is a completely different job from "wake up a saved cloud workflow tomorrow morning."
This distinction matters because readers often arrive with the half-formed feeling that /loop and routines are the same thing at different maturity levels. They are not. /loop is what you use when the open session is still the right owner and you only need short-lived repetition. Routines are what you use when the open session is the wrong owner because the work should outlive it.
If your real problem is not unattended automation but prompt fatigue during long local coding sessions, the closer sibling is probably Claude Code Auto Mode, not routines. Auto Mode changes approval behavior inside a live local workflow. Routines change where the workflow runs.
GitHub Actions are for CI-owned automation
GitHub Actions should be treated as a real sibling route, not as the legacy thing routines are replacing. If the automation belongs to repository policy, builds, test gates, scheduled CI maintenance, or audit-friendly logs that the repo should own, GitHub Actions still has the cleaner contract. The logs live where the CI history lives. The permissions live where repo automation permissions live. The workflow remains legible to people who think in CI first.
Routines can still be GitHub-triggered, but that does not make them "better GitHub Actions." It makes them a different execution surface that can wake up from GitHub events. Use that when the repo event is only the wake-up signal and the real value is a cloud Claude Code session. Use GitHub Actions when the workflow itself belongs in CI.
And if you decide to stay local instead of moving to a cloud branch, the next problem is often tool access, not scheduling. In that case the better follow-up is Best Claude Code MCP Servers to Install First, not a deeper routines tutorial.
Current limits, auth, and preview boundaries
Routines are real enough to use, but the current contract still matters. Anthropic's launch post says routines are in research preview and currently include 5 routine runs per day for Pro, 15 for Max, and 25 for Team or Enterprise as of April 16, 2026. The same materials also say routine runs draw from the same subscription usage pool as interactive Claude Code sessions. Treat that as planning data for your workload, not as a reason to hand every recurring job to routines.
The auth model matters just as much because it is easy to assume the API trigger behaves like the rest of Anthropic's API surface. It does not. Anthropic's current /fire docs say the API trigger uses a per-routine bearer token and the experimental anthropic-beta: experimental-cc-routine-2026-04-01 header. That means the trigger is part of the Claude Code routines product surface, not a generic reuse of your workspace API key pattern. If you come in expecting normal Anthropic SDK semantics, you will design the wrong integration.
Trigger setup has its own boundary too. Routines can use schedule, API, and GitHub triggers, and one routine can combine multiple trigger types. But the CLI is narrower than the surface as a whole. Anthropic's docs say claude --schedule creates scheduled routines only. API and GitHub triggers are configured from the web editor. That is exactly the kind of detail that matters once you have already decided routines are the right owner, and exactly the wrong detail to lead with before that decision exists.
There is also one quiet constraint that changes route choice more than it first appears: cloud routines require at least a one-hour interval. If you need minute-by-minute polling, routines are already the wrong answer. That is /loop territory when the session can stay open, or CI territory when the polling belongs in repo automation. Treat this as a route boundary, not as a minor footnote.
If you need the broader plan and usage ladder behind these caps, read the full Claude Code pricing guide. For route choice, the key point is simpler: preview caps and shared usage pools should shape which jobs you hand to routines first.
A safe first routine to build
The best first routine is boring on purpose. It should be narrow enough that you can judge the value quickly, and safe enough that a wrong guess does not create cleanup work across three systems.
One good starting pattern is a morning repo triage routine:
- Give it one repository, not five.
- Start with the schedule trigger only, not API plus GitHub plus schedule on day one.
- Ask it to review stale issues, open PRs, and failing checks, then produce a short summary or a branch-scoped draft action list.
- Keep pushes bounded to the default branch restrictions instead of opening unrestricted write behavior immediately.
That pattern is good because it proves the one thing routines are supposed to prove: cloud persistence that does useful repo work while you are away. It does not depend on a local machine. It does not pretend CI should disappear. And it lets you evaluate whether the cloud branch is genuinely useful before you build a more ambitious automation stack on top of it.
The bad first routine is usually the same shape in reverse: too many repos, too many triggers, too much write power, and too much faith that "automation" means one surface should own everything. Start with one bounded workflow, let the surface prove itself, and only then widen the contract.
FAQ
Are routines the same as /schedule or scheduled tasks?
No. routines is the broader current surface name. Anthropic's docs still expose older scheduled-task wording, but the current umbrella includes schedule, API, and GitHub triggers. The CLI --schedule path creates only the scheduled kind, not the whole trigger surface.
When should I use Desktop scheduled tasks instead?
Use Desktop scheduled tasks when the job depends on local files, local apps, a local browser, or any machine-bound state. If the machine is the dependency, the automation should stay on the machine.
When is /loop enough?
/loop is enough when the work belongs to the current Claude Code session and only needs short-lived repetition. It can run every minute, but it is session-scoped and recurring loops expire after seven days. That makes it a live-session tool, not a cloud persistence tool.
Do routines replace GitHub Actions?
No. GitHub Actions remains the better route when the workflow belongs to CI, repo policy, build automation, or audit-friendly pipeline logs. Routines are a sibling route, not an automatic upgrade path.
How does the routine API trigger authenticate?
Anthropic's current docs say the routine API trigger uses a per-routine bearer token plus the experimental anthropic-beta: experimental-cc-routine-2026-04-01 header. It is not the same auth model as a normal Anthropic API-key integration.
What are the current daily routine-run limits?
As of April 16, 2026, Anthropic's launch announcement lists 5 included routine runs per day for Pro, 15 for Max, and 25 for Team or Enterprise. Treat those as research-preview facts checked on that date, not as timeless limits.
The useful question is who should own the runtime
Routines are worth learning because they add a real new branch to Claude Code automation. They are the cloud branch. That is the part to remember.
Everything else follows from that. If your workflow should keep running in a cloud clone after you step away, routines are the cleanest new option in Claude Code. If the job belongs to your machine, to your live session, or to CI, another owner is better. Once you frame the problem that way, routines stop looking like a universal scheduler and start looking like one clear branch in a larger automation stack.