The most common question I hear about Claude Code agents isn't "how do I build one," it's "how do I make it run when I'm not at the keyboard." Those are two different problems. An agent sitting in a terminal, waiting on your prompt, is still a manual tool. It only starts working for you at night once it fires on its own, every ten minutes, every hour, or on an event.
There's no single best deployment method. There are several, each suited to a different kind of automation, so instead of hunting for "the right one" I'll give you a framework for comparing the options, then walk through three concrete paths: the /loop command, Claude's cloud routines, and your own cloud on Modal or Trigger.dev. At the end: a decision table and two things worth knowing before you hand an agent the controls.
Framework: how to think about deployment
Before picking a method, set two axes. Every deployment sits somewhere on these scales, and they're what defines the trade-offs.
- Where does it run? On your own machine (which has to stay on) or in the cloud — Anthropic, Modal, Trigger.dev, your own VPS. This decides whether the automation survives closing your laptop.
- How deterministic is it? A full agentic loop with autonomous decision-making sits at one end, a script that runs the same way every time sits at the other. The more decisions you hand the model, the less predictable — and more expensive — the run.
The WAT framework — what you're actually deploying
A second framework keeps you from mistaking a piece of the automation for the whole thing. When you evaluate any method, ask which of these three parts you're actually deploying:
- W = Workflow — the process, the sequence of steps.
- A = Agent — the autonomous reasoning loop, the part that decides.
- T = Tools — the tools: APIs, integrations, file access.
This matters because some methods drop A by default. You get a process and tools, but no autonomous brain to connect them into a decision. Sometimes that's the point, a deterministic script is cheaper and safer. Sometimes it's a trap, because you expected an agent and got a rigid pipeline instead.
Where do skills fit in this? A skill can be pure W — "this is how I write a LinkedIn post" — or W + T, when the same skill also points at a tool, like an infographic generator behind an API. Worth knowing, because when I say "I'm deploying a skill," you should ask whether that means the process alone or the process plus its tools.
Method 1: the /loop command
This is the fastest way to get an automation running. You ask Claude Code for a loop, it fires on schedule, does the work, stops, and repeats. Zero configuration, you literally just ask for a loop.
How it works under the hood
Claude Code has three internal scheduling tools: cron_create, cron_list, and cron_delete. A cron is just a scheduled job. The schedule is internal to the Claude Code process, and individual crons are tied to a session — each session (a terminal tab, a desktop app window) has its own loops, and they don't interfere with each other.
How to set it up
You use plain language, there's no syntax to memorize. Type something like: "Set up a loop every 10 minutes that reminds me to take the trash out." Claude Code runs the /loop skill, calls cron_create, and replies in a plain sentence confirming how it understood the schedule. That's it.
Terminal vs. the desktop app
This difference matters more than it looks. The same loops behave differently depending on where you run them:
| Feature | Desktop app | Terminal |
|---|---|---|
Survives the /clear command | No (kills the cron) | Yes (crons keep running) |
| Maximum loop lifetime | 3 days | 7 days |
| Functionality | Basic | Fuller |
The takeaway is simple: if you rely on /loop for anything serious, use the terminal.
Jitter — a quirk worth knowing
So that all sessions don't hit the API in the exact same second, Claude Code adds up to 30 minutes of random jitter to recurring jobs. A schedule of "9:17 and 9:27" won't fire on the exact minute, but the interval, every 10 minutes, is preserved. So don't schedule anything on /loop that has to fire at an exact time.
Patterns worth knowing
- A self-expiring loop: "Run this every 10 minutes, and kill the loop after 24 hours." That way you're not leaving something grinding away forever.
- A
/clearloop every 5 minutes running alongside your working loop, to prevent context rot on a long run. - A real example: after uploading a video to YouTube, you set a loop that reads new comments every 10 minutes and replies to them, using the transcript as context.
Pros and cons
Pros: zero configuration; a full agentic loop (W + A + T); access to every skill, file, and slash command; you can call commands like /clear from inside the loop.
Cons: the session has to stay open; the machine has to stay on; maximum lifetime is 7 days; the interval is "roughly" fixed because of jitter.
WAT snapshot: runs on your machine · covers W + A + T · machine on: yes · session open: yes.
Method 2: scheduled tasks and Claude routines
You'll find both of these in the Claude desktop app, under Routines. They work almost identically, with one key difference: where they execute.
Local scheduled tasks
These run on your own machine. The desktop app has to be open and the computer has to be on. There's one behavior worth watching for: catch-up. If your computer was off for five days and you reopen the app, Claude Code looks at every local task that didn't fire and runs it now. If you don't want that, pause the tasks before you shut the machine down for a while.
Claude routines (cloud)
These run on Anthropic's infrastructure. Your machine can be off, the desktop closed, the terminal closed, they fire anyway. This is genuine 24/7. You do have to watch the limits, though.
- Daily run limits: Pro — 5 a day; Max — 15 a day; Team/Enterprise — 25 a day. Beyond that, extra usage is billed separately.
- Minimum interval: 1 hour. If you need something more frequent, use
/loopinstead. - Triggers: schedule, a GitHub event, or an API call (webhook). So routines can be event-driven, not just time-driven.
How both work
You write a prompt, full instructions, including which skill to run and in what order, and that prompt gets injected into a fresh Claude Code session the moment the schedule fires. The project carries your API keys, context, and skill access along with it.
One technical note: because cloud routines run against a cloned repository in Anthropic's cloud, environment variables are configured a bit differently than for local tasks. Check this before you're surprised that an integration can't see its own key.
Pros and cons
Pros: built directly into Claude Code, no extra infrastructure; full Claude Code capability (skills, shell, MCP, sub-agents, reasoning); the cloud variant is genuine 24/7 with no dependency on a machine; cloud routines can be triggered by API or GitHub events.
Cons: cloud routines have a 1-hour minimum interval; daily limits can feel tight, especially on Pro; local versions need a running machine and an open desktop app; a loosely scoped prompt in an autonomous run can trigger unwanted actions, watch it for a while before you trust it.
WAT snapshot
| Local task | Cloud routine | |
|---|---|---|
| Where | Your machine | Anthropic's cloud |
| Covers | W + A + T | W + A + T |
| Machine on | Yes | No |
| Session open | No (starts a fresh one) | No (starts a fresh one) |
Method 3: Modal and Trigger.dev
This is the "bring your own cloud" deployment. You write a script, push it to Modal or Trigger.dev, and set it to run on a schedule or from a webhook.
Two platforms
| Platform | Language | Character |
|---|---|---|
| Modal | Python | Serverless functions on a cron. Behaves like "a script on a timer." |
| Trigger.dev | TypeScript | A durable workflow engine that also handles cron. Feels a bit more agentic, it lets you split work across several scripts that call each other. |
Both can also act as API endpoints, so other automations can call them by webhook.
Where Claude Code helps
Claude Code works well with both. It knows how to push scripts to a dev environment and promote them to production, and how to configure environment variables on Modal or Trigger.dev so the deployed automation can reach your integrations. You don't have to write the Python or TypeScript yourself, that's what the agent is for.
Bonus: the Claude Agent SDK
By default, deployments on Modal and Trigger.dev give you only W + T, with no autonomous agent. If you want A back, you reach for the Claude Agent SDK.
What is the Agent SDK? It's essentially an endpoint version of Claude Code. Claude Code is an interface built on top of the Agent SDK. The plain Claude API gives you "just a brain that answers," and the Agent SDK gives you the brain plus hands, tool calls, a bash shell, file editing, web search, the whole loop.
The key behaviors to keep in mind:
- Stateless by default. Every request wakes up from scratch. To keep context, you pass a session ID.
- Auto-compacts, but there's no equivalent of
/clear. To clear context, you start a new session. - It supports sub-agents, MCP, hooks, skills, slash commands, a
CLAUDE.mdfile, memory, and compacting. - Requires a Claude API key. It doesn't run on your Claude subscription, so it's more expensive than running Claude Code directly.
- Update from May 13, 2026: monthly Claude credits can now count toward Agent SDK usage, but that's a separate, dedicated budget, not your weekly subscription usage. Check Anthropic's announcement for the details.
Pros and cons
Pros: the machine doesn't have to stay on; no session has to stay open; a lot of deterministic automation doesn't need AI at all, so you avoid API costs entirely; webhooks make them event-driven, not just time-driven.
Cons: AI processing is priced like an API (per token), not like a subscription; no agentic loop by default unless you use the Agent SDK; a bit more setup than /loop or routines.
WAT snapshot: runs on the Modal or Trigger.dev cloud · covers W + T (or W + A + T with the Agent SDK) · machine on: no · session open: no.
Also worth knowing: managed services and hooks
Two things a bit outside the main three, but useful when deciding.
Managed Agents is a newer Anthropic service for running fully managed agents on Anthropic's own cloud. My take: if you're already using Claude Code and you have your own infrastructure, stick with what you have. Managed Agents are most useful for people who've never opened Claude Code and want a ready-made starting point.
Hooks are event-driven automations, heavily deterministic. They fire when a specific event happens inside Claude Code. Typical triggers are pre_tool_use, post_tool_use, session_start, session_end, sending a message (say, a notification sound when Claude pings you), and specific actions like grep, glob, or a file edit. Hooks get powerful when you layer them: session_end triggers a backup, post_tool_use appends a log entry, and so on.
Decision table
When I have to pick a method, I compare everything in one place:
| Method | Where it runs | WAT | Machine on? | Session open? | Best for |
|---|---|---|---|---|---|
/loop | Your machine | W + A + T | Yes | Yes | Fast, ad hoc, fully agentic loops set up in seconds |
| Local scheduled task | Your machine | W + A + T | Yes | No | Recurring, project-tied jobs when the machine is on anyway |
| Claude routine (cloud) | Anthropic's cloud | W + A + T | No | No | Genuine 24/7 with the full Claude Code feature set |
| Modal / Trigger.dev | Their cloud | W + T (W + A + T with the SDK) | No | No | Deterministic scripts, webhooks, AI-free pipelines |
How to choose — and what to watch
I boil this down to a few rules that hold up almost every time.
There's no universally best method, you match the deployment style to the kind of automation. The two axes (where it runs + how deterministic it is) are your filter, and the WAT framework tells you what you're actually deploying, because some methods drop A by default.
In practice: /loop for fast iteration, cloud routines for genuine 24/7 with the full Claude Code stack, and Modal/Trigger.dev for deterministic or webhook-driven work where AI isn't needed. The Agent SDK is the bridge, you reach for it when you want a Modal or Trigger.dev deployment to keep acting agentic.
And one thing that matters more than which platform you pick: watch autonomous automations for a while before you trust them. The most common cause of unwanted actions is a loosely scoped prompt, the agent gets too much latitude and does something you didn't intend. Tighten the scope, watch a few runs, and only then leave it alone at night.