I pushed a branch and wanted Claude to watch CI until it went green, then fix whatever broke. Before /loop, I'd either sit there checking manually or write a bash script to poll. Now I type one line and walk away.
What You'll Learn
- What /loop does and the two ways to use it
- Self-pacing: why letting Claude choose the interval is usually better
- The Monitor tool and how it replaces polling entirely
- Practical examples for CI, dev servers, and long builds
Two Ways to Loop
Fixed interval:
/loop 5m check CI on my PR
Claude runs the prompt every 5 minutes. Simple, predictable, works for anything with a known cadence.
Self-pacing (the interesting one):/loop check CI on my PR
Omit the interval and Claude decides when to check next. It looks at what it found, estimates how long the thing it's waiting for will take, and schedules the next check accordingly.
Why this matters: a fixed 60-second interval on an 8-minute build means 8 cache misses for nothing. Self-pacing might check at 30 seconds (quick look), then wait 270 seconds (build is running, no point checking sooner), then check again right when it's likely done.
💡 Self-pacing uses a 5-minute prompt cache window. Claude tries to stay under 270 seconds between checks to keep the cache warm. If there's genuinely nothing to check, it'll sleep longer — up to 30 minutes.
The Monitor Tool: Skip Polling Entirely
New in v2.1.98. Instead of checking repeatedly, Claude can spawn a background watcher that streams events into the conversation in real time.
Tail server.log in the background and tell me the moment a 5xx shows up
Claude starts a Monitor that watches the log file. Each new event appears as a message in your transcript. When a 5xx appears, Claude reacts immediately — no polling delay.
This is fundamentally different from /loop. /loop checks at intervals. Monitor watches continuously and notifies the moment something happens.
Best use cases for Monitor:
- Tailing log files for errors
- Watching a dev server for crashes
- Babysitting a PR's CI pipeline
- Monitoring a training run's metrics
Best use cases for /loop: - Periodic health checks
- Recurring tasks ("check for new issues every hour")
- Anything where you want Claude to take action on each tick, not just react to events
Three Practical Setups
Watch CI and fix failures:
/loop check CI on my PR and fix any failures
Claude checks CI, and when a test fails, it reads the error, writes a fix, pushes it, and checks CI again. I've had this fix two sequential test failures while I was at lunch.
Babysit a deploy:/loop 2m check if the deploy to staging finished and run the smoke tests
Fixed interval because deploys have a predictable timeline.
Auto-restart crashed dev server:Watch the dev server. If it crashes, read the error, fix the code, and restart it.
This one uses Monitor, not /loop. Claude watches the process and reacts the moment it dies.
What to Watch Out For
⚠️ /loop burns tokens on every tick. A 60-second interval running for an hour is 60 API calls. Self-pacing helps, but keep an eye on usage for long-running loops.
⚠️ Monitor keeps a background process alive. If you forget about it, it keeps streaming events and consuming context. Use/tasksto see active monitors and stop them when done.
❌ Neither /loop nor Monitor survives a session restart. If Claude Code crashes or you restart, you need to set them up again.
Setting Up
/loop is a bundled skill — it's available in every Claude Code session without installation. Monitor is a built-in tool available from v2.1.98 onward. Run claude --version to check and claude update if needed.
The shift from "check every N minutes" to "watch and react" is subtle but significant. It's the difference between a cron job and a colleague who's actually paying attention.