Auto-compact should trigger earlier / threshold should be configurable

[royleon55]

Problem

When autoCompact is enabled, the auto-compact trigger threshold is too close to the hard context window limit. This creates a failure scenario where:

1. Context grows rapidly (e.g., large file reads, verbose tool outputs) and overshoots past the auto-compact threshold straight to the hard limit
2. Claude stops working and advises running /compact manually
3. Manual /compact then fails with "conversation is too long" — because the conversation is so large that even the compaction request can't fit in the context window
4. The only option left is /clear, which destroys all conversation context

This is a catch-22: auto-compact didn't trigger when it should have, and manual compact can't rescue the situation.

Proposed Solution

• Make the auto-compact threshold configurable — allow users to set a percentage (e.g., trigger at 80% or 85% of the context limit instead of the current default)
• Trigger auto-compact earlier by default — even a 5% earlier threshold would provide enough buffer to avoid the failure scenario described above
• Ensure /compact always works — if the conversation is too long to compact normally, consider a more aggressive fallback (e.g., truncating older messages before compacting)

Example config:

{
  "autoCompact": true,
  "autoCompactThreshold": 0.85
}

Impact

This is a significant UX issue. Losing an entire long session's context because auto-compact failed silently and manual compact can't recover is extremely frustrating — especially during complex multi-file tasks where rebuilding context is costly.

Environment

• Claude Code CLI
• autoCompact: true in settings
• Model: Claude Opus
• Platform: macOS

[github-actions]

Found 3 possible duplicate issues:

1. [Bug] Auto-Compact Failure Leaves Instance in Unrecoverable Context Limit State #24942
2. Cascading failure: auto-compaction, /compact, and rewind all fail at context limit — requires Ctrl+C to escape #26220
3. /compact fails with 'Conversation too long' when context limit is reached #23047

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

[mihnen]

This started happening to me today Claude code native install on Ubuntu 24.04 and auto compact turned on it fails to auto compact and then will not let me run the /compact command saying conversation is too long. This has happened 3 times today after updating to version 2.1.58 from 2.1.52. I never has this happen before ever.

[royleon55]

The issue appears only in my Apple Mac Claude code instances while my windows instances, though ssh acces into a vm running Ubuntu 24 Lts latest don’t have the issue. Related “duplicate” issues are not calling for a configurable context compact threshold though I see other hit the same error at lower CTX thresholds, one user reported crashing at 74%.

[mihnen]

Looks like for me this has something to do with the context running low when the terminal doesn't have focus. I am using Ghostty and if the context runs low and it needs to auto compact but I am working in another window it will fail.

[MishaPT]

Adding a +1 and a specific use case that I think sharpens the "natural break" framing:

The most impactful version of this feature, from a UX perspective, is compaction triggered immediately after Claude finishes delivering a response — not before the next user message, not mid-tool-chain, but in the ~5–30 seconds while the user is reading the response they just received.

Why the timing matters as much as the threshold:

The current experience in long sessions:

User sends message
Claude starts responding
Context limit hit → compaction interrupts → user waits
User gets response, already frustrated
The desired experience:

User sends message → Claude responds fully
[background: context at 80% → compaction runs while user reads]
User types next message → context is already clean, no wait
The user is always reading after a response. That's the only moment in the conversation where they're guaranteed to not be waiting on Claude. Using that window for compaction is zero-cost from a perceived latency standpoint.

Proposed settings.json:

{
"autoCompactThreshold": 0.80,
"autoCompactTiming": "after-response"
}
after-response would mean: once the final token of a response is delivered, if context usage exceeds autoCompactThreshold, begin compaction in the background. Queue the next user message until compaction completes (which by then may already be done).

This pairs naturally with the "Compact at next natural break" mode described in the original issue — I'd just argue the break should be after delivery, not before the next prompt.

[dsent]

I personally would really like to compact much earlier, especially with the new 1M limit of Opus. Large context leads to poor focus and deviating from instructions more. +1 to making this configurable.

Also, @MishaPT's suggestion is brilliant.