## Description Auto-compact fired when the context bar showed only **16% used** (84% of the context window still available). Compaction should not trigger anywhere near that low. ## Environment - Claude Code on macOS (Darwin 25.3.0) - Model: claude-opus-4-7 ## Impact Lost mid-task context unexpectedly during a long working session. Bar showed plenty of headroom; compaction was a complete surprise. ## Repro Not yet isolated — happened during a vault-editing session with several large file Read

Auto-compact firing at ~16% context used

Status Fixed / completed

Maintainer reply None cached

Activity 3 comments · opened Apr 27, 2026 · closed Apr 27, 2026

Description

Auto-compact fired when the context bar showed only 16% used (84% of the context window still available). Compaction should not trigger anywhere near that low.

Environment

Claude Code on macOS (Darwin 25.3.0)
Model: claude-opus-4-7

Impact

Lost mid-task context unexpectedly during a long working session. Bar showed plenty of headroom; compaction was a complete surprise.

Repro

Not yet isolated — happened during a vault-editing session with several large file Reads (one Excalidraw .md was flagged as "too large to include" in a prior turn). The bar reported 16% used at the time compaction fired.

View original on GitHub ↗

3 Comments

0xbrainkid · 5 months ago

If auto-compact is really firing around ~16% context used, that is not just an efficiency bug — it changes the product’s trust model.

Users are planning work against an implied budget. When compaction arrives an order of magnitude earlier than expected, they do not just lose space, they lose the ability to reason about when continuity risk begins.

That is especially bad because compaction is not a neutral event. Even when it works “correctly,” it can change which details remain salient and which disappear. So premature compaction means users are pushed into summary/handoff mode far earlier than the interface suggests.

I would want three things here:

confirm whether the trigger is truly early or whether the visible percentage is misreported
surface the actual compaction threshold in the UI/session state
if early compaction is intentional under some conditions, explain which conditions (model, tool traffic, hidden overhead, etc.)

Otherwise people will keep interpreting it as random continuity loss, because from their point of view they still had plenty of headroom left.

MelchiorLaTour · 5 months ago

Closing to refile with clearer description.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.