[Bug] Auto-compact consumes double-counted usage: preTokens=1,364,156 on a 1M window while real context was ~335K (33%)

Bug Description
Auto-compact fired with preTokens: 1,364,156 on a 1M-context model — a value larger than the model window itself, and ~4× the session's real context (~335K, i.e. 33% utilization). The compaction trigger appears to consume raw per-request usage totals that are intermittently double- (and here quadruple-) counted, instead of a sanity-checked context estimate.

Environment Info

• Platform: linux (CachyOS, kernel 7.1.3-2)
• Version: 2.1.220
• Models in session: claude-sonnet-5, claude-fable-5 (1M window active — requests at 318K–335K input succeeded)
• No auto-compact overrides: autoCompactEnabled unset, DISABLE_AUTO_COMPACT/CLAUDE_CODE_AUTO_COMPACT_WINDOW unset at the time.

What happened

During a ~1h45m interactive session (2026-07-31), the main-chain assistant usage totals (input_tokens + cache_read_input_tokens + cache_creation_input_tokens) recorded in the session JSONL showed a recurring pattern of transient ~2.0× spikes that self-correct on the next request:

| time (UTC) | usage total | note |
|---|---|---|
| 10:08:33 | 101,778 → 211,034 → 108,228 | ×2.07, self-corrected |
| 10:38:12 | 242,580 → 491,120 → 248,843 | ×2.02, self-corrected |
| 11:32:02 | 318,466 → 641,650 → 321,843 | ×2.02, self-corrected |
| 11:36:30 | 334,316 → 1,359,713 | ×4.07 — never corrected |
| 11:41:19 | compact_boundary | trigger: "auto" |

The final compact_boundary event:

{
  "trigger": "auto",
  "preTokens": 1364156,
  "postTokens": 22154,
  "cumulativeDroppedTokens": 1342002,
  "durationMs": 263205
}

preTokens matches the anomalous 1,359,713 reading (+~4K), not the real context. The in-product indicator simultaneously jumped to "0% until auto-compact" while a statusline computing context from the same stdin showed ~33% of the 1M window.

Why this must be an accounting artifact

• A 1,364,156-token prompt cannot exist on a 1,000,000-token window — the request would be rejected. The session's real context, per every stable reading before and after the spike, was ~335K.
• The ×2.0 spikes bracket exact doubling (2.02–2.07) and revert to the organic growth curve on the next request — consistent with a retried/duplicated request's usage being summed instead of replacing the previous reading. The fatal spike is ×4.07 ≈ two compounded doublings.
• Same signature observed in earlier sessions (2026-07-16): stable 710K → reported 1,427K, and 533K → 1,069K (~×2.0), each followed by premature auto-compact and near-thrashing (post-compact token count still above the threshold, retriggering next turn).

Expected

The auto-compact trigger should use a sanity-checked context estimate, e.g.:

• ignore/clamp usage totals that exceed the active model window (physically impossible values),
• reconcile usage across retries of the same request rather than summing,
• or fall back to the last stable reading when a single-request jump exceeds a plausibility band.

Actual

A single inflated usage reading is consumed at face value, discarding ~1.34M "tokens" (really ~313K) at 33% real utilization, costing a 263s compaction plus lossy-summary reconstruction.

Impact

• Premature loss of ~2/3 of the usable 1M window in long sessions.
• Thrash risk: when the inflated value persists, post-compact accounting can remain above the threshold and retrigger.

Possibly related

• #72600 — same observable (auto trigger, preTokens far below the 1M window, no overrides). Notably its preTokens: 468,102 ≈ 2 × ~234K, so it may share this double-counting mechanism rather than a mis-anchored threshold.
• #73399 — context-percentage accounting vs [1m] variants.

Workaround

DISABLE_AUTO_COMPACT=1 (env), then compact manually — works, verified against 2.1.220.