[FEATURE] Configurable autocompaction threshold

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Autocompaction is currently all-or-nothing: autoCompactEnabled / DISABLE_AUTO_COMPACT let me turn it on or off, but I can't control when it fires. It triggers on a fixed "context approaching the limit"
heuristic that I can't see or tune.

This causes two opposite problems depending on the workflow:

1. Compaction fires too early. On long, context-heavy tasks (large codebases, multi-file refactors,

deep investigations) I'd rather use more of the window before summarizing, because every compaction loses
fidelity that matters for the task.

1. Disabling it is too blunt. If I turn autocompaction off to avoid surprise mid-task summarization, I

lose the safety net entirely and risk hard-hitting the context limit. There's no middle ground.

My only real lever today is to disable it and manually run /compact at breakpoints, which requires me to
constantly watch context usage instead of focusing on the work.

Proposed Solution

Add a configurable threshold controlling when autocompaction triggers, alongside the existing on/off
switch. For example a settings.json key:

{
"autoCompactEnabled": true,
"autoCompactThreshold": 0.85 // compact at 85% of the context window
}

Accept either a fraction/percentage of the context window or an absolute token count. Behavior:

• Default preserves today's behavior (no change for users who don't set it).
• Setting a higher value (e.g. 0.90) lets me use more of the window before compacting.
• Setting a lower value compacts earlier for users who prefer smaller, cheaper context.

Pair it with an env var for parity with the existing controls (e.g. CLAUDE_CODE_AUTO_COMPACT_THRESHOLD),
and surface it in /config next to the existing Auto-compact toggle.

Alternative Solutions

• Disabling autocompaction (autoCompactEnabled: false / DISABLE_AUTO_COMPACT) and manually running

/compact at natural breakpoints. Works, but requires constantly monitoring context usage and removes the
safety net against hitting the hard limit.

• Using /clear between tasks to keep context small — loses all continuity, so not viable mid-task.
• Neither gives a tunable trigger point; both are blunt on/off behaviors.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. I start a large multi-file refactor in a big codebase. I want as much context retained as possible

before any summarization, so I set "autoCompactThreshold": 0.92 in settings.json.

1. Claude works through ~25 files, accumulating context. Today, autocompaction would fire well before 92%

and I'd lose detail from files reviewed early in the session.

1. With the threshold set, compaction holds off until 92% of the window is used, keeping more of the

relevant code and decisions in context for the bulk of the task.

1. When it finally compacts, I've gotten maximum useful work out of the window — and I never had to babysit

the context meter or risk hitting the hard limit by disabling compaction entirely.

Additional Context

• Existing controls for reference: the autoCompactEnabled setting (default true, /config "Auto-compact"

toggle) and the DISABLE_AUTO_COMPACT env var only expose on/off, not a threshold.

• Prior art: many tools that summarize/trim context expose a configurable trigger point (token budget or %

of window) rather than a fixed internal heuristic.

• A read-only way to see the current trigger point and current context usage would complement this nicely.