/loop vs Routines vs scheduled tasks: which to use

I built the same weekly pipeline report three different clumsy ways before I understood something obvious: there is not one way to repeat work in Claude, there are three, and they are for different situations. I was using the hands-on /loop for something that should have run on a schedule, and hand-running on a schedule something my own system should have triggered. Same goal, wrong tool, every time.

The confusion is understandable, because all three are ways to do a thing more than once. But they differ in what triggers the repeat, and once you see that, the choice is easy. This guide lays out /loop, Routines, and scheduled tasks side by side, and gives you the one question that tells you which to reach for.

Three kinds of repeating work

The reason there are three tools is that repeat means three different things. Sometimes you are sitting there, iterating on something, and you want Claude to keep working through it. Sometimes you want a job to happen on a schedule whether or not you are around. And sometimes you want your own system to decide when the work runs, by a clock or an event. Those are genuinely different, and each has its tool.

So the frame is not which is best, it is which trigger fits. Who or what kicks off each repeat: you, in the moment; a cloud schedule; or your own code reacting to time or an event. Name the trigger and the tool falls out, which is the whole point of this guide.

/loop: repeat while you're there

/loop is the hands-on one. You are in a session, working on a task, and you want Claude to keep iterating on it, pacing itself, continuing until the job is done or you stop it. It is for the moment when you would otherwise be typing continue over and over: you are present, engaged, and steering, just not wanting to nudge every single step.

The tell that /loop is right is that you are there and iterating. You want to watch, correct, and let it push forward on a task you are actively shaping. It is not for unattended work and not for schedules; it is for keeping momentum on something you are working on now.

Routines: scheduled and unattended

Routines are the scheduled ones. You define a job and a cadence, every Monday at six, every night, and it runs in the cloud, without you and without your machine. This is for the recurring work that should just happen: the weekly report, the nightly enrichment, the standing summary. You set it once and it shows up on schedule.

The tell for Routines is a calendar, not a keyboard. The work repeats on a clock, unattended, and the whole value is that you are not involved in triggering it. If you find yourself doing the same thing every Monday by hand, that is a Routine waiting to be created.

Scheduled tasks: your system triggers the API

The third is your own scheduled task calling the API. Here your system, a cron job, a workflow tool, an event in your app, decides when the work runs and calls Claude through the API to do it. This is for when you want full control over the trigger and the surrounding logic: run this when a deal hits a stage, or every hour, or when a webhook fires.

The tell is that the trigger lives in your world, not Claude's. You are not using Claude's built-in scheduling, you are wiring Claude into your own pipeline as a step that your system invokes. It is the most flexible and the most work, because you own the scheduling and the plumbing around the call.

The decision, plainly

Put together, the choice is one question with three answers. Are you there right now, iterating, and want Claude to keep going: /loop. Should it run on a schedule, unattended, using Claude's own scheduling: a Routine. Should your own system trigger it, by time or event, with your logic around it: a scheduled task on the API.

Almost every mismatch comes from ignoring the trigger and picking by habit. The weekly report is not a /loop, because you should not have to be there; it is a Routine. The deal-stage-change email is not a Routine, because Claude's clock does not know your deal stages; it is a scheduled task your system fires. Name the trigger first.

• You, now, iterating on a task: /loop.
• A cloud schedule, unattended, Claude's own scheduling: Routines.
• Your system, by time or event, with your logic: a scheduled task calling the API.
• The question that decides it: what triggers the repeat?

One task, all three ways

To make the distinction concrete, take one goal, a weekly competitive update, and watch it change shape across the three. As a /loop, you sit down Friday and iterate with Claude until the update is right, present and steering. As a Routine, you define it once and it runs every Friday at eight in the cloud, and you just read it. As a scheduled task, your own system, maybe triggered when a competitor ships a release you track, calls the API to draft the update the moment the event fires.

Same output, three triggers, and the right one depends entirely on when you want it to happen. If you want to craft it this week, /loop. If you want it every week without thinking, a Routine. If you want it the instant something happens, a scheduled task on your event. Seeing one task wear all three shapes is the fastest way to internalize which is which.

Combining them

These are not mutually exclusive, and real setups mix them. A Routine can run a job that internally fans out to background agents. A scheduled task your system triggers might, once running, use the Agent SDK's loop to iterate. You are not locked into one; you pick the trigger with the right tool and compose the rest underneath.

The layering that is common in GTM: your system watches for an event and triggers a task, or a Routine runs on a cadence, and the actual work inside is an agent doing multiple steps. The repeat-trigger tool and the do-the-work engine are different choices, and you make both.

A practical note on cost and effort: the three also differ in how much you build. /loop is zero setup, you just use it. A Routine is a little setup, define and schedule, then nothing. A scheduled task is the most, because you own the trigger, the scheduling, and the plumbing around the API call. Reach for the heaviest option only when you genuinely need control the lighter ones cannot give, not because building a pipeline feels more serious.

Where people pick wrong

The most common mistake is hand-running a Routine: doing the same scheduled thing manually, week after week, because you never moved it off /loop or out of a live session. If you are present for something that did not need you present, it wants to be a Routine or a scheduled task. Your attendance is the smell.

The mirror mistake is over-engineering a one-off into a scheduled task when you just needed to iterate on it once with /loop, or reaching for your own API scheduling when a built-in Routine would have done it with none of the plumbing. Match the effort to the trigger: do not build a pipeline for something you will do twice, and do not hand-run something you do every week.

• Hand-running week after week what should be a Routine, your attendance is the tell.
• Building your own API scheduler when a built-in Routine would have sufficed.
• Using /loop for unattended work that should run without you there.
• Over-engineering a genuine one-off into a scheduled pipeline.

The GTM version

Mapped onto a GTM stack, the three sort cleanly. The Monday pipeline report and the nightly enrichment are Routines, scheduled, unattended, no you required. Deep-cleaning a messy list you are staring at right now is /loop, you are there, iterating. And send a tailored nudge the moment a deal sits untouched for two weeks is a scheduled task, because your CRM knows the deal stage and Claude's clock does not, so your system fires the call.

The report I built three ways was a Routine all along; I just kept reaching for the tool in front of me instead of asking what triggered it. Ask the trigger question first and you will build each repeat once. Which of your recurring tasks are you still triggering by hand that a schedule should own?

How to set it up

Frequently asked questions

Sources & further reading

• Claude Code overview (Anthropic docs)
• Messages API reference (Anthropic docs)

Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.