Anthropic ships Routines.

Until this week, the recipe for "an agent that wakes up at eight every morning, looks at production data, and emails me a paragraph about it" required three separate systems wired together by hand. A cron worker. A Claude API call with its own prompt management. A notification step using somebody else's SDK. Routines collapse those three into one configuration. Anthropic shipped them inside Claude Code this week, and the cleanest way to think about Routines is as the scheduling primitive that closes the loop on agentic automation already happening at the keyboard.

The launch is small in surface area and large in implication. A Routine is a Claude Code session that runs on Anthropic's infrastructure on a schedule, with whatever MCPs and skills you have wired in for your interactive Claude Code sessions also wired into the scheduled run. That last clause is the one most coverage will underplay, because it sounds like a footnote and is actually the whole feature.

§01What Routines actually are

A Routine has four parts. A trigger (more on that below). An instruction, in plain language, that tells Claude Code what the run is for. A toolset, which is the same MCP connectors and skills you already have configured for your account. And an output destination, which can be anything your tools can write to: a database, an email, a Slack message, a file in your repo, a Linear ticket. Anthropic does not need to know which destination matters to you; the tools handle that part.

Triggers come in three kinds, and a single Routine can combine more than one of them. Scheduled triggers fire on a recurring cadence (hourly, daily, weekly, custom cron) or once at a specific future timestamp. API triggers give the Routine its own POST /fire endpoint protected by a bearer token, so any HTTP caller (a monitoring tool when a threshold breaks, a deploy pipeline after a release lands, an internal admin button) can fire it on demand and pass run-specific context as a text payload. GitHub triggers run the Routine in response to pull request or release events on a connected repo, with filters on author, branch, labels, draft state, and a few other fields. The combination matters: a code-review Routine can react to every new PR and run nightly and fire from a deploy script, all from the same configuration.

Routines are not a separate product with their own integrations. They are a Claude Code session with a cron annotation on top, running headless on Anthropic's infrastructure rather than in a terminal on your laptop. Everything that already works in Claude Code (custom MCPs, installed skills, project conventions in CLAUDE.md) keeps working when the same session runs unattended.

The pricing model is the second tell that this is one product, not two. Routines are available on Pro, Max, Team, and Enterprise plans (with Claude Code on the web enabled), with no separate metering on top. The same Claude Code subscription that pays for sessions at the keyboard also pays for the ones that run while you sleep, draw down the same usage budget, and have a per-account daily cap on routine runs that one-off scheduled runs are exempt from.

Anthropic ships the feature as a research preview, which is the right cue: the trigger types and configuration surfaces are stable enough to build on, but the API shape ships behind a dated beta header (experimental-cc-routine-2026-04-01) and may shift. The morning-digest pattern below works today and is unlikely to break; teams wiring API triggers into critical alerting paths should pin the beta header version and watch the changelog.

§02A worked example, in production

A working example, running daily on nomology.ai since the launch landed: a Next.js app exposes a custom MCP server at a secret-token-guarded route. The MCP has two tools. get_pacing_digest pulls live data on every active advertising program (rate-check alerts, pacing drift, overdelivery, failed budget pushes from the previous day). send_email posts a plain-text email through the Resend API.

The Routine, configured through Claude Code's scheduling interface at claude.ai/code/routines, fires once a day at eight. Its instruction is roughly: call get_pacing_digest, decide what is worth surfacing in a one-screen morning summary, write it as plain text the way I would write it to a colleague, and email it to me through send_email. That is the entire configuration. Claude Code runs the call, makes the editorial decisions, and triggers the delivery, exactly the way it would in an interactive session at the terminal.

The output is a paragraph written for the actual signals of the day, not a templated digest with the variables swapped in. When the data is boring, the email says so in two sentences. When something has gone sideways overnight, the email leads with that and skips the things that did not change. The model is doing the editing, not the rendering, and the difference shows up immediately.

§03Why the composition matters

The pieces in this stack were all available before Routines launched. A Vercel cron job hitting the Claude API directly, with prompt management, error handling, retries, and a separate email service. Plenty of teams ran some version of that. What Routines remove is the glue. The schedule, the agent, the tools, and the output are now one configuration in one place, owned by one platform.

The other thing worth noticing is how Routines treat the existing Claude Code surface area. MCPs, skills, and project context are first-class citizens, not bolt-ons. Whatever MCP a developer has already wired into their interactive Claude Code sessions is the same MCP a Routine can call. Whatever skill they have installed runs the same way at three in the morning as it does at three in the afternoon. The pacing digest MCP in the example above was built months earlier for ad-hoc "what is happening in production" queries during the workday. The morning digest is the same server, plus a daily trigger, plus an email tool. Zero new code on the data side.

That is the part the launch unlocks. Custom MCPs and installed skills become assets that pay back twice: once interactively at the keyboard, once on a schedule while the keyboard is closed.

§04What this unblocks, and what it does not

The class of automation Routines makes practical is anything where the value is model in the loop, not data in the loop. Morning operations digests. Stale pull request nudges that explain why each is stale rather than just listing them. Customer feedback summaries that flag the comment that actually matters this week. Inbox triage where the model decides what is worth surfacing and writes a one-paragraph cover note for it.

API triggers extend that class meaningfully. The same monitoring tool that already pages a human at three in the morning can instead POST /fire a Routine that pulls the stack trace, correlates with recent commits, and opens a draft PR with a proposed fix. A deploy pipeline can call a Routine after each production release to run smoke checks and post a go or no-go to the release channel before the deploy window closes. The Routine is the part that does the writing and the judgment; the API trigger is the part that lets the rest of your stack call it.

What Routines do not replace is anything sub-minute. A regular cron firing at thirty-second intervals to check a queue depth and Slack on breach is still the right pattern there, because the per-tick cost of waking a Claude Code session is not worth what the model adds. The right division of labor: monitoring detects the breach, monitoring fires the API trigger, the Routine handles the part where someone writes a sentence about it.

§05The implication for vibe coders

The right design move on a new automation, starting now, is to ask whether a Routine plus a custom MCP works first, and only fall back to a hand-rolled cron when the latency floor or the per-tick cost rules Routines out. Most automations a one-person team builds clear that bar.

The other implication, less obvious: an MCP that exposes the data and the delivery surfaces of an internal tool is now a meaningfully more valuable artifact than it was a week ago. It used to be a way to make Claude Code useful at the keyboard. It is now also a way to make Claude Code useful while the keyboard is closed.