Claude Code routines: let Claude work while your laptop is off

Most of what I ask Claude Code to do, I ask more than once. The same report on Monday. The same check on every new pull request. The same summary of what changed overnight.

For a long time that meant one of two things. I typed the prompt again, or I kept a machine running so a scheduled script could do it for me. Routines remove both. You set the task up once, and Claude runs it in the cloud on a schedule or when something happens.

This guide covers what a routine is, what can start one, how to set up your first, and how to keep it from doing something you did not mean.

What are Claude Code routines?

A Claude Code routine is a saved task that runs on Anthropic's cloud infrastructure instead of on your computer. It holds a prompt, the repositories Claude may work in and the connectors it may use, plus a trigger that decides when it runs.

Anthropic launched routines in 2026 as a research preview. That label matters. The feature works, but details like limits and settings are still moving, so treat the Claude Code docs as the source of truth for anything specific.

The point of a routine is simple. A normal Claude Code session needs you: you open the terminal, you type, you watch. A routine needs nobody. It starts by itself, does the work and leaves the result where you told it to.

How is a routine different from a skill, command or hook?

A routine decides when Claude works without you, while skills, commands and hooks decide how Claude works once a session is running. They fit together rather than compete.

In practice a good routine is short, because it leans on the rest. The routine prompt says "run the weekly report", and the skill holds the steps for how a weekly report is made. If you have not written skills yet, start with how to write a Claude Code skill, then come back. A routine is only as good as the procedure it calls.

Which triggers can start a routine?

A routine can be started by three kinds of trigger: a schedule, an HTTP call to its API endpoint, or an event in a GitHub repository. You can attach more than one trigger to the same routine.

The API trigger is the one people overlook. It turns a routine into a step in a bigger flow. Your CRM, an n8n workflow or a webhook from a form tool can hand Claude a task the moment it happens, instead of waiting for the next scheduled run.

How do you set up your first Claude Code routine?

You set up a routine by writing a prompt that works on its own, choosing what Claude may touch, and adding a trigger. These are the steps I would follow:

1. Pick one recurring task you already do by hand. Something you have done at least five times, so you know what good output looks like.
2. Run it as a normal session first. Do the task in Claude Code with you watching. Fix the prompt until the result is right without you stepping in.
3. Write the prompt for nobody. No "ask me if unsure". Say what to do when information is missing, where to put the result and what done looks like.
4. Choose the smallest scope. Add only the repositories and connectors this task needs. A report routine does not need write access to your CRM.
5. Create the routine. Use /schedule in the terminal or the routines section at claude.ai/code, then paste the prompt and pick a trigger.
6. Run it once by hand. Check the session it produced: what it read, what it changed, what it left behind.
7. Let the trigger take over, and review the first week. Read every run until you trust it. Then read a sample.

Step 3 is where most routines fail. In a live session you catch a vague prompt within seconds. In a routine, a vague prompt produces a vague result every day until you notice.

What should a routine prompt contain?

A routine prompt should state the goal, the inputs, the output and its location, and what to do when something is missing, because nobody is there to answer questions. Here is an example for a made-up agency that wants a Monday summary of its client work:

Every Monday, write a short status summary of last week's client work.

Inputs: the /clients folder in this repo, and the task board connector
(read only).

Output: one Markdown file in /reports named YYYY-MM-DD-weekly.md, with
one section per client: what was finished, what is stuck, what is due
this week. Max 300 words in total.

If a client has no updates, write "no updates" for that client.
Do not contact anyone. Do not change any task on the board.
When done, open a pull request with the report so a person can review it.

Notice the last three lines. They tell the routine what it may not do. In a session I would correct it on the spot. In a routine, the prompt is the only correction it gets.

Which business tasks fit a routine?

Tasks fit a routine when they repeat on a known rhythm, use inputs Claude can reach in the cloud and end in an output a person can check. A few examples of the kind that work well:

• A morning brief. Read yesterday's notes, the task board and the calendar through connectors, and write one page of what matters today.
• A weekly report. Pull numbers from a connected tool and write the same report in the same format every week.
• A pull request reviewer. On every new pull request, check it against the team's written rules and leave comments.
• Docs that keep up. After a release, update the changelog or the help docs that describe what changed.
• An intake handler. When a form tool calls the API trigger, draft a reply and a summary for a person to approve.

What these share is that the routine prepares and a person decides. That is not caution for its own sake. In a June 2025 forecast, Gartner said more than 40% of agentic AI projects would be scrapped before the end of 2027, mainly because costs climb, the value stays vague or the risks are not controlled. A routine that only drafts is cheap to run, easy to judge and hard to get badly wrong.

Most routines need to reach your tools, and they do that through connectors. If you have not linked any yet, my MCP setup guide covers the basics.

How do you keep a routine safe?

You keep a routine safe by limiting what it can reach, letting it draft instead of act, and reading what it did. A routine runs without supervision, so every risk you accept in a live session gets bigger.

The habits that matter:

• Narrow access. Every repository and connector you add is something the routine can touch on every run. Start with read access where you can.
• Output to a review point. A pull request, a draft or a file in a reports folder. Not a sent email or a changed record.
• Name the forbidden actions. "Do not contact anyone" and "do not delete" belong in the prompt.
• Check the run history. Each run is a full session you can open. Skim it weekly, even when the results look fine.
• Mind the limits. Runs use your plan's usage, and there is a daily cap on routine runs. An hourly trigger on a task that needs a daily one burns both for nothing.

These are the same weak spots that break any agent after launch: access that is far too wide, no person approving risky actions and no record of what happened. I go through all five in the production failure patterns I keep seeing.

Should you use a routine or a cron job with claude -p?

Use a routine when everything the task needs lives in GitHub or behind a connector, and use a cron job with claude -p when it needs files, tools or networks that only exist on your own machine or server.

Cron with headless mode is older and more flexible. It is also more work: you keep the server alive, manage secrets and build your own logging. If you go that route, the -p flag and the other CLI options are in my list of Claude Code commands.

Are Claude Code routines worth setting up?

Yes, for any task you already run on a fixed rhythm, because the setup takes less time than doing the task by hand twice. The value is not that Claude works faster. It is that the work happens without anyone remembering to start it.

According to McKinsey's 2025 State of AI survey, 88% of organizations now use AI somewhere in the business, while roughly two-thirds have not begun to scale it company-wide. Most of that gap is not the model. It is that AI still waits for a person to open a chat window. A routine is one of the simplest ways to close it for one task.

Start with one routine that writes something you already read every week. Run it by hand, then let it run on its own and read the first few results. When it holds up, add the next one.