Configurable auto-compaction threshold

[cforce]

Problem

Auto-compaction currently triggers only when the context window is nearly 100% full. In practice, this means the UI appears frozen (progress bar at max, no visible action) while Claude Code decides whether to compact. Users end up running /compact manually as a workaround.

Proposed Solution

Add a configurable threshold (e.g., 90%) at which auto-compaction triggers. Something like:

// settings.json
{
  "compactThreshold": 0.9
}

When context usage crosses this threshold, Claude Code would automatically compact — identical behavior to today's auto-compact, just triggered earlier.

Why This Matters

• Background agents inflate context silently. Pipeline monitors, research agents, etc. return results that accumulate. By the time the user notices the bar at 100%, the experience has already degraded.
• Proactive compaction is smoother. Compacting at 90% with headroom preserves a working buffer, rather than hitting the wall and scrambling.
• Hooks can't solve this. PreCompact/PostCompact hooks exist but fire only when compaction is already happening. There's no hook event for "context reaching X%", no tool to read current usage, and no programmatic way to trigger /compact.

Alternatives Considered

• Behavioral guidance in skills/hooks: We tried adding "suggest compaction after major ops" to skills, but this is unreliable (the agent itself consumes context to suggest it).
• Manual /compact: Works but requires user vigilance — defeats the purpose of autonomous operation.

Environment

• Claude Code CLI (latest)
• Heavy use of background agents (pipeline monitors, research agents)
• Long-running sessions with multiple tool-heavy operations

[github-actions]

Found 3 possible duplicate issues:

1. [Feature Request] Add configurable auto-compaction threshold setting #66019
2. Feature request: configurable auto-compact token threshold via settings.json #70431
3. Feature Request: Configurable auto-compact threshold #70681

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[junaidtitan]

Your three failure modes are exactly right — and the hooks insight is the sharpest part: PreCompact/PostCompact fire after the decision has been made, so there's no way to inject a "trigger compaction now" signal into the threshold logic from user code.

One workaround that fits your specific pattern: a guard daemon that monitors the JSONL file rather than hooking into CC's trigger. cozempic does this — it watches your session file's token count independently of CC's internal threshold logic. You configure a target (say 60%) and it prunes at session exit, stripping tool-result payloads, file-read accumulations, completed subagent transcripts — the categories pipeline agents produce most. On the next session start the context loads lean, so you're much less likely to hit 100% before the first substantive turn.

The mechanism is different from what you're asking for: guard prunes the JSONL directly rather than triggering CC's /compact summarizer. So it's complementary, not a substitute — the summary still generates when CC decides to compact, but it has denser material to work with (fewer verbatim tool-results diluting it) when guard has already stripped the dead weight.

What it doesn't solve: there's still no hook event for "context reached X%" that can fire your own code mid-session. That gap genuinely needs a native CC feature — agree it should be in the product. But for the "pipeline agents silently fill the window" pattern, JSONL-level pruning between sessions has been effective in practice.

pip install cozempic or pipx install cozempic (zero external deps). cozempic doctor first to see the state of your session files before touching anything.