A paced run pauses 300 minutes after every 120-minute window by default: the bundled pace is 120/300, so an implement run that outlives its first window stops every stage, landing moves included, for five hours unless a flag or a configuration layer sets the pause. The product thinker ruled on 2026-10-10 that no pause is needed and that the default must be zero.

Frontmatter

.abcd/work/issues/resolved/iss-2610100546338578-a-paced-run-pauses-300-minutes-after.md
open on GitHub ↗ · commit history ↗

mentions2

• dcn-26101000000000012026-10-10 — Ruling of the product thinker on the bundled pace (given in a build session, on the report that its run had entered a 300-minute pause): "Remove that forever, we don't need a pause", then "it must be set to zero by default". The bundled pause of decision 5 of itd-2609201925079472 (120 minutes of work, 300 of pause) becomes 0: `BundledPauseMinutes` is 0, so a run that sets no pace runs window after window with no pause, and a repository or machine that wants one sets `pace.pause_minutes`. The working window, the sub-agent ceiling and the fix rounds are unchanged. The intent's record keeps decision 5 and its first criterion as written (120/300), which this entry supersedes for the pause; iss-2610100546338578 carries the change.
• iss-2610100602595553A rate limit gets no wait once the pause is zero: pacing's rate-limit checkpoint (itd-2609201925079472) ends the run's window early and sets next_eligible_at to now plus the run's pause, and with the bundled pause now 0 (iss-2610100546338578) the next step hands the same work out again at once, so a rate-limited run can hit the same limit again and again. The product thinker ruled on 2026-10-10 that a rate limit waits on its own, independent of the pause, as work after pacing and the drain (itd-82).