Claude Code Routines: The Complete Guide to Scheduled Cloud Agents (2026)

What Claude Code routines are, the three triggers that start them, how to set one up, and when a routine beats a cron job, a subagent, or a Managed Agent.

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.

TriggerFires whenReach for it when
ScheduledA 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
APIYou call the routine on demand from your own codeEvent-driven work where your application decides the timing, not a fixed clock
GitHubA 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.

  1. Open a creation surface. Run /schedule in 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.
  2. 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.
  3. Pick the repositories. Choose the repo, or repos, the routine can read and work in.
  4. 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.
  5. Choose the trigger. Set a cron schedule (minimum one hour), an API trigger, or a GitHub event.
  6. Pick the model. Select the model that runs every execution. You can change it later.
  7. 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.

ToolWhat it isReasons about context?How it startsBest forAvoid when
Cron job / shell scriptFixed, deterministic steps on a server you runNoA clock on your own infrastructureBackups, syncs, deterministic jobs with zero judgmentThe task needs to read a situation and decide
Interactive Claude CodeThe agent in your terminal, you steeringYesYou typeOne-off and exploratory work where you want to react turn by turnThe work recurs and you keep redoing it by hand
SubagentA scoped agent (.claude/agents/) with its own context, tools, and modelYesThe parent agent delegates to itSplitting a larger interactive task into focused, parallel piecesYou need it to run on its own, on a schedule, off your machine
Claude Code routineA scheduled cloud agent running a saved promptYesScheduled, API, or GitHub triggerRecurring, rule-based work that should propose changes unattendedThe 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 SDKYesYour own deployment and triggersCustom, always-on products with bespoke control and billingYou 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 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.

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?
Claude Code routines are scheduled cloud agents that run a defined prompt autonomously on Anthropic-managed cloud infrastructure rather than your local machine. Each run starts a fresh, isolated session with the repositories, tools, and MCP connectors you grant it, and reports back when finished. Use one for recurring, rule-based work like log triage, dependency checks, or a daily brief.
How are Claude routines different from a cron job?
A cron job runs fixed, deterministic steps. A Claude routine runs an agent that reasons about context: it reads your logs and codebase, decides whether an error is a real bug or noise, and proposes a fix as a pull request. Use a script when no judgment is needed, and a routine when the task requires reading a situation and deciding what to do.
Do Claude Code routines run when my computer is off?
Yes. Routines execute on Anthropic-managed cloud infrastructure, not your local machine, so they keep running with your laptop closed. This is the main difference between a routine and an interactive Claude Code session in your terminal, which only runs while you are at the keyboard.
How much do Claude Code routines cost?
Routines bill against your existing subscription usage on Pro, Max, Team, or Enterprise plans, drawing from the same token budget as terminal sessions, with no separate server cost. Your two cost levers are the model you pick (Haiku for cheap frequent checks, Opus for heavy reasoning) and the cadence. Managed Agents built on the Agent SDK bill separately, per-token plus an hourly runtime fee.
Is it safe to give a routine access to my repository?
Yes, if you constrain it. By default a routine can only push to branches prefixed with claude/, so it can open a pull request but cannot push to main or deploy. Keep that default on, grant only the connectors it needs, and design it to propose (PRs, tasks, summaries) rather than perform irreversible actions. There is no human approval prompt mid-run, so the boundaries are the whole safety story.
Why does my routine push to a claude/ branch instead of main?
That is the safety default. Claude can only push to branches prefixed with claude/ unless you explicitly enable unrestricted branch pushes. It forces every change through a pull request a human reviews, so an unattended agent can propose a fix but never ship it on its own. Leave the restriction on; it is what makes pointing a routine at production reasonable.
What models can run a Claude routine?
Each routine has a model selector, and the model you choose runs on every execution. Pick a fast, inexpensive model like Haiku for frequent lightweight checks, and a stronger model like Opus 4.8 with its 1M-token context for runs that need careful reasoning about code. You can change the model at any time, and it is your main cost lever alongside cadence.
What is the minimum schedule interval for a routine?
One hour. You set a scheduled routine with a cron expression, and any expression that would run more frequently than once an hour is rejected. For work that needs to react faster than that, use the API trigger to invoke the routine on demand from your own code, or the GitHub trigger to run it on a repository event.

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.