Claude Code routines are scheduled cloud agents: a saved prompt that runs on Anthropic's cloud, on a schedule you set, with no one in the loop. If you already use Claude Code in your terminal, a routine is the same agent, parked off your machine and triggered on a clock, an API call, or a GitHub event. People search for this under a few names, "claude code routines", "claude routines", "claude code scheduled tasks", and they all mean the same feature, which shipped in April 2026 and is still a research preview. This guide defines the model, walks the setup, and gives you the decision framework most of the early coverage skips: when a routine is the right tool, and when it is the wrong one.
I run a routine against production every six hours. I will link to that worked example below. But the example only makes sense once you have the model straight, so let me start there.
What are Claude routines?
What are Claude Code routines?
Claude Code routines are scheduled cloud agents that run a defined prompt autonomously on Anthropic-managed cloud infrastructure, not your local machine. Each run starts a fresh, isolated session with zero prior context, uses the repositories, tools, and MCP connectors you grant it, and reports back when it finishes. Use a routine for recurring, rule-based work that is worth doing whether or not you remember to do it.
Three properties define a routine, and they are the three things a plain Claude Code session is not:
- It runs in the cloud. A routine executes on Anthropic-managed infrastructure, so it keeps running when your laptop is closed. This is what separates it from a terminal session, and it is the single fact most people want confirmed first: yes, routines run when your computer is off.
- It runs on a trigger, not on your keystrokes. You do not start a routine by typing. A schedule, an API call, or a GitHub event starts it.
- It is stateless per run. Every execution begins fresh with no memory of the last one. A routine cannot lean on context you built up earlier, which is liberating (no drift) and demanding (the prompt has to carry everything).
The mental model that makes the rest of this click: a routine is a saved prompt, plus the repositories it can touch, plus the connectors it can reach, parked on Anthropic's cloud and wired to a trigger. Same agent as your terminal, scheduled and remote and amnesiac. Everything else is configuration.
The three triggers (the part most guides miss)
Almost every write-up I have read treats routines as a cron feature and stops there. They are not. A routine can start three different ways, and picking the right trigger is half of designing a good one.
| Trigger | Fires when | Reach for it when |
|---|---|---|
| Scheduled | A cron expression you set elapses (minimum one hour between runs) | Work that runs on a clock: a morning brief, periodic log triage, a weekly dependency audit |
| API | You call the routine on demand from your own code | Event-driven work where your application decides the timing, not a fixed clock |
| GitHub | A repository event happens (a push, a pull request, an issue) | Code-reactive work: review an incoming PR, triage a new issue, check a fresh push against your rules |
The scheduled trigger is the one people mean by "claude code schedule" or "claude code scheduled tasks", and it is the most common. But the API and GitHub triggers are why "routine" is a broader idea than "cron job for Claude". A GitHub-triggered routine that reviews every PR against your AGENTS.md is not on a clock at all. It reacts.
How to set up a Claude Code routine
You can create a routine from three surfaces, and they all write to the same cloud account, so a routine you start in the terminal shows up on the web and vice versa.
- Open a creation surface. Run
/schedulein the Claude Code CLI, or open the Desktop app and choose New routine, then Remote, or go to claude.ai/code/routines on the web. - Describe the task. Write or paste the prompt the routine will run on every execution. This is the whole job description, so be explicit about scope and limits.
- Pick the repositories. Choose the repo, or repos, the routine can read and work in.
- Add connectors. Grant the MCP connectors it needs, such as GitHub, Slack, or ClickUp, so it can reach the systems it has to act on.
- Choose the trigger. Set a cron schedule (minimum one hour), an API trigger, or a GitHub event.
- Pick the model. Select the model that runs every execution. You can change it later.
- Save. The routine now runs unattended and reports back when it finishes.
That is the entire flow, and it genuinely takes about five minutes. A scheduled routine looks like 0 */6 * * * for "every six hours". The minimum interval is one hour; a cron expression that asks for anything more frequent is rejected. The value is never in the setup. It is in the judgment you encode into step 2 and the boundaries you set, which is what the rest of this guide is about.
When to use a routine, and when not to
This is the question the early coverage answers worst, and it is the one an AI assistant gets asked most: routine versus cron versus subagent versus Managed Agent versus an interactive session. Here is how I separate them.
| Tool | What it is | Reasons about context? | How it starts | Best for | Avoid when |
|---|---|---|---|---|---|
| Cron job / shell script | Fixed, deterministic steps on a server you run | No | A clock on your own infrastructure | Backups, syncs, deterministic jobs with zero judgment | The task needs to read a situation and decide |
| Interactive Claude Code | The agent in your terminal, you steering | Yes | You type | One-off and exploratory work where you want to react turn by turn | The work recurs and you keep redoing it by hand |
| Subagent | A scoped agent (.claude/agents/) with its own context, tools, and model | Yes | The parent agent delegates to it | Splitting a larger interactive task into focused, parallel pieces | You need it to run on its own, on a schedule, off your machine |
| Claude Code routine | A scheduled cloud agent running a saved prompt | Yes | Scheduled, API, or GitHub trigger | Recurring, rule-based work that should propose changes unattended | The task is one-off, needs mid-run steering, or has no clear output contract |
| Managed Agent (Agent SDK) | A long-running agent you build and deploy with the Agent SDK | Yes | Your own deployment and triggers | Custom, always-on products with bespoke control and billing | You just need a recurring task and do not want to build and host an app |
A few rules of thumb fall out of that table:
- If a deterministic script can do it, use the script. Do not pay an LLM to reason about something with no decision in it.
- If you are still figuring out the task, stay interactive. Promote it to a routine only once the steps and rules are stable enough to write down.
- A subagent and a routine are easy to confuse. The line is simple: a subagent runs inside an interactive session you started, a routine runs on its own in the cloud. Subagent is a composition tool; routine is a scheduling tool.
- Reach for the Agent SDK and Managed Agents when you are building a product, not automating a chore. If your need is "run this useful thing on a schedule", a routine is lighter and you do not host anything.
If you are unsure between a routine and an interactive session: ask whether you would be comfortable with the task running while you are asleep. If the honest answer is no, it is not a routine yet. Tighten the prompt and the output contract until the answer is yes.
The security and trust model
Handing an autonomous agent your repository and your connectors is the part that should make you pause, and it is the part the content farms wave away. A routine run is a full cloud session: it can run shell commands, use skills, and call your connectors, and there is no permission prompt mid-run. No human clicks "approve" while it works. That is the whole point (unattended) and the whole risk (unattended).
So the trust model is not "watch it closely". You cannot. The trust model is "build boundaries it cannot cross", and Claude Code ships with the most important one as a default.
The default that makes this safe: the `claude/` branch boundary
By default, a routine can only push to branches prefixed with claude/. It cannot push to main and it cannot deploy. Its most powerful action is opening a pull request against a branch that does not ship on its own, where a human gates the merge. There is a setting to allow unrestricted branch pushes. Leave it off. This single boundary is what lets you point a scheduled agent at production and still sleep.
The principle behind that default, and the one I apply to every routine I build, is propose, do not perform. A pull request is a proposal. A filed task is a proposal. A Slack summary is a proposal. A merge, a deploy, a closed ticket, a message to a customer: those are actions, and actions stay on the human side of the line. Give the routine wide room to investigate and propose, and no ability to do anything irreversible.
Two more rules earn their place:
- Fail loud. When the routine is missing an API token, or a query returns an auth error, it should stop and post the failure, not guess and carry on. An agent that improvises when it lacks data is worse than one that does nothing.
- Scope the connectors. Grant only the connectors a routine needs, with the narrowest access that still lets it do the job. A read-only token is a feature, not a limitation.
I put all of this into practice in a routine that triages production exceptions every six hours. It reads my Cloudflare Workers logs, diagnoses each error against the codebase, and then either opens a PR against a non-deploying branch, files a ClickUp task and tags me, or posts an all-clear to Slack. The full prompt, the exact API calls, and the output contract are in how I automate real work with a Claude Code routine. Read it as the worked example of every principle in this section.
Cost and models
Routines bill the same way an interactive session does: against your subscription usage. They are available on Claude Pro, Max, Team, and Enterprise plans, and a run draws down the same token budget your terminal sessions use. There is no separate server cost, because there is no server you rent. That is the headline the "no computer required" posts get right.
The real cost lever is the model, and it is one of the setup steps for a reason. Every routine has a model selector, and the model you choose runs on every execution. So a cheap, frequent check (an hourly "is anything on fire" glance) should probably run on a fast, inexpensive model like Haiku, while a run that has to reason carefully about code is worth Opus 4.8 and its 1M-token context. You can change the model anytime. Two dials set your spend: the model and the cadence. Cadence times scope times model is roughly your bill, so do not run an Opus routine every hour across ten repos unless the output is worth it.
Managed Agents built on the Agent SDK bill differently, and this is the other half of the "routine versus Managed Agent" decision. They charge per-token usage plus a metered hourly runtime fee, billed only for active time with idle excluded. For a recurring chore, a routine on your existing subscription is almost always cheaper and simpler. For an always-on product, the Agent SDK's billing and control may be worth it.
Research preview: verify before you budget
Routines shipped in April 2026 and are still a research preview, so limits, surfaces, and pricing can change. I have verified the facts here against the official docs at code.claude.com/docs as of June 2026, but check the current routines and costs documentation before you commit a workflow or a budget to it.
Routine archetypes worth automating
The triage routine is one shape. The same contract, stable input in, judgment in the middle, a proposal out, fits a lot of recurring work. A few I either run or plan to:
- Exception and log triage. Read production errors on a schedule, diagnose against the codebase, open a PR for the obvious fixes and file tasks for the rest. This is the worked example I keep pointing to.
- Dependency triage. Weekly, read the lockfile diff and changelogs, open a PR for safe patch bumps, file a task for anything with breaking changes.
- Daily SEO reporting. Every morning, pull ranking and traffic changes, summarize what moved and why, and flag pages that dropped. I am writing this one up as its own guide: automate SEO reporting with a Claude Code routine (forthcoming).
- PR hygiene. A few times a day, find pull requests that are stale, missing a description, or failing CI, and nudge with a comment.
- Docs drift. Weekly, diff recent code changes against the docs and open tasks where they disagree.
Each one gathers, judges against rules you wrote, and proposes rather than acts. If you cannot describe the rules and the output contract in a paragraph, it is not ready to be a routine.
Quick Recommendation
Claude Code routines are best for:
- Recurring, rule-based work worth doing on a schedule whether or not you remember
- Tasks where a proposal (a PR, a task, a summary) is more useful than a raw alert
- Code-reactive checks via the GitHub trigger, like reviewing every PR against your rules
Skip routines if:
- The task is one-off, exploratory, or needs you steering it mid-run (stay interactive)
- A deterministic cron script already handles it with no judgment required
- You are building an always-on product with custom control (use the Agent SDK)
- You are not willing to write a strict output contract, because an unbounded routine becomes noise you mute within a week
My pick: start with one read-only routine that only files tasks and posts to Slack, run it for a week, and grant write access (PRs against a claude/ branch) only once you trust its judgment. Earn the access incrementally, exactly like you would with a new hire.
Frequently Asked Questions
What are Claude Code routines?
How are Claude routines different from a cron job?
Do Claude Code routines run when my computer is off?
How much do Claude Code routines cost?
Is it safe to give a routine access to my repository?
Why does my routine push to a claude/ branch instead of main?
What models can run a Claude routine?
What is the minimum schedule interval for a routine?
Next steps
A routine is only as good as the codebase it reasons about, so start with the foundations: our Claude Code best practices guide covers the AGENTS.md rules, MCP servers, and subagents that make any agent reliable. If you want the interactive version of this workflow before you automate it, see how to build a SaaS with Claude Code, and for where routines fit among the other AI coding tools, read the best AI for coding in 2026. When you are ready for a concrete build, the production triage routine walks through one end to end.
MakerKit ships with the AGENTS.md rules and MCP setup that make routines like these dependable out of the box, because the structure you encode once is what a scheduled agent leans on every run. Get the codebase right, and the schedule does the rest.