choose-loop-wakeup-interval

Choose Loop Wakeup Interval

Pick a delaySeconds value for ScheduleWakeup that respects the prompt cache's 5-minute TTL, the scheduler's whole-minute granularity, and the [60, 3600] runtime clamp. The decision is structurally non-trivial: the common instinct "wait about 5 minutes" lands in the worst-of-both zone — pay the cache miss without amortizing the wait.

The reasoning travels with the ScheduleWakeup tool description at tool-call time, but by then the loop is already being scheduled. This skill hoists that reasoning to planning time, where it belongs.

When to Use

• Designing an autonomous /loop or ScheduleWakeup-driven continuation and picking the per-tick delay
• Planning a heartbeat cadence for a long-running agent that will poll, watch, or iterate
• Tuning polling cadence against cost or cache-warmth pressure
• Post-hoc reviewing loop costs and discovering the interval was mis-sized
• Writing a guide, runbook, or worked example that involves picking delaySeconds

Inputs

• Required: What the loop is waiting for (a specific event, a state transition, an idle tick, a periodic check)
• Required: Whether the reader of this tick will need fresh context (cache-warm) or can tolerate a cold re-read (cache-miss acceptable)
• Optional: Any known lower bound on when the awaited event could possibly occur (e.g. "the build takes at least 4 minutes")
• Optional: A cost ceiling on the total loop (number of ticks × per-tick cost)

Procedure

Step 1: Classify the Wait

Decide which tier the wait belongs to:

• Active watch (cache-warm): something is expected to change within the next 5 minutes — a build nearing completion, a state transition being polled, a process that was kicked off
• Cache-miss wait: nothing worth checking sooner than 5 minutes from now; the context cache will go cold and that is acceptable
• Idle: no specific signal to watch; the loop is checking in because it might find something, not because it will