What this fixes
A 14-agent investigation (all findings verified against code + live telemetry) found a real guard reload loop that survived 1.8.20: a prune that frees >10% of bytes but barely reduces tokens (low-token-density content) reloads anyway → resumes a session whose token count is ~unchanged → re-fires HARD. Because a successful reload exits the daemon and a fresh guard respawns with the in-process breaker reborn at 0, this looped one confirmed prune+ping per cycle, invisible to the per-process breaker — inflating prune counts and churning sessions (kill→resume→re-bloat).
Two complementary backstops
- Post-prune token-PROGRESS gate — mirror the existing byte-ratio futile check but on tokens: if a prune reduced tokens by less than the min ratio, skip the reload as futile (it would re-trigger HARD immediately). Gates on progress, not an absolute floor, so a prune that frees real headroom still reloads even just above the trigger band.
- Disk-backed reload-rate ledger (
/tmp/cozempic_reload_<slug>.history) — cap reloads-per-window per session, surviving daemon respawn (the in-process breaker cannot). Catches the slower regrow loop. Env-overridable (COZEMPIC_RELOAD_MAX,COZEMPIC_RELOAD_WINDOW_S).
Detection
- Version-tagged prune counter — pings
prunes_v<version>alongsideprunesso a future prune-rate spike is attributable to a specific release (the plain counter was version-blind). Privacy-safe; honorsCOZEMPIC_NO_TELEMETRY.
Verified by a multi-agent adversarial QA fleet: no over-block of legitimate reloads, no under-catch of the loop, breaker accounting intact, inert on no-reload/overflow paths. Full suite 1100+ tests green.