Anthropic shipped Claude Routines on April 14, 2026. Cloud-side automation. Schedule a job, hit it via HTTP, fire it on a GitHub event. The runs happen on Anthropic infrastructure, against a fresh clone of your repo. Public coverage of Routines treated it as a strict upgrade over Desktop Scheduled Tasks. It is not. Three of the things we currently run on Desktop, the parent's gws-multi.sh healthcheck, the vault-sync cadence, the infra-improver weekly brief, would all silently fail on Routines for the same reason. None of them can see the local credentials they need. None of them can see the uncommitted notes they read from. None of them can call the local MCPs they depend on.
The right way to think about Routines is not as a replacement for Desktop. It is as a fourth slot in a routing decision matrix that already had three slots, plus one we hadn't named. Cron at the OS level. /loop inside a Claude Code session. Desktop Scheduled Tasks via the scheduled-tasks MCP. And now Cloud Routines on Anthropic's side. Each one is the right answer for a specific job class. None of them is the right answer for every job.
The four slots
Cron at the OS level is for jobs with no AI in them. The vault sync that runs every fifteen minutes via launchd. The disk-snapshot. The cleanup of old downloads. These are pre-AI infrastructure that does not need a model. Cron is faster, cheaper, and more reliable than any AI-aware scheduler for jobs that just need to fire and run a shell script. Most stacks have a few of these. They do not move.
/loop inside an active Claude Code session is for self-paced iterations that benefit from session context. The work is "keep doing this every five minutes until the deploy is green." The model already knows what the deploy looks like, what success means, what the failure modes are. /loop is the cheapest way to express that, because the polling and the action are inside the same session, and the session context is the spec. /loop is wrong for cross-session work. The session ends, the loop ends.
Desktop Scheduled Tasks are for jobs that need local context. The credentials in .gws-accounts.json. The uncommitted notes in research/external/ that the infra-improver agent reads from. The MCPs registered in your local ~/.claude/ directory. Every one of these is invisible to a cloud runner. Desktop Scheduled Tasks run on your machine, with your environment, with your full .claude/ configuration. The cost is that they only run when your machine is on. For most operators, that is fine. For some, it is not.
Cloud Routines are for jobs that need none of the above. The full input is captured in the committed repo. The output is a GitHub PR or a Slack post. The job is something an external collaborator could run. The wiki-lint we run weekly is a clean fit. It reads only committed files. It writes a PR with the audit. There are no creds beyond the GitHub token. The work is repeatable from a fresh clone, by definition. Cloud Routines run regardless of whether your laptop is on.
The decision rule
A job belongs in Cloud Routines if and only if all four of these hold. The repo at HEAD is sufficient input. The output is a GitHub artifact (PR, release, comment). The credentials are in the GitHub or Anthropic side, not the local side. The work does not depend on local MCPs.
If any of those fails, the job belongs on Desktop or in a session. The temptation will be to push more work to Cloud because Cloud means "runs even when laptop is closed." That is a real benefit, but it does not change the input requirements. A job that needs local creds cannot run in the cloud, even if you really wish it could.
What we are actually doing
This week's TODO entry from the brief was: port wiki-lint-weekly to Cloud Routines, document why no other scheduled task moves. We are doing both. The wiki-lint port is the proof of pattern. The decision matrix is this article. The other tasks (gws-healthcheck, infra-improver, the various beeks-refresh-* runs) all fail at least one of the four conditions. They stay on Desktop.
The decision matrix is the publishable artifact. Most of what gets written about Cloud Routines treats them as a tier-up from Desktop, the way SaaS used to be treated as a tier-up from on-prem. The framing is wrong because the inputs are different. Cloud Routines is a different shape, and the four-slot matrix tells you which shape your job fits. Use the slot the job fits, not the slot that sounds most modern.
What to do this week
If you have scheduled tasks running on a stack like ours, run the matrix against each one. Cron stays cron. /loop stays inline. Desktop stays Desktop unless all four cloud conditions hold. For the jobs that pass all four, port one of them to Cloud Routines as a proof. Document why no other job moves. The decision matrix is more useful than any single port, because it tells you the shape of every future scheduled task you will write.
Daily limits to know about. Pro accounts get five Routine runs per day. Max gets fifteen. Team and Enterprise get twenty-five. These are budgeting constraints, not capacity ones. If you find yourself trying to push more than fifteen jobs per day to Routines, the matrix is telling you that some of them belong elsewhere.