What Are Claude Code Routines?

What Are Claude Code Routines?

A routine is a saved Claude Code setup that runs on its own, and the first thing to know is that Anthropic no longer calls it a routine.

Its documentation page now carries the heading "Automate work with scheduled tasks" and opens by telling you to "Create scheduled tasks, formerly routines, that run in the cloud on a schedule, on API calls, or on GitHub events."

The old name has not vanished, though. It survives in a slash command, a URL, an admin toggle and the launch announcement, which is exactly why people still search for it.

This guide covers what the feature does, where the word "routines" still appears, the three unrelated things now sharing the name "scheduled tasks", and the limits that two Anthropic pages describe differently.

What Are Claude Code Routines?

They are saved, unattended Claude Code runs. Anthropic's current definition is that "A cloud scheduled task, formerly a routine, is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically."

The practical shape is this. You write the prompt once. You attach the repositories and connectors it needs. You pick what sets it off. Then it runs without you, and each run becomes a session you can read afterwards.

Cloud runs happen on Anthropic-managed infrastructure, or on an organization's self-hosted environment when routed there. Your laptop does not need to be on.

Free SEO + AI Search Audit. Find out whether your site is visible in Google and in AI search engines like ChatGPT, Claude and Perplexity. Run your free audit in 60 seconds.

Where Does the Word "Routines" Still Appear?

In more places than you would expect from a completed rename, which is useful to know when you are searching for help.

The places that still say routines

The documentation URL is still /docs/en/routines, even though the page it serves is titled for scheduled tasks. The web interface lives at claude.ai/code/routines.

In the CLI, the command is /schedule, and the docs note that "The command is also available under the alias /routines". So the old command still works.

For Team and Enterprise administrators, the setting is labelled "Scheduled tasks (Was Routines)", which is the clearest signal that Anthropic expects the old name to stay in circulation.

The April 2026 launch announcement still uses "routines" as the product name throughout and was not retitled. Nothing I could find gives a date for the rename itself.

What the rename does not mean

It is not a deprecation. There is no sunset notice, no removal date and no migration step on any of the pages involved.

This matters because a renamed feature and a withdrawn feature look similar in search results, and plenty of third-party articles about "routines" are now describing an interface with different labels. The feature is alive; the vocabulary moved.

Three Different Things Are Called Scheduled Tasks

This is the genuinely confusing part, and it is worth separating before you read any documentation page, because the URL slugs do not match the names.

Cloud scheduled tasks, formerly routines

These are the subject of this article. They run in Anthropic's cloud, they do not need your machine on, and the documentation describes their repository access as a fresh clone rather than your local files.

Desktop local scheduled tasks

A separate feature that runs on your own machine with direct access to your files and tools. The trade-off is stated plainly: it "only fires while the app is open and your computer is awake."

If the computer sleeps through the scheduled time, the run is skipped. Missed runs catch up once within seven days. This path requires Claude Desktop 1.1.5368 or later.

Session-scoped tasks with /loop

A third thing entirely: repeated prompts inside a single running Claude Code session, driven by /loop and the cron tools. These are documented at /docs/en/scheduled-tasks, which is the slug you would have guessed was the cloud feature.

These have their own rules. Recurring tasks "automatically expire 7 days after creation", and "A session can hold up to 50 scheduled tasks at once."

Free SEO + AI Search Audit. See how your site performs in traditional search and in AI assistants like ChatGPT and Claude. Get your free audit in under a minute.

How Do You Create One?

Two routes, and the plan requirement is the same for both.

1. From the web, at claude.ai/code/routines, where you configure the prompt, repositories, connectors and trigger in a form.
2. From the CLI, with /schedule, which also accepts a one-off instruction in plain language and then confirms it back to you as an absolute timestamp.

For the schedule itself you can take a preset of hourly, nightly or weekly, choose a single future time, or write a cron expression such as 0 */2 * * *.

Two timezone details are easy to get wrong. Presets take the time in your local timezone. A bare five-field cron expression is read in UTC, so the docs note that 0 9 * * 1-5 runs at 9:00 AM UTC on weekdays. A CRON_TZ= prefix is honoured if you want local time in a cron.

One scheduling quirk is documented and worth designing around: runs set exactly on the hour "can start several minutes late". If something downstream depends on precise timing, do not assume punctuality.

Free SEO + AI Search Audit. Before your next content push, see how your site performs in traditional search and in AI assistants. Get your free audit in under a minute.

What Can Trigger a Run Besides the Clock?

Two other things, and they are what lift this past a cron job.

An API call. Each task gets a /fire endpoint you can POST to with a bearer token, optionally passing a text field to hand that single run some extra context. The response includes a claude_code_session_url so you can read what happened.

