Auto-compaction fired mid-task on a 1M-context (Opus 4.8) session at ~50% reported context utilization

Summary

A Claude Code session running on claude-opus-4-8[1m] (Opus 4.8, 1M-token context) was automatically compacted ("This session is being continued from a previous conversation that ran out of context") in the middle of an active, multi-step task. Per the in-app context indicator, the user was at no more than ~50% utilization — nowhere near the 1M limit — which makes ordinary context-exhaustion an unlikely explanation. The compaction broke session continuity and cost the user their working session.

Environment

• Claude Code (CLI) on Windows 11
• Model: claude-opus-4-8[1m] (Opus 4.8, 1M context)
• Long-running agentic session (multi-pass build workflow)

What happened

1. A long agentic session running a visual QA task that loaded ~20+ images (screenshots, extracted video frames, montages).
2. As images accumulated, repeated image-processing failures appeared:

• An image couldn't be read. Rewind to remove it and try a different format.
• API Error: an image in the conversation could not be processed and was removed. Re-read the file with a different approach if you still need it.
• The effective per-image size limit appeared to shrink as more images were added.

1. Shortly after, the session was auto-compacted and continued in a fresh context window — at a reported ~50% context utilization, with no advance warning.

Expected

On a 1M-context model, an actively-working user at ~50% utilization should not hit auto-compaction — and certainly not without warning.

Impact

• Loss of the active working session's context; the user discarded the session and restarted.
• (Committed code was unaffected — it lives in git, separate from the conversation — but the in-flight working state and trust in session continuity were lost.)

Hypotheses (unverified — for triage)

The user reports being at ~50% context, so simple context-exhaustion seems unlikely. Candidate causes:

• Premature auto-compact trigger — compaction firing far below the 1M ceiling.
• Context-accounting / display mismatch — if true utilization was higher than the ~50% the indicator displayed (e.g., image tokens not fully counted), the indicator is under-reporting, which is itself a bug.
• Interaction with the image-processing error cascade — the "…image could not be processed and was removed…" errors immediately preceded the compaction and may be related.

Suggested fixes

• Warn before auto-compacting an active session; let the user checkpoint/confirm first.
• Verify the auto-compact threshold scales to the full 1M window on 1M-context models.
• Ensure the context indicator accurately reflects true utilization, including image tokens.
• Investigate the progressive image-rejection failures in long image-heavy sessions.

_Related: #36068, #23419_