Claude Code Routines: what they actually do, and when to use them over GitHub Actions

Anthropic shipped Claude Code Routines this week, and the feature landed on the Hacker News front page with 643 points. At the time of writing it’s in research preview, which means the shape can change, but the direction is clear: Claude Code is no longer strictly an interactive tool. It’s a scheduled agent platform.

If you’ve been running Claude Code via claude -p in a cron job or a GitHub Action, Routines replace most of that setup. Here’s the actual shape of the feature, and when to reach for it versus tools you already use.

What is a Routine?

A Routine is a saved Claude Code configuration that runs on its own in Anthropic’s cloud.

That’s it. Mechanically, you package four things: a prompt, one or more repositories, an environment (network access, env vars, setup script), and a set of MCP connectors. You attach one or more triggers. Then it runs when a trigger fires.

Per the docs, there are three trigger types:

• Scheduled runs on a recurring cadence, as fast as hourly.
• API gives the Routine a dedicated HTTP endpoint with a bearer token. POST to it from anywhere.
• GitHub runs automatically on pull request or release events in a repository you’ve installed the Claude GitHub App on.

A single Routine can combine all three. Your PR-review Routine can run on every new pull request, on a nightly sweep, and on an explicit call from your deploy script. Same configuration, three ways to invoke it.

Why this matters

Before Routines, if you wanted Claude Code to run unattended, you had three options, all of them awkward.

You could cron an SSH session to your own box and hope the machine stayed awake. You could use /loop or ScheduleWakeup inside an active session, which only works while that session is open. Or you could wire Claude Code’s CLI into a GitHub Actions workflow, which means a paid minutes allocation and the friction of managing a secret for every repo.

Routines cut all of that. They run on Anthropic’s cloud infrastructure. They don’t need a laptop open. The session starts, does the work, commits to a claude/-prefixed branch, and optionally opens a pull request. You watch the run later in a session tab like any other.

For developer teams, this removes friction around unattended work that used to require a self-hosted runner or an ops budget. For solo devs, it removes the “is my Mac awake” problem that kills every locally-scheduled automation project.

When to reach for Routines (and when not to)

Routines are good for work that is repeatable, unattended, and tied to a clear outcome. The docs give six example use cases: backlog maintenance, alert triage, PR review, deploy verification, docs drift, and library port. All of those share the shape: fire a trigger, run a bounded task, leave a diff or a comment behind.

They’re the wrong tool for work that needs:

• Sub-hour latency on a schedule. Scheduled Routines have a one-hour minimum cadence. If you need a 5-minute cron, keep it in your existing scheduler and have that scheduler POST to the API endpoint instead.
• Complex CI orchestration across services. Routines run Claude Code; they’re not a full CI runner. For multi-stage pipelines with matrix builds, stay in GitHub Actions.
• Anything secret-sensitive you can’t scope down. A Routine runs as you: its GitHub pushes, Slack messages, and Linear tickets all carry your identity. For team-shared automation, that identity coupling matters.

For a lot of the middle ground, though, Routines win on ergonomics.

A concrete example

Here’s what triggering a Routine from your own tooling looks like, copied from the docs:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

The response gives you a session ID and a URL you can open in a browser to watch the run happen live. That’s the whole integration.

For a schedule, you write the Routine once in claude.ai/code/routines or via /schedule in the CLI, and it fires on its cadence.

For a GitHub trigger, you install the Claude GitHub App on a repo, pick an event (pull_request.opened, release.created, etc.), and filter on fields like author, base branch, labels, or “from fork.” Each matching event creates its own session.

What’s still rough

The feature is in research preview. A few edges are visible in the docs:

• The API trigger is gated behind a beta header (anthropic-beta: experimental-cc-routine-2026-04-01). Anthropic says breaking changes ship under new dated beta headers with a migration window, but if you build on this, expect to revisit. The endpoint and token format isn’t stable yet.
• GitHub webhooks have per-account hourly caps. Events beyond the limit get dropped. If your repo gets hundreds of PRs per hour, you’ll need to use filters aggressively.
• Routines count against your daily run allowance. If you build a team workflow on Routines, every member’s runs share the same cap unless you’re on a plan with extra usage. Watch the usage page.
• CLI parity isn’t there yet. /schedule can create scheduled Routines, but API and GitHub triggers need the web UI to configure.

None of these are dealbreakers. They’re the normal shape of a preview feature.

How it compares to the alternatives

For a practical perspective, it helps to line Routines up against the tools they overlap with.

GitHub Actions running Claude CLI is the closest alternative. You get per-repo scoping, full CI ergonomics, and free minutes for public repos. You lose: managed infrastructure, a daily cap outside GitHub’s billing, and a unified session tab to review what Claude did. Routines win on setup friction; Actions win on multi-step pipeline flexibility.

Self-hosted cron on a VPS is the other common pattern. You own everything: the schedule, the secrets, the logs. You also own the uptime and the bill. Routines trade all of that for a daily cap and vendor lock-in. If your automation already outgrew the VPS, Routines are a soft landing.

AWS Lambda or GCP Cloud Functions with Claude API calls is the enterprise alternative. Those give you VPC integration, per-request metrics, and IAM-scoped secrets. Routines don’t replace that level of platform control. They replace the weekend-project version of the same idea.

The honest read on when to rebuild: if your current setup is “GitHub Actions runs claude -p on cron,” Routines are simpler and a bit cheaper (you skip the Actions minutes). If your current setup is “a scheduled Lambda with full orchestration logic around Claude,” keep what you have.

What this means for you

If you’ve been building around Claude Code as “the interactive mode of Claude,” Routines are a category shift. You now have a first-party way to put Claude Code on a schedule, on a webhook, or on a GitHub event, without running your own infrastructure. That’s a new thing.

One rule to follow, straight from the docs: the prompt is everything. Routines run autonomously, so the prompt has to be self-contained and explicit about what success looks like. An interactive prompt you’d refine with follow-ups doesn’t translate. Write prompts for Routines the way you’d write them for a coworker you can’t reach that day.

Start small. Pick one task you currently run manually once a week. Write a Routine for it with a weekly schedule. Let it run for two weeks. If the output is good, add a GitHub trigger. If it isn’t, tighten the prompt. You’ll learn more about what Routines are good for from one real automation than from any number of explainer articles, this one included.