Claude Code Routines — Don't Hand Anthropic Your CI Yet

Anthropic wants to own your automation infrastructure, and on April 14 they stopped being subtle about it.

TL;DR

• What: Claude Code Routines run autonomous coding sessions on Anthropic’s cloud — scheduled, API-triggered, or fired by GitHub events like PRs, pushes, and releases
• Lock-in: Your automations run on infrastructure you don’t control, consume subscription quota, and use an experimental API that can break with a header rotation
• Limits: Pro gets 5 runs/day, Max gets 15, Team/Enterprise gets 25 — GitHub webhook events beyond hourly caps are silently dropped
• Action: Learn the pattern on side projects. Do not wire production repos to an experimental endpoint with no observability and no team ownership model

Claude Code Routines — What Happened

Routines landed as a research preview on April 14, 2026 — a cloud-hosted automation layer that runs full Claude Code sessions on Anthropic-managed infrastructure while your laptop stays off and your subscription quota drains. I’ve been watching Anthropic methodically close every exit that would let a team use Claude Code without deepening their dependency. Routines made the strategy explicit: this is Anthropic taking over your cron job, your GitHub Actions step, and your n8n workflow node in a single move.

A routine is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors packaged once and run automatically. You create them at claude.ai/code/routines or with /schedule in the CLI. Each routine supports three trigger types simultaneously — scheduled cadence (hourly, daily, weekdays, weekly, or custom cron expressions), a per-routine HTTP POST /fire endpoint authenticated with a bearer token, and GitHub webhook events including pull requests, pushes, issues, check runs, workflow runs, discussions, releases, and merge queue entries.

Execution happens on Anthropic-managed cloud infrastructure. Each run clones the repo fresh. By default, Claude can only push to branches prefixed with claude/ — a guardrail that prevents a misconfigured routine from touching your main branch directly. You monitor sessions at claude.ai/code, not in your existing observability stack. No OTEL export, no Datadog integration, no log forwarding to anything you already own.

The /fire API endpoint ships under the experimental-cc-routine-2026-04-01 beta header. Request and response shapes, rate limits, and token semantics may change while the feature is in research preview. Anthropic guarantees only that the two most recent previous header versions continue to work, giving callers a migration window when breaking changes ship. Any production integration built against this endpoint is breakable infrastructure — by design.

GitHub webhook events are subject to per-routine and per-account hourly caps during research preview. Events beyond the limit are silently dropped until the window resets. If your routine handles PR reviews on a busy monorepo, you will miss events without notification.

Routines are available to Claude Code users on Pro, Max, Team, and Enterprise plans. The quota model is where things get interesting: routine runs draw from the same daily cap as interactive Claude Code sessions. On top of that, Anthropic enforces daily run limits per plan tier — Pro users get 5 runs per day, Max users get 15, and Team or Enterprise users get 25. Five heavy routines on a Pro plan don’t just hit the run cap; they can exhaust the day’s interactive Claude Code capacity entirely.

Why This Matters

The pitch is compelling. A nightly issue triage bot that reads your backlog, labels stale tickets, and drafts responses. A PR reviewer that runs on every pull request, catches obvious bugs, and leaves structured comments. A deploy verification hook that smoke-tests your staging environment after every merge to main. These are real workflows that currently require stitching together GitHub Actions, a hosted LLM API, prompt management, and custom glue code. Routines collapse that entire stack into a prompt and a trigger.

But the infrastructure custody question deserves more scrutiny than the announcement gives it. When you build a GitHub Actions workflow, you own the YAML, the runner, the logs, and the retry logic. When you build an n8n automation, the workflow definition lives in your database. When you build a Routine, the configuration lives in Anthropic’s cloud, runs on Anthropic’s servers, draws from Anthropic’s quota, and commits code under your GitHub identity from machines you don’t control.

This is not hypothetical risk. The /fire endpoint is explicitly experimental. Anthropic’s own documentation states that request shapes and token semantics may change. The two-version header guarantee means your integrations get one migration window before they break. If you’ve built fifteen routines that form the backbone of your team’s development workflow, you’re one header rotation away from a weekend of emergency rebuilding — or you’re pinned to Anthropic’s release cadence permanently.

The ownership model amplifies the concern. During research preview, routines belong to individual claude.ai accounts, not organizations. Commits appear under the configuring developer’s GitHub identity. There’s no team sharing, no co-ownership, no centralized policy control. Your org’s compliance team will want to know who authorized an AI agent to commit to the production repo under a specific developer’s name, and “whoever set up their personal Claude account first” is not a satisfying answer.

If you want the Routines pattern without the custody tradeoff, the underlying approach — prompt + repo + trigger — can be replicated with GitHub Actions calling the Claude API directly via the Claude Agent SDK. You lose the managed UI but keep the infrastructure ownership.

Compare this to what’s happening elsewhere in the agentic CI space. GitHub Actions with Copilot extensions give you AI capabilities inside infrastructure you already own. Self-hosted agent runners from the open-source community let you control the execution environment. Even Cursor’s SDK approach, which has its own lock-in concerns, at least runs locally. Routines are the most opinionated bet in this space: Anthropic is saying “give us the keys to your repo and your automation layer, and trust us to run it well.”

The daily run limits reveal the business model clearly. At 5 runs per day on Pro, Anthropic throttles the feature hard enough to push teams toward Max or Enterprise pricing. This is classic land-and-expand: let teams taste automated PR reviews, build dependency, then make the upgrade conversation about not losing workflows rather than gaining features.

The Take

The pattern is sound — saved configurations with mixed triggers is exactly how developer automation should work. But the implementation is a custody grab dressed as a convenience feature. You stop owning the automation infrastructure. Your nightly triage, your PR review bot, your deploy smoke checks — they now run on Anthropic’s cloud, draw from your subscription cap, and commit code under your GitHub identity from servers you don’t control.

Before you wire a production GitHub repo to a Routine, ask three questions. What happens to those automations when Anthropic changes rate limits or rotates the beta header? Who on your team owns the routine, and what happens when they leave? Can you rebuild this in GitHub Actions calling the Claude API directly — and if so, why are you handing over the infrastructure layer?

The honest answer for most teams: experiment on side projects and non-critical repos. Learn the prompt-plus-trigger pattern, because it’s genuinely useful. But do not build production-critical automation on an experimental endpoint owned by a single developer’s personal account with no observability integration and silently dropped events. When Anthropic ships team ownership, stable API contracts, and log forwarding to your own observability stack, revisit. Until then, you’re renting automation infrastructure on terms that can change with a blog post.