Source: raw/Claude Code Routines.pdf (Nate Herk walkthrough), Anthropic official blog — Apr 14 2026 Authors: Nate Herk (AI Automation Society); Anthropic (official announcement) Published: April 14 2026 (Anthropic announcement); Nate Herk walkthrough April 2026
Routines are saved Claude Code tasks that run on Anthropic’s cloud servers — on a schedule, via API call, or in response to GitHub events — even when your laptop is closed. Announced April 14, 2026 in research preview, they represent the shift from “AI helps me code faster” to “AI handles entire repeatable workflows autonomously.”
Key Takeaways
- Routines run on Anthropic’s cloud, not your machine. Each run clones your repo fresh, works in an isolated environment, and destroys the environment after.
- Three trigger types: Schedule (cron, min 1 hour), API (POST with bearer token), GitHub (18+ event types including PRs, pushes, issues, releases, workflow runs).
- Changes push to
claude/-prefixed branches. Every run creates a reviewable session on claude.ai. - Actions happen as YOU — commits carry your GitHub user, Slack messages use your account.
- CLAUDE.md is read automatically every run because routines clone your repo. This is how you make routines context-aware.
- Routines cannot use local MCP servers. They use Connectors — Anthropic’s managed integrations (Slack, Linear, Jira, Google Drive, GitHub built-in).
- Existing Desktop Scheduled Tasks do NOT migrate. You must recreate them as new routines manually.
- Each run is stateless — no state carries between runs. If step 2 depends on something step 1 saved to disk yesterday, it won’t be there.
- Key advantage over n8n/Zapier/cron: routines inject a prompt into a full Claude Code agentic session with self-correction and context-aware problem solving, not a rigid flowchart.
Routines vs. Existing Options
| Routines (cloud) | Desktop Scheduled Tasks | /loop | |
|---|---|---|---|
| Runs on | Anthropic cloud | Your machine | Your machine |
| Needs machine on | No | Yes | Yes |
| Needs open session | No | No | Yes |
| Survives restarts | Yes | Yes | No |
| Local file access | No (fresh clone) | Yes | Yes |
| Permission prompts | None (fully autonomous) | Configurable | Inherits from session |
| Min interval | 1 hour | 1 minute | 1 minute |
Three Trigger Types
- Schedule: Cron-based (hourly, daily, weekly). Example: “Every weeknight at 9pm, triage new issues.”
- API: POST to a dedicated endpoint with bearer token. Example: “When Sentry fires an alert, Claude diagnoses and opens a fix PR.” Each routine gets a tokened
/fireendpoint for external systems (added Week 16). - GitHub: Reacts to repo events. Example: “On every new PR, run my team’s review checklist.” The trigger picker covers GitHub events with optional filters: author, title, body, base/head branch, labels, draft status, merged status, from fork (filter UI updated Week 16).
- You can combine multiple triggers on one routine (e.g., runs nightly AND on every new PR).
- Scaffold from terminal:
/schedule daily PR review at 9am— a terminal shortcut to define a routine’s schedule without opening the web UI (added Week 16).
Environments: The Big Gotcha
Your .env is .gitignored, so the fresh clone won’t have it. Routines solve this with Environments:
- Environment variables: API keys configured at claude.ai, read as normal env vars during the run.
- Network access: Trusted (default, whitelist only), Full (unrestricted outbound), None, or Custom (specific domains).
- Setup script: Install commands that run before each session (
npm install,pip install, etc.).
The .env gotcha: Nate’s first routine failed because scripts looked for .env (reinforced by CLAUDE.md). Fix: explicitly tell the routine “Use environment variables directly. Don’t look for a .env.” General fix: use os.environ["KEY_NAME"] instead of .env loading.
Network gotcha: If your routine needs external APIs (ClickUp, YouTube, etc.), you need Full mode. Trusted blocks those requests. Risk of Full: if Claude reads malicious content (crafted PR description, compromised dependency), it could be tricked into sending data to an external server. Practical risk for private repos where you control inputs: very low.
Connectors
Available at launch:
- Slack: read/post messages, respond to threads
- Linear: create/update issues, read project state
- Jira: ticket management
- Google Drive: read/write docs and files
- GitHub (built-in): PRs, issues, code changes
Each connector authenticates through your account. Nate’s tip: if you just need a notification, a Slack connector is often easier than a custom API call.
What Won’t Work
- Persistent browser sessions: Playwright/Puppeteer requiring login cookies. Environment is destroyed after each run. Workaround: use endpoint with cookie/header/API-key auth.
- Local-only services: Can’t reach localhost databases, local APIs, or machine services.
- Resource-heavy processes: Each run gets 4 vCPUs, 16 GB RAM, 30 GB disk. Exceed memory and the session terminates.
- Stateful workflows: No state between runs.
Limits and Quotas
| Plan | Runs/day |
|---|---|
| Pro | 5 |
| Max | 15 |
| Team | 25 |
| Enterprise | 25 |
- Orgs with extra usage enabled can exceed the cap on metered overage.
- Token budget: each run draws from normal subscription usage.
- Minimum schedule interval: 1 hour.
Security
- Branch safety: Default push only to
claude/-prefixed branches. Per-repo toggle for unrestricted (not recommended). - API trigger protection: Each routine gets its own bearer token (shown once, can be regenerated/revoked).
- Token leak risk: Attacker could spam-trigger runs and burn your daily cap. Revoke and regenerate immediately.
- Identity: Everything runs as YOU. Test thoroughly before connecting routines to communication tools.
- Never put
.envin your repo to solve the env var problem. Even in a private repo, history persists and collaborators get exposed.
Writing Good Routine Prompts
- Be specific. “Fix flaky tests” is bad. “Scan src/tests/ for tests that failed intermittently in the last 5 CI runs, identify the root cause, and open a fix PR for each” is good.
- Name the files and directories — Claude clones fresh with no prior context beyond CLAUDE.md.
- State what success looks like.
- Set boundaries (“Only modify files in src/utils/. Do not touch the API layer.”).
- Include the output format (“Push to claude/fix-flaky-tests branch and open a draft PR with summary.”).
- Leverage CLAUDE.md for stable instructions, keep run-specific instructions in the prompt.
- Tell it what to do on failure.
Nate’s W.A.T. framework (Workflows, Agents, Tools): when you push a normal automation to the cloud as a Python script, you lose the Agent. Only workflow and tools survive. With routines, all three stay together.
Use Cases
Event-driven (GitHub triggers):
- PR merge triggers auto-docs update
- PR opened triggers automated code review against CLAUDE.md and style guide
- PRs touching
/auth-providerget flagged and summarized to Slack
Scheduled (cron):
- Nightly bug triage: pull top Linear issue, attempt fix, open draft PR
- Flaky test cleanup, weekly backlog grooming
- Dependency audits, code cleanups, release notes on autopilot
- Weekly docs drift detection
API-triggered:
- CI/CD or Sentry/Grafana alerts trigger Claude to triage and post to oncall
- Post-deploy smoke tests: CD pipeline calls routine, Claude runs checks, posts go/no-go
Implementation
Tool/Service: Claude Code Routines (research preview) Setup:
- Create at claude.ai/code, desktop app, or terminal (via scheduled remote agents)
- Configure: name, prompt, model, GitHub repo, cloud environment, cadence, connectors, permissions
- Create an Environment at claude.ai with env vars, network access, and setup script
- Test with “Run now” and watch live before trusting the schedule
Cost: Included in Pro/Max/Team/Enterprise plans. Runs draw from normal subscription usage. Daily run caps apply (5-25/day by plan). Integration notes: CLAUDE.md is critical — routines read it automatically on every run. Consider a dedicated repo per routine to keep context lean and avoid burning tokens on irrelevant CLAUDE.md content.
Final Setup Checklist
- Use “Run now” and watch the session live
- Verify all API keys are in cloud environment variables (not .env)
- Confirm network access is set correctly (Trusted vs. Full)
- Make sure prompt explicitly tells Claude where to find env vars
- Make sure prompt tells Claude what to do when it hits a wall
- Confirm CLAUDE.md isn’t dragging in irrelevant context
- Test failure paths, not just the happy path
Try It
- Go to claude.ai/code or the desktop app and create your first routine
- Start simple: a scheduled routine that opens a draft PR summarizing your repo’s open issues nightly
- Set up an Environment with any API keys needed
- Use “Run now” to test interactively before enabling the schedule
- Migrate one existing Desktop Scheduled Task to a cloud routine — compare reliability and output quality
- Add a Slack connector so routine results post to a channel for visibility
Related
- Cross-Topic Connections — cross-topic synthesis comparing Routines vs Managed Agents vs Dispatch with a decision framework
- Claude Managed Agents — Anthropic’s hosted agent service (different from routines: managed agents are API-invoked, routines are event-driven)
- Claude Code Subagents — Local parallel workers (routines are the cloud equivalent for scheduled/triggered work)
- Skills vs MCP vs Plugins — Routines use Connectors instead of local MCP servers
- Building Skills Guide — Skills can be used within routine prompts via CLAUDE.md
- Essential MCP Servers — Local MCP servers won’t work in routines; Connectors are the cloud alternative
Open Questions
- How does Anthropic plan to handle MCP server support in routines beyond the current Connector set?
- Will team-plan sharing of routines be supported?
- What is the token budget per run, and are there ways to optimize for cost?
- Will the minimum 1-hour schedule interval decrease as the feature matures?
- How does routine execution interact with the new Claude Opus 4.7 model’s stricter instruction adherence?