[Bug] Auto-compact triggers prematurely with extended context models

Environment:

• Model: claude-opus-4-7[1m] (1M extended context beta)
• Client: Claude Code v2.1.112
• Platform: Windows 10, bash (MSYS)
• No custom autoCompact settings in settings.json / settings.local.json

Bug: The UI context-usage percentage is inaccurate and under-reports actual token usage by roughly 2× at intermediate loads. Auto-compact triggers based on real server-side token count (which is correct), but the indicator the user sees does not track it — so compaction fires while the UI still shows plenty of headroom.

Evidence from one session transcript (3 compact events, same session id):

• Compact #1: UI read 147%, actual peak cache_read_input_tokens = 1,465,572 → UI ≈ accurate only at extreme overflow.
• Compact #2: UI read 60%, actual peak cache_read_input_tokens = 1,244,198 (124% of 1M window) → UI under-reported by factor of ~2.

(Numbers pulled directly from ~/.claude/projects/<proj>/<sessionId>.jsonl, filtering cache_read_input_tokens per assistant turn.)

Expected: UI percentage should reflect the same total that drives auto-compact (input + cache_read + cache_creation).

Observed: UI percentage appears to normalize against the 200k base window, or under-count tool results / cached content. Result: user sees "60%" and experiences surprise compaction mid-task.

Impact:

• Unexpected context loss during long analysis sessions.
• User cannot preemptively /compact because the indicator looks safe.
• Workaround required: disable auto-compact entirely (which I just did).

Suggested fix: UI percentage for [1m] context variants should use the same token accounting as the compact trigger. Either denominator = 1M (matching the advertised window) or display raw token count so the user can judge.

Repro: Run a heavy read-and-analyze workload on claude-opus-4-7[1m] (~20+ file reads, ~5+ advisor/subagent calls, several hundred-line writes). Compare UI % at trigger vs cache_read_input_tokens in the transcript jsonl.