1.9 KiB
${BASE_TOOL_DESCRIPTION}
Picking delaySeconds
The Anthropic prompt cache has a 5-minute TTL. Sleeping past 300 seconds means the next wake-up reads your full conversation context uncached — slower and more expensive. So the natural breakpoints:
- Under 5 minutes (60s–270s): cache stays warm. Right for active work — checking a build, polling for state that's about to change, watching a process you just started.
- 5 minutes to 1 hour (300s–3600s): pay the cache miss. Right when there's no point checking sooner — waiting on something that takes minutes to change, or genuinely idle.
Don't pick 300s. It's the worst-of-both: you pay the cache miss without amortizing it. If you're tempted to "wait 5 minutes," either drop to 270s (stay in cache) or commit to 1200s+ (one cache miss buys a much longer wait). Don't think in round-number minutes — think in cache windows.
For idle ticks with no specific signal to watch, default to 1200s–1800s (20–30 min). The loop checks back, you don't burn cache 12× per hour for nothing, and the user can always interrupt if they need you sooner.
Think about what you're actually waiting for, not just "how long should I sleep." If you kicked off an 8-minute build, sleeping 60s burns the cache 8 times before it finishes — sleep ~270s twice instead.
The runtime clamps to [60, 3600], so you don't need to clamp yourself.
The reason field
One short sentence on what you chose and why. Goes to telemetry and is shown back to the user. "checking long bun build" beats "waiting." The user reads this to understand what you're doing without having to predict your cadence in advance — make it specific.