Published: 2026-04-14

Claude Code Routines: Run AI Agents 24/7 Without Your Laptop

Chapters / key moments (click to jump — plays here on the page)

Claude Code's new Routines feature lets you run scheduled AI automations entirely on Anthropic's cloud — no local hardware needed, no laptop to keep open. Nate Herk demos setup via desktop app, web, and CLI, covering the critical differences from local scheduled tasks: stateless execution, GitHub repo sync, and the API key configuration mistake that breaks most first attempts.

Source video

"Claude Code Just Dropped Routines. 24/7 Agents." by Nate Herk — Watch on YouTube →

Key Takeaways

Routines run on Anthropic's cloud infrastructure (4 vCPUs, 16 GB RAM, 30 GB disk per run) — your laptop does not need to be on or even connected to the internet.
The most common setup mistake: API keys from your local .env file are gitignored and invisible to the cloud run. Store them in the Cloud Environment's environment variables section and explicitly tell your prompt to read them from the environment, not from .env.
Three trigger types: schedule (minimum 1-hour interval, set in natural language), API call (send a curl request to fire the routine), and GitHub events (new PR, push, issue, or release).
Session limits per day: 5 on Pro, 15 on Max, 25 on Team/Enterprise. Hitting the cap triggers metered overage for orgs with that enabled.
Network access modes: Trusted only allows Anthropic-vetted domains (version control, major cloud providers). Full allows all outbound requests — required for third-party APIs like ClickUp. Understand the tradeoff before switching to Full.
Each run is stateless — the cloned GitHub repo is destroyed after completion. Commits to your branch persist; local files, browser cookies, and cached credentials do not.

Routines vs. Scheduled Tasks vs. /loop

Nate compares the three Claude automation modes side by side:

Routines: cloud-based, no machine required, survive restarts, minimum 1-hour interval, stateless (no local file access), fully autonomous.
Desktop scheduled tasks: local, machine must be on, survive restarts, can run every minute, full local file access, configurable permissions.
/loop: local, machine must be on, does NOT survive restarts (session-bound), any interval, full local file access.

The right choice depends on your use case. If you need local file access, browser session state, or sub-hour triggers, stick with desktop scheduled tasks. If you need the automation to run while you travel or sleep without leaving a machine on, Routines are the answer.

Setup in Practice: What Actually Works

Based on Nate's live testing, the fastest path to a working routine:

Create a dedicated GitHub repo for the routine (not your full project repo — the cloud clones the entire repo, so keep it lean).
Add any API keys you need to the Cloud Environment → Environment Variables section in the Claude desktop app or web interface.
Write the routine prompt with an explicit instruction like: "My YouTube API key is available as an environment variable. Use it directly from the environment, not from .env."
Use Run Now to test before scheduling — you can watch it execute live and inject corrections.
If your routine uses a non-standard API (not on Anthropic's trusted list), set Network Access to Full in the Cloud Environment settings.

Related on OpenClawDatabase

Claude Cowork Setup Guide — getting started with Claude Code and Cowork environments
Claude Routines vs N8N — Nick Saraev on why Routines replace no-code automation platforms entirely
Claude Managed Agents Reviewed — Nate's earlier take on managed agents and where Routines fill the gaps

What you can actually set up from this

Extracted from the video's own transcript — the specifics the original summary left out.

Reproducible steps

Know which kind of routine you are creating
Routines run locally or remotely on Anthropic's web infrastructure, and both appear in the same scheduled-tasks list. Remote ones can be created from the terminal, from claude.ai/code, or from the desktop app. A new task takes a name, the prompt itself, a model, a repository, a cloud environment, a cadence, connectors and permissions.
A remote routine needs a GitHub repository, and that shapes everything else
The remote run clones your repo, reads your CLAUDE.md, scripts and skills, does the job, then destroys the clone. <strong>This is why the rest of the setup is the way it is</strong> — the clone is the agent's entire world, and it is thrown away afterwards.
Put API keys in the cloud environment, not in .env
<strong>The single most useful gotcha here.</strong> Your <code>.env</code> is gitignored, so it does not exist in the clone. Keys go into the scheduled task's cloud environment as environment variables instead. Open the environment's settings to set the name, network access and environment variables.
Tell the prompt explicitly to read the environment
Setting the variable is not always enough. With a CLAUDE.md that documents keys as living in <code>.env</code>, the agent may go looking there and fail. The fix that worked was adding to the prompt: "My API key is available as an environment variable. Use it directly from the environment. Don't look for a .env." One routine failed twice before that sentence was added and worked immediately after.
Check the network access level before blaming the code
Cloud environments default to <em>trusted</em>, which only allows package downloads from Anthropic-verified sources. A routine calling a third-party API will simply be refused. Switching to <em>full</em> resolved it; a <em>custom</em> setting exists to allow specific domains instead of opening everything.
Write the prompt to be one-shot
Nobody is there to answer a clarifying question. The mental model offered is exact: a routine is you typing a prompt, except someone else walks up to your laptop and types it for you. If it can stall waiting for you, the automation has no point.

Gotchas

<strong>Every remote run is stateless and the clone is deleted afterwards.</strong> An automation that drives a browser will have no cookies from previous sessions, so anything relying on an existing logged-in session will not port to a remote routine. You need an endpoint that accepts real authentication — an API key, header or cookie you supply.
The exception: if the routine changes code or performs a review, it creates a branch or produces output rather than discarding everything.
Minimum cadence is hourly — there is no every-ten-minutes option.
There is a separate daily limit on included routine runs, visible under usage settings alongside session and model limits. Worth checking before you migrate a fleet of automations across.
The migration is not automatic. Local automations copied verbatim into remote routines did not simply work — the .env assumption and the network access level were both silent failures rather than clear errors.

← Back to News digest · See also: Claude Cowork guide