Claude Code Routines: Scheduled, API and GitHub-Triggered Agents in the Cloud
Routines are saved Claude Code tasks — a prompt, repositories and connectors — that run on Anthropic's cloud or an organization's self-hosted environment. How to create one with /schedule or the web, use schedule, API and GitHub triggers, and manage limits and security.
A routine is a Claude Code task you configure once and let run by itself: a prompt, one or more GitHub repositories, an environment and a set of connectors. Routines run on Anthropic-managed cloud infrastructure, or an organization's self-hosted environment when routed there. They can keep working when your laptop is closed, provided the selected infrastructure remains available.
Routines are a research preview as of October 2026; behaviour and limits may change. Details below are from Anthropic's routines docs.
The three triggers
A routine can have any combination of:
- Schedule — hourly, nightly, weekdays, weekly, a custom cron (minimum interval: one hour), or a one-off run at a specific time.
- API — an HTTP endpoint you POST to with a bearer token, so your monitoring or deploy pipeline can start a run.
- GitHub event — pull requests (opened, labeled, merged…) and releases, with filters on author, branch, labels, title, draft status and more.
A single routine can, for example, review PRs nightly, run when your deploy script calls it, and react to every new PR.
Creating one
From the CLI, describe it:
/schedule daily PR review at 9am
/schedule in 2 weeks, open a cleanup PR that removes the new-checkout feature flag
Claude asks follow-up questions (repos, prompt, schedule) and saves the routine to your claude.ai account. /schedule list, /schedule update and /schedule run manage existing ones. You can also create and edit routines at claude.ai/code/routines or in the desktop app.
/schedule requires a claude.ai subscription login (Pro, Max, Team or Enterprise) — it's hidden if you're signed in with an API key or a cloud provider.
How a run works
Each run is a full Claude Code cloud session:
- Your repositories are cloned fresh, normally from the default branch. A GitHub pull-request trigger can use the PR's head commit for the first repository; the prompt can also specify another branch.
- The environment's setup script and network policy apply.
- Claude carries out the saved prompt autonomously for shell commands and connector tools. Some artifact publishing actions still require approval.
- Changes go to
claude/-prefixed branches; Claude can open pull requests.
Every run appears as a session you can open, read and continue. A green status only means the session ran without an infrastructure error — read the transcript to see whether the task succeeded.
Writing the prompt
Because nobody is there to answer questions, the prompt has to be self-contained:
Review every PR opened in the last 24 hours that isn't a draft.
For each: run the test suite, check for missing tests on changed code,
and leave one summary comment with findings ranked by severity.
Don't push commits. If there are no new PRs, do nothing.
State what success looks like and what Claude must not do.
The API trigger
After saving, add an API trigger on the web to get a URL and a token (shown once). Then:
curl -X POST "$ROUTINE_URL" \
-H "Authorization: Bearer $ROUTINE_TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'
The text arrives wrapped and labelled as untrusted data. Your routine's prompt must explicitly say to act on it ("investigate the alert in the routine-fire-payload block"), otherwise Claude treats it as inert context. That protects you if the token leaks.
Security: think before you include things
Routines act as you through your connected GitHub identity and connectors; self-hosted deployments can instead provide their own git credentials. Shell commands and connector writes run without approval prompts, so:
- Remove connectors the routine doesn't need. All connected connectors are included by default, and Claude can use every tool in them, including writes.
- Scope network access in the environment to what's required.
- Use branch protection so a routine can't push to
main. - Store API keys as network secrets, not plain environment variables, on Pro and Max.
(Prompt Injection in Coding Agents)
Limits
- Runs draw down your subscription usage like interactive sessions.
- Scheduled runs: 100 per hour per account. Run now / API fires: 30 per hour per routine.
- If GitHub access lapses, runs are skipped for up to 72 hours, then the routine turns off.
Routines vs /loop vs desktop scheduled tasks vs GitHub Actions
| Routines | /loop |
Desktop scheduled tasks | GitHub Actions | |
|---|---|---|---|---|
| Runs on | Anthropic cloud or configured self-hosted environment | Your open session | Your machine | GitHub-hosted or self-hosted runners |
| Needs your machine on | No for managed cloud; self-hosted runner must stay available | Yes | Yes | No for hosted runners; self-hosted runner must stay available |
| Local files | No (fresh clone) | Yes | Yes | No |
| Minimum interval | 1 hour | 1 minute | 1 minute | 5 minutes |
(Claude Code /loop, Claude Code GitHub Actions)
Good first routines
- Nightly: triage new issues and label them.
- On PR opened: apply your team's review checklist.
- Weekly: find docs that reference changed APIs and open update PRs.
- On deploy (API): smoke-test production and post go/no-go.
The summary
- Routines are saved Claude Code tasks that run in the cloud on schedules, API calls or GitHub events.
- They run autonomously, as you — trim connectors and protect branches.
- Create with
/scheduleor at claude.ai/code/routines.
EasySpawn gives Claude Code a persistent server of its own, so long-running and scheduled work has your app, database and files right there — no fresh clone each time. See how it works or join the waitlist.
Related: Running Claude Code Headless · Claude Code Hooks · Review AI-Generated Pull Requests · Cron Expressions Explained
Keep reading
MCP Transports: stdio vs Streamable HTTP (and What the 2026 Spec Changed)
MCP servers talk to clients over stdio (a local subprocess) or Streamable HTTP (a remote endpoint). How each works, when to choose which, how to add both to Claude Code, why the old HTTP+SSE transport is deprecated, and what the stateless 2026-07-28 specification means for building and hosting HTTP servers.
Claude Code /goal: Keep Claude Working Until the Job Is Actually Done
/goal sets a completion condition and Claude keeps taking turns until a separate model confirms it's met — no prompting each step. How to write conditions the evaluator can verify, how evaluation and check-ins work, combining it with auto mode, running it headless, and when to use /loop or a Stop hook instead.