Anthropic now sells two different ways to put Claude on a schedule and walk away: routines inside Claude Code, and scheduled tasks inside Claude Cowork. Both boil down to the same pitch — write a prompt once, set a cadence, get the work back without opening a chat window. That similarity is exactly why teams keep asking which one they're supposed to use, and the honest answer is that the pitch is the only thing they share. The two features are built for different people doing different jobs, and picking the wrong one is how a team ends up either fighting a GUI to do a git-native job, or writing YAML to do a job a form would have handled in five minutes.
Claude Code Routines: automation that lives in a repo
A routine is a saved Claude Code task — a prompt, a connected GitHub repository, and a set of tools and connectors — that runs on Anthropic's own cloud infrastructure rather than on anyone's laptop. That last part matters operationally: a routine keeps firing on its schedule whether or not the engineer who configured it is at their desk, because nothing about the run depends on a local machine staying on. Routines support three trigger types: a recurring schedule (hourly, nightly, weekly, or a one-time future run), an API call (a bearer-token POST to a per-routine endpoint, for triggering from another system), and GitHub events such as a pull request or a release. Run volume is capped by plan — Pro, Max, and Team/Enterprise accounts get different daily allowances — and the whole thing requires Claude Code on the web to be enabled in the first place. The pipeline that drafted and is about to publish this post is a routine in exactly this sense: a checked-in prompt, a GitHub repository, and a schedule, with the run itself happening in an isolated cloud session rather than on anyone's machine.
Claude Cowork's scheduled tasks: automation that lives in the desktop app
Cowork's scheduled tasks solve a version of the same problem for people who don't want a terminal in the mix. Cowork itself is a tab in the Claude desktop app built for knowledge work over files, folders, and other applications rather than code. Setting up a scheduled task means typing /schedule inside an existing task, or building one from the sidebar with a name, description, prompt, frequency (hourly, daily, weekly, weekdays, or on demand), a model choice, and a working folder — all through a form, not a config file. Connectors get installed from a browse-and-click marketplace inside the app rather than wired up by hand. Cowork's scheduled tasks now run in the cloud as well, so a task keeps its cadence even with the desktop app closed or the computer asleep — the same "doesn't need your laptop on" property routines have, arrived at from the opposite direction.
Where the two actually diverge
Strip away the "both run Claude on a timer" framing and the differences are about who configures the automation and what it's allowed to touch. A routine's configuration is code: the prompt and its connectors live in files a team can review, diff, and roll back with ordinary version control, and its trigger surface includes API calls and GitHub webhooks that only make sense against a repository. A Cowork scheduled task's configuration is a form filled out in an app, aimed at a person's own files, folders, and installed connectors — there's no pull request to review, because there's no repository the task is changing. Neither is a lesser version of the other; they're built against different assumptions about who's doing the configuring and what "done" looks like.
Which one belongs under a publishing pipeline
For a content operation, the deciding question isn't speed or output — it's where the audit trail needs to live. A pipeline that has to prove what it did (which topic it picked, which credentials it used, what it published, and when) benefits from a routine's git-native shape: the run's own prompt and logic are reviewable the same way the content it produces is reviewable, and quality gates can be enforced as code rather than as a setting someone has to remember to check. A one-off recurring task over a shared drive or a folder of client files — the kind of thing a single marketer owns and wants to tweak without filing a pull request — is exactly what Cowork's scheduled tasks are for instead. The two aren't competing for the same job; they're each the better tool for a job the other one wasn't built to do.