Two-band daemon context reset — opportunistic (soft) recycle at a clean point + mandatory (hard) drain-and-reset

Operator idea (2026-07-03). Extend the #86 single-threshold reset into a TWO-BAND policy so daemons recycle without ever losing in-progress context. ## The two bands - **Soft / opportunistic (default ~400k, `reset_soft_threshold_tokens`):** at or above this, IF the daemon is at a clean checkpoint — nothing new started, no in-flight/running work — it may take a #76 make-before-break reset "for free" (schedule/trigger it). It does NOT force holding new work; it just opportunistically recycles when it happens to be idle/clean. Zero context loss because a clean state means the handoff scratchpad captures everything. - **Hard / mandatory (default ~600k, = current `reset.context_threshold_tokens`, rename to `reset_hard_threshold_tokens`):** at or above this, the current #86 behavior kicks in — mark reset_pending, STOP pulling new work, finish/drain in-flight, then #76 reset. The backstop that guarantees a reset before compaction. ## "Clean checkpoint" detection (the crux — never reset with pending/running work) The daemon only takes the soft/opportunistic reset when it has NO in-progress work that would be lost: - Orchestrator: no dispatch_requests in flight for its scope (no workers building), no claimed coordination signals, no in-progress merge, coordination queue drained. - Ops/refine: no claimed/in-progress work items. This is the whole point — we don't reset while there's running/pending work whose live context won't survive into the handoff scratchpad. ## Why (the cost rationale — verified reasoning on prompt caching) Even with prompt caching, cost-per-turn scales ~linearly with context size: the cached prefix is re-read every turn at the cache-read rate (~10% of input price, but on the WHOLE prefix), so an 800k session costs ~5× the per-turn cache-read of a 150k one, every turn. For a long-lived daemon (orchestrator/ops) that's ongoing spend. A #76 reset drops the prefix back to ~fresh+handoff (~50-100k), and the one-time re-grounding cost is amortized over many future turns. So opportunistic recycling at a clean point is a real quota/token lever, not just the "don't compact mid-task" correctness win. (Keeping a session warm avoids re-cache WRITE costs but does NOT reduce the per-turn READ premium of a huge prefix — so "never let it go stale" ≠ cheap for big contexts.) ## Work sketch 1. Config: add `reset_soft_threshold_tokens` (default 400000, env) alongside the existing hard threshold (rename/keep 600000). 2. On checkin, compute a `reset_band` (none | soft | hard) from context_used vs the two thresholds (extends #86's applyResetPendingUpdates). 3. Surface the band on the roster (badge) so it's visible. 4. Daemon behavior (AgentConventions): soft → "if you're clean/idle, take a #76 reset now"; hard → current reset_pending hold+drain. The orchestrator's clean-check uses recall_dispatch_queue (in-flight requests) + recall_signals (claimed) + its own merge state. 5. Guard: don't opportunistically reset a daemon that's near end-of-life/winddown, or with < N future turns expected (no amortization benefit). ## Relationship - DEPENDS ON #86 (the reset_pending mechanism + hard threshold) and #76 (make-before-break reset). This is band #2 (soft/opportunistic) + clean-state gating layered on top. - Not urgent (operator: "not something we need to do now") — explore/refine.