/loop re-runs a prompt on a schedule. The session stays alive between iterations, so each
run has the full history of the ones before it — useful for watching something that changes
over time rather than asking once.
/loop 5m check if the CI run on this branch has finished
| Mode | How to invoke | Cadence |
|---|---|---|
| Interval | /loop 5m <prompt> |
fixed — every 5 minutes |
| Self-paced | /loop <prompt> |
the model picks the next delay after each run |
| Maintenance | /loop |
self-paced, prompt resolved at fire time |
A fixed wall-clock cadence. Accepts values like 30s, 5m, 1h. Intervals shorter than the
self-paced minimum are still honoured exactly as written.
After each iteration an evaluator chooses when to run next, bounded to 1 minute – 1 hour, defaulting to 5 minutes when it can't be reached. Use this when the right cadence depends on what it finds — polling a slow build hard for the first minute and then backing off.
Bare /loop resolves its prompt at fire time from a loop.md in your project, falling back
to a built-in maintenance prompt. Because it resolves at fire time, editing loop.md changes
the next iteration without touching the loop itself.
| Command | Effect |
|---|---|
/loop [<interval>] <prompt> |
start a loop |
/loop status |
mode, cadence, iteration count, next fire time, last reason |
/loop pause |
stop firing; state is kept |
/loop resume |
start firing again |
/loop stop |
remove the loop |
nextFireAt is the single source of truth for when the next run happens; the in-memory timer
is always derived from it, never the reverse.
The practical consequence: there is no backlog. Only one future timestamp is ever tracked,
so a loop whose fire time passed while the process was down fires once when next observed —
it does not replay the runs it missed. A /loop 1m left overnight will not wake up to 500
queued iterations.
Warning
Every iteration is a real model call billed against your tier and budget. A 1-minute loop is 1,440 turns per day. Prefer self-paced mode unless you specifically need a fixed cadence, and use
/loop statusto check the iteration count before leaving one running.
Stored on the session record, not the message stream. It rides with the session — restored on resume, deleted with it, and untouched by compaction.
/loop is the odd one out: it improves freshness, not correctness. It re-runs the same
prompt — it doesn't make any single answer better. Where it helps is work whose state changes
under you while you wait.
| Use case | Effect | Why |
|---|---|---|
| Migration | Better | Long runs where you want progress checked without babysitting: "every 10 minutes, list the files still using the old API". |
| Feature Development | Better | Watching a build or CI run to completion, so you find out it went red without polling by hand. |
| Testcase creation | Some | Useful against a flaky test — re-run it on a schedule and collect how often it actually fails. |
| Reviewer | Some | Only for a PR still receiving pushes; re-reviewing a static diff repeats the same answer. |
| Bug-Fixer | Little | A bug doesn't change on a timer. Use /bug-fix. |
If the answer would be identical five minutes from now, /loop adds cost and nothing else.
/goal is one continuous
effort toward a target; /loop is repeated separate checks over time.