Claude Loops have two modes — fixed interval and dynamic. The choice between them is not aesthetic. It changes how much your loop costs, how fast it reacts, and how often it interrupts you.
The 30-second decision
Pick fixed mode when you can name the cadence in seconds. Pick dynamic mode when you cannot.
That is the whole heuristic. Everything below is "why that heuristic works."
Fixed mode in plain terms
You pass an interval. Claude runs the task on that exact clock. Predictable, easy to reason about, easy to cap costs on.
/loop 10m /code-review
Use it for:
- Metrics that update on a known schedule.
- Cron-replacement tasks where you actually want clock cadence.
- Loops where the cost of an unexpected run is meaningful (you do not want it firing more than planned).
Dynamic mode in plain terms
You skip the interval. At the end of each iteration, Claude decides how long to wait by calling ScheduleWakeup. The model picks the delay based on what it observed and what it is waiting for.
/loop watch the deploy and end when production is live
Use it for:
- External processes with variable duration (deploys, migrations, CI).
- Polling that should adapt: fast while state moves, slow while idle.
- Loops with an explicit "done" condition Claude can detect.
The cache-window economics
This is the part most people miss. Anthropic's prompt cache has roughly a 5-minute TTL. Wake-ups within the window read from cache (fast, cheap). Wake-ups past the window pay a full cache miss.
| Delay range | Cache state | Right for |
|---|---|---|
| 60-270s | Stays warm | Active polling of changing state |
| ~300s | Worst of both | Avoid — you eat the miss without amortizing it |
| 1200s-3600s | Cold (but worth it) | Genuinely idle waits — checking back in once in a while |
Dynamic mode is good at this. Fixed mode forces you to think about it. If you pick the wrong fixed interval (say, 5 minutes for something that takes 8), you burn the cache 8 times waiting. Use dynamic mode and Claude picks a saner delay.
A practical example
Imagine polling a CI build that usually takes 7-15 minutes.
Fixed mode (60s): 7-15 iterations, 6-14 unnecessary cache misses, lots of noise.
Fixed mode (5m): 2-3 iterations, 1-2 misses, but you might learn about the result up to 5 minutes late.
Dynamic mode: Claude probes once, sees the build is queued, sleeps long. Probes again, sees it is running, drops to 90-second polls. Catches the green check within ~90s of completion.
Dynamic wins on both cost and latency. It is the default we recommend for anything CI-, deploy-, or queue-shaped.
When fixed mode actually wins
Three cases:
- The cadence is exact. A metric updates every minute on the dot. Fixed 60s. No ambiguity.
- You want cost ceilings. "Run no more than 12 times per hour, ever." Fixed 5m.
- You want timing audits. Compliance loops where "ran at HH:00:00" matters.
Recommended defaults
- Watching a known-cadence metric: fixed at the metric's update rate.
- Watching CI / deploys / migrations: dynamic, with a stop condition.
- Daily / hourly digests: use
/schedule, not/loop. - Inbox / Slack monitoring: dynamic — activity is bursty.
- Log scouts: fixed at 5-10m is usually fine.