Repository navigation
bug: prune thresholds are too aggressive for 1M+ context models #21208
Description
Description
The prune function in SessionCompaction uses hardcoded thresholds (PRUNE_PROTECT = 40_000 and PRUNE_MINIMUM = 20_000 tokens) to decide when to clear old tool call outputs.
These values were reasonable when most models had 200K context (40K = 20%), but with Claude Opus 4.6, GPT-5.4, and Gemini 2.5 Pro all at 1M+ context, 40K is only 4%. Tool results from just a few turns ago get pruned even though context usage is well under the limit.
Steps to reproduce
- Use a 1M context model (Claude Opus, GPT-5.4, etc.)
- Have a multi-turn conversation with tool calls (reading/editing files)
- After several turns, observe that tool outputs from earlier turns are pruned prematurely
- The model loses access to recent work results
Expected behavior
Prune thresholds should scale with model context size so that larger-context models retain more tool output history.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 6, 2026
This issue might be a duplicate of existing issues. Please check:
okuyam2y commentedon Apr 6, 2026
Related but different from #15871. That issue is about the compaction trigger threshold (when to start compacting), while this one is about the prune thresholds (how much tool output to protect from clearing). Both stem from hardcoded values that don't scale to 1M contexts, but they affect different code paths —
overflow.tsvscompaction.ts:prune().PR #21209 addresses only the prune side.
okuyam2y commentedon Apr 6, 2026
Also related to #16308 (1M context but compaction/prune triggers at ~272K) — the hardcoded prune thresholds are part of that problem. #11930 requests making thresholds configurable; this PR takes the simpler approach of auto-scaling to context size.
github-actions commentedon Jul 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.