Claude Code Routines let you save a prompt, a repo, and a set of connectors once, then have that bundle run on its own. Anthropic introduced them on April 14, 2026, in the same week (v2.1.105 through v2.1.113) that shipped native binaries and the /usage breakdown. A routine runs on Anthropic-managed cloud infrastructure, so it keeps working when your laptop is closed. They are still in research preview, which means limits and the API surface can shift under you.
Here is why power users care. Most recurring work does not need a human babysitting a terminal: nightly bug triage, a post-deploy smoke check, a review pass on every new PR. You have probably been duct-taping these together with cron jobs and GitHub Actions, and it mostly works until it quietly doesn't. Routines put the schedule, the trigger, and the agent into one saved object you manage from claude.ai/code/routines.
What a routine actually is
Three pieces, saved together. A prompt, one or more repositories, and the connectors the run is allowed to touch. Each repo gets cloned fresh at the start of every run, starting from its default branch, and Claude writes its changes to claude/-prefixed branches unless you explicitly allow unrestricted branch pushes. The connectors are your claude.ai MCP integrations, things like Slack, Linear, or Google Drive.
One detail trips almost everyone up the first time: routines run with no permission prompts. There is no approval mode picker, no "allow this command?" interruption. The session can run shell commands, use skills committed to the cloned repo, and call any connector tool, writes included, without asking you first. The prompt has to carry all of that itself. It needs to be explicit about what to do and what done actually looks like, because a vague prompt that you would normally clarify mid-session has nobody to clarify with at 2 a.m.
Routines are available on Pro, Max, Team, and Enterprise plans, and they require Claude Code on the web to be enabled. They belong to your individual account, not your team. Anything a routine does through your GitHub identity or your connectors shows up as you: commits and PRs carry your GitHub user, Slack messages post from your linked account.
The three trigger types
A single routine can carry one trigger or several at once. The docs give the canonical example of a PR review routine that runs nightly, fires from a deploy script, and reacts to every new PR, all three on the same saved object.
Schedule. A recurring cadence, or a single future run. The presets in the form are hourly, daily, weekdays, and weekly. You enter times in your local zone and they get converted, so the routine fires at that wall-clock time no matter where the cloud box happens to live. Runs can start a few minutes late because of stagger, though that offset stays consistent for a given routine once it settles. The minimum interval is one hour, and anything more frequent gets rejected. Want every two hours, or "first of the month"? Pick the closest preset, then drop into the CLI and run /schedule update to set a real cron expression.
API. Each routine can get a dedicated HTTPS endpoint. You POST to its /fire URL with a bearer token; that starts a new session and hands back a session URL. The request body takes an optional text field for run-specific context, say an alert body or a failing log, which gets passed alongside the saved prompt. One thing to watch here: that text is freeform and not parsed, so if you send JSON it arrives as a literal string. A call looks like this:
curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABC.../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 token is shown exactly once when you generate it, and it only triggers that one routine, nothing else. The whole /fire surface ships behind the experimental-cc-routine-2026-04-01 beta header, so expect it to move around while the preview runs.
GitHub event. A new session starts automatically when a matching event lands on a connected repo. Two event categories are supported right now: pull request (opened, closed, assigned, labeled, synchronized, and the rest) and release (created, published, edited, deleted). You can react to a whole category or pin a specific action like pull_request.opened. This requires the Claude GitHub App installed on the repo; granting clone access with /web-setup is not enough on its own, and the trigger setup will prompt you to install the app.
The PR filters are where this gets interesting. You can narrow by author, title, body, base branch, head branch, labels, draft state, and merged state, each one paired with an operator: equals, contains, starts with, is one of, is not one of, or matches regex. So "only PRs into main whose head branch contains auth-provider" is a two-condition filter, and all conditions have to match. There is one gotcha here that bites people, and it is worth committing to memory. matches regex tests the entire field, not a substring. To catch any title containing hotfix you write .*hotfix.*, not hotfix. If all you want is plain substring matching, reach for contains instead.
Setting one up
The web form at claude.ai/code/routines is the full path. Click New routine, give it a name, and write the prompt. The prompt input carries a model selector, and whatever you pick runs on every execution. Add your repositories. Then pick a cloud environment, which is what governs network access, environment variables, and any setup script. The Default environment uses Trusted network access. That means common package registries and cloud APIs are reachable, but arbitrary hosts return a 403 with x-deny-reason: host_not_allowed. If your routine needs to reach your own service, switch the environment to Custom and add the domain by hand. After that, choose your trigger under Select a trigger, review which connectors are included (all of them are, by default, so prune the ones you do not need), and click Create.
The CLI is faster for the common case. Run /schedule in any session and describe what you want in plain language:
/schedule daily PR review at 9am
/schedule in 2 weeks, open a cleanup PR that removes the feature flag
Claude walks the same fields the web form collects and saves to the same account, so a routine you make in the CLI shows up on the web and in the Desktop app right away. One limit to know: /schedule from the CLI creates scheduled routines only. To attach an API or GitHub trigger, you have to edit the routine on the web. The CLI does cover management though, with /schedule list, /schedule update, and /schedule run to fire one on demand. And if /schedule returns "Unknown command," the usual cause is that you are authenticated with a Console API key or a cloud provider instead of a claude.ai login, or you have ANTHROPIC_API_KEY set in your shell, which takes precedence.
Two patterns worth stealing
A nightly check. Schedule a routine for every weeknight that reads issues opened since the last run, labels them, assigns owners based on the area of code referenced, and posts a digest to Slack through a connector. You walk in to a sorted backlog instead of a wall of untriaged tickets. The official docs describe this exact shape under backlog maintenance.
A PR-triggered review. Set a GitHub trigger on pull_request.opened, filtered to non-draft PRs, that applies your team's own review checklist and leaves inline comments on security, performance, and style before a human looks. This is the one most teams reach for first. It is also where output consistency starts to matter, and here is the catch. A routine fires the same prompt every time, but a loosely worded prompt still produces a different-shaped review on every PR. The fix is to move the actual review logic out of the prompt and into a skill committed to the repo, then have the prompt invoke it. The skill encodes your checklist once, in the Anthropic SKILL.md format, and every run reads the same instructions.
That skill is where Knack fits. The routine handles when the prompt runs. The skill handles what consistent output looks like, and Knack turns a 20-minute interview into that SKILL.md so you are not hand-writing it. Commit the skill, point the routine's prompt at it, and the nightly run and the PR run both behave the same way.
Limits and the sharp edges
Routines draw down your subscription usage the same way an interactive session does, plus a daily cap on how many runs can start per account. Per the launch post that cap is 5 daily routine runs on Pro, 15 on Max, and 25 on Team and Enterprise. Once you hit it, you either run on metered overage (if usage credits are on) or get rejected until the window resets. One-off scheduled runs are exempt from that daily cap, though they still consume normal subscription usage. GitHub webhook events have their own per-routine and per-account hourly caps during the preview, and events past the limit get dropped rather than queued.
The status indicator lies a little, and you should know how. A green run does not mean your task succeeded. All it means is that the session started and exited without an infrastructure error. A blocked network request, a missing connector tool, a task that Claude attempted and got plain wrong, all of those still show green. The only way to know what actually happened is to open the run and read the transcript. So for anything that matters, have the routine report its own outcome, posting a pass or fail to a channel rather than trusting the dot.
So routines end up turning Claude Code into something closer to a CI job that can think. Knack-authored skills keep that thinking consistent, and in my experience the difference between a routine that helps and one you quietly disable after a week is almost always how tight the prompt and the skill behind it are. Get those right, and the cloud will run them at 2 a.m. without you.