How many context compactions does a coding session undergo?
A compaction is the behavioral event the paper distinguishes from the plain size buckets in
total_input_growth: when the running context nears its limit it is
summarized/dropped to a short history and then slowly re-accumulates. We detect it structurally
from the per-step total input length (prefix_tokens + newly_append_tokens), ordered by
round_pk within each session. A step i is a compaction when all three hold:
- Great reduction —
total[i-1] - total[i] >= 64k(--min-drop-tokens, defaults togrowth.MAJOR_REDUCTION_MIN_TOKENS). Every compaction is therefore also a major reduction; compactions are the strict subset that also satisfy (2) and (3). - Near the context limit — the pre-drop level
total[i-1]is at least--near-max-ratio(0.75) of the session’s observed max total input. The drop happens near the session’s peak, not at a small early dip. - Recovers slowly — the context does not rebound to
--rebound-ratio(0.75) of the pre-drop level within the next--rebound-steps(3) steps, and at least one step follows. A drop that immediately snaps back is a branch/edit artifact, not a compaction.
Each compaction is attributed to the trigger of step i, using the same
user-initiated / tool-initiated split the rest of the paper uses: user_message →
user-initiated (an explicit /compact or a new request that forced summarization);
tool_result → tool-initiated (auto-compaction mid-loop).