GitHub events. A task can fire on pull request activity, releases or issues. Pull request triggers can be filtered on author, title, body, base and head branch, labels, draft status and merge status.

Both of these are gated on recent versions if you drive them from the terminal: adding a GitHub trigger from the CLI needs Claude Code v2.1.225 or later, and reading run history from the CLI needs v2.1.227 or later. Those version gates are a good sign, incidentally — they indicate active development rather than a feature being quietly parked.

What Permissions Does an Unattended Run Have?

This is the most important section for anyone about to automate something consequential.

You do not choose a permission mode when you create the task. Cloud runs start in auto mode unless auto mode is unavailable, with a classifier checking actions before they execute. Our guide to Claude Code auto mode covers what that classifier does and does not stop.

A run can still halt. If an action matches an ask rule, or if the classifier blocks actions repeatedly, a prompt appears in the run's session and waits until someone answers it. An unattended run that needs an answer simply stops and waits.

Anthropic is explicit about what a firing does not amount to, and the wording deserves quoting: the trigger "attests only that the prompt was stored ahead of time" and "The fired prompt is therefore not live user input and can't act as approval or consent for actions during the run."

Text passed into the API endpoint is wrapped in a payload block labelled as untrusted, and runs started from the API or from GitHub always ask before publishing artifacts.

For output, each run creates branches prefixed with claude/ for its changes, and Claude can open a pull request from the session rather than pushing to anything you rely on.

Limits, and Where the Numbers Disagree

Treat every number here as something to check on the live page rather than something to memorise, because the published figures do not currently agree with each other.

The minimum interval for a cloud task is one hour, and the docs state that "Expressions that run more often than once per hour are rejected." Desktop local tasks go down to one minute when Claude sets them. Session /loop tasks also go to one minute.

On how many runs you get, there is a real conflict. The April 2026 launch post gave per-day caps by plan: 5 for Pro, 15 for Max, and 25 for Team and Enterprise, with extra runs available through extra usage. The current documentation instead describes hourly caps, applied both per task and per account.

I am not going to restate the hourly figures here, because the two sources describe different units and the feature is explicitly subject to change. Read the current page before you build a schedule against a number.

What is clear in both places is that runs consume your normal allowance. Scheduled runs "count against your account's usage and limits", and the launch post said routines draw down subscription limits the same way interactive sessions do.

Also documented: GitHub webhook events are subject to per-task and per-account hourly caps, and "Events beyond the limit are dropped until the window resets." Dropped, not queued.

Several things a reader would reasonably want are simply not published on these pages: there is no dollar price, no stated maximum number of tasks, no stated run duration, no concurrency figure and no service level commitment.

Free SEO + AI Search Audit. Automating your reporting is only worth it if the underlying pages rank. Start your free audit and see where you stand.

Limitations Worth Knowing Before You Rely On It

Five caveats, each from Anthropic's own pages, and each capable of silently breaking an automation you thought was working.

It is a research preview. The documentation says so directly: "Scheduled tasks are in research preview. Behavior, limits, and the API surface may change." The /fire endpoint ships behind an experimental beta header.

A lapsed GitHub connection kills the task eventually. If the connection is missing or expired, the task skips runs for up to 72 hours, and after 72 hours without a connection it turns off. Nothing restarts it for you.

Local MCP servers do not come along. Servers added with claude mcp add do not appear in the connectors list, so a prompt that depends on one will not have it in a cloud run.

Network access is restricted by default. The default environment is Trusted, and requests outside the allowlist fail with a 403 and an x-deny-reason of host_not_allowed. A scraping or API-polling task needs the allowlist sorted first.

Administrators can switch the whole thing off. When the Team or Enterprise toggle is off, existing scheduled tasks stop running and members cannot create new ones.

One contradiction is worth flagging because it affects how you design GitHub automations. The launch post says Claude opens one session per pull request and continues feeding that PR's updates into it. The current documentation says the opposite: sessions are not reused across events, so two PR updates produce two independent sessions. Build for the documented behaviour.

Final Thoughts

Routines are real, actively developed, and now called scheduled tasks. If you are searching the old name you are not looking at a dead product, just an older label.

The feature is strongest where the work is genuinely repetitive and the output is reviewable: a nightly dependency check that opens a pull request, a weekly report, a triage pass on new issues. The branch-and-PR default fits that shape well.

It is weakest where you need precision or guarantees. A research preview with shifting limits, no published SLA, hourly caps that drop excess events and a documented habit of starting late is not the place for anything time-critical.

Set one up for something low-stakes, read the run history for a week, and check the limits page before you depend on a number. Then decide what else is safe to hand over.