Claude Code added /loop for running a prompt repeatedly at a chosen interval while the session remains open. The instruction acts like a natural-language scheduled task, suitable for reading new logs, checking routes, reviewing incoming pull requests, or summarizing changes.
The supplied example monitored authentication logs every five minutes after a deployment, filtered 401 and 403 responses, and raised an alert when the rate crossed two percent. It found a mobile client with an outdated token before support reports accumulated. This is a useful shape of work because the agent observes, classifies, and escalates rather than silently changing production.
Scheduled tasks expire after three days, belong to the session, and are limited to 50 per session. Those constraints separate the feature from CI, observability platforms, and durable job schedulers. It is a temporary watch assistant, not infrastructure.
The task dies when the session closes
/loop lives in the conversation. Close the terminal, the tasks stop. Start a new conversation, the list clears. Resume with --continue may restore what has not expired; a fresh session will not. That is enough to keep the feature apart from company cron, GitHub Actions, and any worker that has to survive a closed laptop.
The cap of 50 tasks per session and expiry after three days sharpen the cut. You can watch a deploy, a migration window, a long PR. You cannot "monitor authentication forever". Anyone who needs longer duration uses a cloud routine, a Desktop task, or CI. /loop is fast polling while you are still in context.
A one-minute minimum interval and execution only while the session is idle also change the expectation. If the agent is mid-refactor, the log check waits. There is no catch-up for missed intervals: when it returns, it fires once. Treating this as Prometheus disappoints on the first real incident.
The decision is therefore narrow: does this window of work need a repeated eye, and will I keep the session alive for that? If the answer depends on the machine staying on over the weekend, the wrong tool is already in use.
The prompt needs a threshold, an owner, and a channel
The 401/403 example with a two percent threshold works because the instruction already carries a slice, a metric, and an action. "Watch the logs" does not. Without a threshold the agent summarizes noise. Without a channel it prints into the transcript and nobody sees it. Without an owner the alert falls into a void.
Write the prompt as a one-page runbook: what to read, how to filter, which number fires, what to do (notify, open an issue, do not apply a hotfix alone), when to stop. /loop 5m without that text only spends turns. If the team already has loop.md in the repository, use it for the session default; incident-specific prompts stay on the command line.
The owner is a person, not "the team". Who gets the ping at 23:00? Who cancels the loop when the incident closes? An orphan task for three days is token cost and attention cost. List active loops at the start of the day the way you list PRs.
The escalation channel has to be boring and explicit: a session message, a team chat thread, a PR comment. An agent classifying a spike and "taking action" in production is a different risk category. Watch work escalates. Mutation waits for a human.
Watch work without side effects on the repository
The useful shape is observe, classify, notify. Read error.log, check a route, summarize commits, comment if CI went red. The fragile shape is a loop that also commits, merges, rolls back, or runs kubectl. Every five minutes, the error surface multiplies.
If the session is in auto mode, the loop inherits that permission. The combination is tempting and a poor first use: a vague prompt, a classifier, a short interval. Start with a mode that still asks before writes, or with deny on push and apply. Only then, if the prompt is narrow, relax.
New morning PRs and end-of-day commit summaries fit. They are triage. Complex implementation, an incident with automatic mitigation, and "fix it if it breaks" do not. The 50-task limit exists for the session scheduler, not as an invitation to fifty production automations.
A practical rule: if the action would need a postmortem when it goes wrong, it does not enter /loop. It enters a pipeline with a log, an owner, and rollback. The agent can watch that pipeline; mutation stays in the system that already has an owner.
The running terminal is part of the cost
While the loop runs, the session occupies a machine, context, and invoice. Each iteration resends a prompt. A five-minute interval for 48 hours is dozens of turns, even when the result is "nothing changed". For auth logs after a deploy that can be worth it. For "see if someone commented on the PR", a webhook or CI often notifies cheaper.
There is also attention cost. A notification every cycle trains a person to ignore it. A notification only at the threshold requires trust in the prompt. Match the interval to the window's risk: shorter in the first two hours after deploy, longer after. Claude can pick the interval when you omit the number; for an incident, prefer the fixed cron you understand.
Backgrounding the session keeps the loop without the terminal in the foreground. It is still your machine. An "agent on call" policy has to say whether that is acceptable at night, and what happens if the machine sleeps.
If the team already pays for real observability, /loop does not compete with it. It fills the two-hour hole in which nobody wants to open the dashboard. That honesty avoids the slide where the feature becomes "an SRE platform".
Fifty jobs and three days are the envelope
Use the envelope as a spec. Fits: watching error rate after an auth change; rereading a migration log; following a PR to merge; reminding yourself to look at the canary. Does not fit: an eternal nightly job, fan-out across every service, a pager replacement.
When the window passes three days, recreate on purpose or move to a durable tool. Recreating automatically to dodge expiry only hides that the task was already infrastructure. The product imposes the limit so you do not forget a spent loop still running.
In the weekly review, ask which loops existed, what they escalated, what was a false positive, what nobody read. If the list is empty and the team "uses /loop", the feature is decorative. If it is full of mutations, the feature is in the wrong place. The dull middle (few loops, narrow prompt, live session, human escalation) is the only one that holds.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
