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

Version: 2.1.201
Model: Claude Sonnet 5

Description

After switching a project's executor-default model from Sonnet 4.6 to Sonnet 5, I've noticed context fills noticeably faster during a session, and when auto-compaction triggers, context usage does not drop much below ~75% afterward. This produces a tight work → compact → work → compact loop instead of the long clean runway compaction normally gives after firing.

This is a single day of anecdotal observation on one project, not yet a minimal repro — filing in case others are seeing the same pattern, or in case this is already a known/tracked issue.

Checked changelog first

Searched CHANGELOG.md (335 entries) for related terms (compaction, compact, context window, auto-compact, memory pressure, thrash loop). Found no matching entry. 2.1.201 is currently the top-of-changelog entry (unrelated note about Sonnet 5 harness reminders). The closest related entry is 2.1.89 ("Fixed autocompact thrash loop — detects context refilling to the limit immediately after compacting three times in a row and stops with an actionable error") — but that's a circuit-breaker for repeated full-refill compactions, not this under-reclaim/plateau-at-75% symptom, and it predates 2.1.201.

Expected behavior

Compaction should reclaim context down to a low baseline (well below 75%), giving a long runway before the next compaction is needed.

Actual behavior

Context usage plateaus near ~75% post-compaction, triggering compaction again after comparatively little additional work.

Question

Is this a known issue? Is compaction depth/target percentage expected to differ when the active model is Sonnet 5 vs Sonnet 4.6, or is this a bug in how compaction calculates how much to reclaim?