AnswerQA

How do I watch a long-running build without burning prompt cache?

Answer

Use /loop with no interval to let Claude self-pace; Claude often picks the Monitor tool, which streams a background script's output line-by-line instead of re-running a prompt on a cron. That avoids the 5-minute prompt-cache cliff and the cron jitter you do not want.

By Kalle Lamminpää Verified May 7, 2026

A short poll (60 seconds) keeps the prompt cache warm; a long poll (20+ minutes) amortizes the cache miss. A 5-minute poll lands on the worst edge of the cache TTL, so prefer a tighter or much longer cadence, or skip polling entirely with the Monitor tool.

Three ways to run something on a schedule

/loopRoutines (cloud)Desktop scheduled tasks
Where it runsYour terminalAnthropic cloudYour machine
Requires open sessionYesNoNo
Requires machine onYesNoYes
Min interval1 minute1 hour1 minute
Persistent across restartsRestored on --resume if unexpiredYesYes
Local file accessYesNoYes

Use /loop when the session is already open and the work needs your local files. Use Routines for true unattended work that runs whether your laptop is on or off. Use Desktop scheduled tasks for “every morning, run X locally”.

Three shapes of /loop

/loop 5m check the deploy

Fixed interval. Claude converts the interval to a cron expression and schedules the job. Seconds round up to the nearest minute. Non-cron-clean intervals (7m, 90m) round to the nearest interval that fits a cron step; Claude tells you what it picked.

/loop check the deploy

Dynamic. No interval, only a prompt. Claude chooses the cadence each iteration based on what it sees, and may use the Monitor tool directly instead of re-running a prompt. Monitor streams the background script’s stdout line by line; the loop ends when the script exits or after the 7-day expiry, whichever comes first. On Bedrock, Vertex AI, and Microsoft Foundry, dynamic loops fall back to a fixed 10-minute schedule.

/loop

No prompt either. On Anthropic-direct sessions, this runs the bundled maintenance prompt at a Claude-chosen cadence. On Bedrock, Vertex AI, and Microsoft Foundry, bare /loop prints a usage message instead of starting the maintenance loop; supply at least an interval or a prompt on those providers. Useful for “babysit my session for a while” on Anthropic direct; less useful for actual work.

When the Monitor tool replaces a poll

The cheapest watch is one that does not re-run a prompt at all. npm run build, pytest --watch, kubectl logs -f are scripts that already emit output as work progresses. Monitor runs them in the background and forwards each new stdout line into the parent session as a notification.

/loop tail the kubernetes deployment until rollout completes

Claude reads “until rollout completes” as “this has a terminating event” and reaches for Monitor on a kubectl rollout status background script. The session does not poll on a clock; it reacts when the script writes a new line. Token cost is roughly proportional to actual output volume, not to poll frequency.

Cache windows that matter

Anthropic’s prompt cache uses a default 5-minute TTL that refreshes whenever the cached prefix is reused. Three regimes:

  • 60–270 seconds: Each iteration reuses the cache and refreshes the TTL. Right for active polling where state is about to change.
  • Around 300 seconds (5 minutes): Edge risk. Whether the cache is still alive depends on timing variance you cannot control; some iterations hit cold, some warm. Avoid this exact tier.
  • 20+ minutes: Every iteration is a cache miss anyway, so the cost is predictable. Right for genuinely idle waits where you do not want a tight poll.

Translation for /loop: prefer /loop 4m over /loop 5m if you want reliably-cached iterations, and /loop 20m over /loop 10m if you do not need the resolution. The Monitor path side-steps the issue entirely; that is its whole point.

Footguns

/loop 5m is the worst-case interval to pick. It is the round-number minute most people reach for, and it sits exactly on the prompt-cache TTL boundary. Each iteration risks a cold start depending on timing variance you cannot control; the cost per iteration trends higher than /loop 4m and the responsiveness is no better than /loop 10m. Either stay inside the cache window (under 5 minutes) or commit to a longer interval.

/loop dies when the session dies, and Monitor tasks are gone for good. Closing the terminal, exiting Claude with Ctrl-D, or losing the SSH connection ends the loop. --resume restores unexpired prompt-based recurring loops within the 7-day window, but background Bash and Monitor tasks are not restored on resume; whatever they were watching needs to be re-launched explicitly. If the work matters across machine restarts, use Routines or Desktop scheduled tasks instead. /loop is for “while I am in this session”.

Cron rounding swallows your interval. /loop 7m does not run every 7 minutes; it rounds to whatever cron-clean step Claude picks (5m, 10m, etc.). The CLI confirmation says what was scheduled, but it is easy to skip past. If the exact cadence matters (e.g., a 10-second poll on a deploy), use Monitor with a script that paces itself instead of /loop with a tiny interval.

Monitor’s stdout line-by-line streaming is per line, not per write. A script that batches output (“buffering until the build finishes”) streams nothing for minutes, then dumps thousand lines at once into your session. Most tools do this when stdout is not a TTY. Defense: pipe through stdbuf -oL or use the tool’s flush flag (python -u, node --no-deprecation does not help; use process.stdout.write and \n). Otherwise the loop looks frozen and then floods.

Seven-day expiry applies to all of them. /loop and dynamic Monitor-backed loops both end automatically after 7 days. Long-running observability (“watch this thing for a month”) needs Routines or Desktop scheduled tasks, plus its own restart logic. Setting it and forgetting it for a quarter does not work.

When NOT to reach for /loop

  • The work needs to survive your laptop closing. Use Routines or Desktop scheduled tasks. /loop requires the open session.
  • You can compute the answer once. “Is this PR mergeable?” is a one-shot tool call, not a loop. Polling for state that already settles in the first call is pure overhead.
  • The thing you are watching emits no output. Polling a database for a row that does not exist yet is the right shape for /loop with a tight cadence; Monitor does not help if there is no stdout to stream. Pick /loop 1m and accept the cache miss.
  • You actually want exactly-once semantics. /loop runs a prompt; if the prompt’s side effect matters, two iterations either duplicate work or double-act. Idempotent prompts only.
  • The schedule needs to fire whether you are at your desk or not. Routines (cloud) is the only one of the three that does not need your machine on. /loop and Desktop scheduled tasks both quit when the laptop closes.

Sources

  • Run prompts on a schedule
    Authoritative: `/loop` shapes (fixed interval, dynamic, built-in maintenance), the Monitor tool path for dynamic loops, jitter rules, 7-day expiry, and the comparison with Routines and Desktop scheduled tasks.
  • Tools reference
    Monitor tool semantics: runs a script in the background, streams stdout line-by-line as notifications, avoids the cost of re-running a full prompt on a poll.
  • Prompt caching (Anthropic)
    5-minute TTL on the prompt cache. Why short polls (60s) keep the cache warm and 5-minute polls fall off the worst possible edge.

Was this helpful?