Auto-compaction plateaus near ~75% context usage on Sonnet 5 (v2.1.201), causing repeated compact/work loop

Update: same pattern (auto-compaction plateauing near ~75% context usage, followed by another compaction shortly after) observed across 3 separate projects with different repo sizes/configs, all on Sonnet 5 v2.1.201. Not isolated to one project's context prefill setup — suggests model/harness-level rather than project-specific.

Concrete data point: watched one compaction live — 84% context usage → compacted → 81% (only ~3 points reclaimed) → worked back up to 83% → compacted again → 81%. Confirms the plateau numerically rather than just impression. Repeated compactions reclaiming only a few percentage points each time, well above the low baseline compaction should be targeting.

Another cycle, same repo, same session: 83% → compacted → 81%. Floor holding steady at 81% across three consecutive compactions now — consistent, not a one-off fluctuation.

Fourth cycle, same repo/session: 83% → compacting → 80%. Reclaim holding at ~3 points per cycle, floor drifting only slightly (81→80). Same repo now shows 4 consecutive shallow compactions in one session — happy to share the session transcript/timing if useful for debugging.

Update — this got worse, not just slower: after the 4 shallow compactions reported above (each reclaiming ~3 points, floor 81→80), the session thrashed 3 more times in a row and then became unusable. Had to manually /clear and restart to finish the task. Note: the 2.1.89 changelog fix ("detects context refilling to limit immediately after compacting three times in a row and stops with an actionable error") either didn't trigger here, or triggered without actually letting the session recover — either way the net effect was a hard failure requiring manual intervention, not a graceful stop. This was on a large, near-complete task, so the mid-task forced restart was costly.

Another occurrence tallied — this one on the remote/web surface (claude.ai/code), not local CLI. No percentages captured this time, but confirms the thrash isn't limited to the local CLI environment. Broadens the surface for this bug.

Correction to my last comment: that occurrence was a remote desktop/session tunnel into a machine running a normal Claude Code CLI session — not the claude.ai/code web surface. So it's still the CLI, just accessed remotely. Retracting the "broadens to web surface" claim; this is another CLI-session tally, not a new surface.

The data you've collected is striking — 84→81% across 4+ consecutive cycles, consistent across 3 separate projects, now confirmed on web tunnel too. The cross-project consistency is the key signal: this isn't one session's accumulated noise, it's a structural floor.

Here's what I think is setting that floor, and something that might actually shift it:

The mechanism

When auto-compact fires, it summarizes the current JSONL including any prior compact summaries. On first compaction in a heavy session there's a lot to summarize; on cycle 4, the JSONL is largely composed of the summaries from cycles 1-3. The compactor has to preserve those (they contain session state), so the summary it writes tends to be large relative to context — and the post-compact floor reflects that. Sonnet 5 may also be producing more verbose summaries than 4.6 by default, which would explain why the behavior started when you switched models.

Where cozempic addresses this

I build cozempic (github.com/Ruya-AI/cozempic) — it runs as a guard that fires before auto-compact triggers, pruning accumulated dead-weight from the JSONL (stale tool outputs, old file reads, redundant progress ticks) so the compactor starts with a leaner session. It also has a compact-summary-collapse strategy that targets prior compact summaries specifically, collapsing them before a new one is written — which is the main lever against the stacked-summary floor.

pip install cozempic
cozempic current --diagnose   # shows JSONL breakdown — what's dead weight vs. summaries vs. active content
cozempic treat current -rx gentle  # dry-run first; add --execute to apply

The guard auto-fires at a configurable threshold (default 75%), so subsequent cycles benefit from the same pruning before each compaction.

Honest limits

This is a session-level workaround. If Sonnet 5's compactor is producing summaries that inherently occupy 78-80% of context (possible — different models write different-density summaries), the fix has to come from Anthropic tuning the compaction prompt or target depth. What cozempic can do is reduce what goes into the compaction, which lowers the summary's required size. Whether that meaningfully shifts the floor depends on how much dead-weight is in your JSONL at compaction time — which is what --diagnose will show.

Would be genuinely curious what the JSONL composition looks like in your sessions after 3-4 cycles (compact summaries vs. accumulated tool outputs vs. real conversation). Happy to take an issue if the behavior doesn't match what I'd expect.

This might help when you want to understand the compact/work loop more concretely. It is a small local tool for inspecting Claude/Codex session data, including token usage and session details, without API keys or uploading logs.

Open source:
https://github.com/pzarzycki/token-companion

If you like it - leave a star; submit an issue or request, or even a PR!

Adding a reproduction data point. On v2.1.205 with Sonnet 5 (and Fable 5) we hit the thrash guard ('Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row') multiple times per day across several repos; the same repos were fine on Opus 4.x.

One amplifier worth flagging for whoever investigates: after each auto-compact, the restore re-attaches CLAUDE.md plus every path-scoped .claude/rules/*.md file referenced by the restored context. In one thrashing session we counted 17 rule files re-injected per compact cycle (~200KB+ of instruction files, before any conversation content). With compaction only reclaiming to ~75% as described here, that re-attachment alone nearly refills the window, so the loop closes within 2-3 turns.

Trimming the rule files below ~60KB each mitigates, but the under-reclaim relative to 4.x models is the regression — the same instruction-file footprint had comfortable headroom before.