Claude Code has gained routines — a feature that lets your agent fire itself off on a schedule, on Anthropic's servers. The biggest change: your laptop no longer has to be on, or even open. Until now, scheduled tasks ran only locally, on your own machine. Now they can run in the cloud — that is, on the provider's remote servers. Anthropic is shipping this as a research preview for the moment, so the details may still shift.
Let's start with two terms. An agent is a program built on an AI model that carries out a task on its own, step by step — it reads files, makes decisions, and fixes its own mistakes along the way. Claude Code is the tool where Claude does programming and operational work: it runs in the terminal or as an app, reads your project files, and executes commands.
What a routine actually is
A routine is a single saved prompt — the instruction you give the model — configured once and then run automatically. The simplest way to picture it: it's as if you typed a command into Claude Code, then someone walked over to your computer and hit "enter" for you — except the cloud does it, at a set time.
A routine can be triggered in three ways:
- on a schedule — hourly, daily, on business days (this is the cloud equivalent of the old scheduled tasks);
- via an API call — another automation sends a request and fires the routine (an API is the programming interface two programs use to "talk" to each other);
- in response to a repository event on GitHub — for example a new commit, a new issue, or a new code release.
Setup looks much like an ordinary scheduled task: you give it a name, write the instruction for the agent, pick a model, a repository, and an environment, and set the frequency. A repository is where you keep your project's code — here, on the GitHub platform. The minimum gap between runs is one hour; you can't set "every ten minutes."
Why a repository is required
This is the core mechanism, so it's worth understanding. Every run of a routine clones your repository to the cloud — it makes a temporary copy. The agent reads the CLAUDE.md file (the project instructions), scripts, and skills from that copy, does the task, and once it's finished the copy is deleted. Every run is therefore stateless: it starts from scratch, with no memory of the last one.
Hence a simple boundary rule: if something lives only locally on your computer, or the agent can't reach it through the repository or an API, it won't work in a routine. The agent has no access to the files on your disk, nor to login credentials saved in your browser from earlier sessions.
There's one exception to the deletion. If the routine's job is to change code or review code, the agent doesn't wipe everything — it opens a new branch in the repository (a parallel version of the code) and saves the result there.
The secret to API keys: environment variables, not a .env file
Here's a trap that's easy to fall into. An API key is the password a program uses to log into another service — your YouTube account or your task manager, say. In normal work you keep keys locally in a .env file, and that file is deliberately kept out of the repository (it's on the ignore list). That's good security practice: you don't push secrets to GitHub.
But since a routine sees only the repository, and the .env file isn't there — how do you hand it the keys? The answer: through environment variables in that routine's cloud environment settings. It's a separate, private field; you enter the key for YouTube, for your task manager, and whatever else the agent needs to use.
One detail worth flagging. Sometimes the agent looks for the key in a .env file out of habit (because that's how it works locally and that's how it may be described in CLAUDE.md) and doesn't think to reach for the environment variable. When that happens, you have to tell it outright in the instruction — for example: "the API key is available as an environment variable, use it from there, don't look in .env." Once you spell that out, the agent finds the key straight away.
Network access: trusted or full
In the cloud environment you also set the network access. By default it's trusted: the agent connects only to a vetted list of services verified by Anthropic (version-control systems and select cloud platforms among them). Full mode lifts that limit — it can connect to any address. There's also a custom mode, where you specify the allowed domains yourself, and a none option.
Where's the risk in full mode? If the agent loaded malicious content mid-task, in theory it could be coaxed into sending data to an external server. In trusted mode that outbound connection would be blocked. In practice, with a private repository whose inputs you control yourself, the risk is small — but it's worth knowing before you knowingly switch on full mode for a service that isn't on the trusted list.
Write instructions that land on the first try
A routine is a one-shot. You're not at the computer, so the agent can't stop and ask you something — and if it does, the whole point of the automation is lost. So the instruction has to be specific enough for the agent to carry out in full on the first attempt.
In practice, what works is an instruction that names a ready-made skill to run and lays out the order of the steps. A loose, open-ended phrasing like "analyze the comments and give me a summary" is better left for a live conversation — unless you wrap it in a clearly defined skill. And one bit of good news to close this section: you don't need to know cron syntax (the technical notation for schedules). You set the run time in plain language.
Limits, resources, and cost
The number of runs per day depends on your plan. Per Anthropic's figures: the Pro plan gives you five runs a day, Max fifteen, and the Team and Enterprise plans twenty-five. Organizations with overage billing turned on can exceed the limit for an extra charge.
The cost is simply your usual consumption within the subscription. This matters: routines burn tokens exactly as they would if you were chatting with Claude Code live. A token is a chunk of text the model works with — roughly a piece of a word; every file read and every reply costs tokens. That's why it's not worth pushing a huge repository with a sprawling CLAUDE.md to the cloud when a given task needs only a fraction of it. Often it's better to set up a separate, small repository for a specific routine.
Each cloud run gets a fixed set of resources: four CPU cores (vCPUs), 16 GB of RAM, and 30 GB of disk. That's another reason not to copy a giant project to the cloud without need.
What stays and what disappears
After each run, the run history is saved — you can open a given routine and check how it went and, if it failed, why. If the agent created a branch with code, that branch lands in your repository. What disappears is the cloud environment itself, along with the cloned copy of the repository.
Although every run is stateless, you can configure a routine to leave something behind — a short note or a progress log in the repository. That way successive runs can gradually do better, even though each one starts from scratch.
Before you set it loose — test it
The most practical piece of advice: test the routine a few times before you start firing it off automatically every hour. There's a "run now" button for exactly this. Then you can watch the agent work through the steps live and step in to redirect it if needed. The point is to get confident that the next time it runs on its own, it won't have to ask you anything.
You can also guard against failure up front — for instance, add a line to the instruction telling the agent to message you if something goes wrong. Every failed run stays in the history anyway, so you can always check the cause.
What you gain is an agent that works independently of your hardware — one that reads the project instructions, uses its own scripts, fixes its own mistakes as it goes, and does it at a set time, while your laptop is off. The rest comes down to three things: a specific, one-shot instruction; keys in environment variables instead of a .env file; and a few "live" test runs before you hand the task to the cloud for good.