What is Claude Code's auto-compact threshold, and can you change it?

The short answer: there is no documented fixed percentage. Claude Code triggers auto-compact when the conversation reaches the context window minus a roughly fixed token reserve, and that reserve is what's actually constant. Source-level analyses put it around 33,000 tokens on recent versions: about 20,000 reserved so the model has room to write the compaction summary, plus a safety buffer of about 13,000 for whatever the current turn still produces. Subtract that from the window and you get the trigger:

Model window	Reserve	Auto-compact triggers near
200,000 tokens	~33,000	~167,000 tokens (~83%)
1,000,000 tokens	~33,000	~967,000 tokens (~97%)

That token-not-percentage detail explains most of the confusion around this question, so it's worth keeping front and center: the threshold is a percentage outcome, not a percentage setting, and it lands in a different place on every window size.

Why every source cites a different number

Search this topic and you'll find 77%, 78%, 80%, 83.5%, and 95% all asserted with confidence. Three reasons, all real:

1. The reserve has changed between versions. Earlier Claude Code releases reserved roughly 45,000 tokens (22.5% of a 200K window); as of early 2026 it's about 33,000 (16.5%). Every article froze whatever was true when it was written.
2. The window size changes the percentage. An author on a 200K model measures ~83%; someone on a 1M-context model measures ~97%. Both are reporting the same reserve.
3. Bugs and measurement gaps. The used_percentage figure Claude Code reports to status lines counts input-side message tokens and under-reports overhead (system prompt, CLAUDE.md, tool definitions), so the number you watch and the number the compactor acts on aren't identical, and there are open issues where auto-compact fired earlier or later than the math predicts.

So when your session compacts "at 80%" one week and "at 84%" the next, nothing is wrong with your setup. The trigger is undocumented, version-dependent, and measured against a slightly different number than the one you can see.

Can you change the threshold?

Two environment variables move it. Both are undocumented, and community reports are mixed on whether every version honors them faithfully (#42394), so treat them as tuning, not contract:

• CLAUDE_AUTOCOMPACT_PCT_OVERRIDE takes 1 to 100 and replaces the derived trigger with a direct percentage. 90 compacts later (more usable context, less room for the summary); 70 compacts earlier.
• CLAUDE_CODE_AUTO_COMPACT_WINDOW takes an absolute token count and replaces the window the reserve is subtracted from, useful on 1M-context models when you want compaction long before the real wall.

Set either in the env block of ~/.claude/settings.json so every session gets it (with the claude role, that's three lines of claude_code_settings):

{
  "env": {
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "90"
  }
}

What does not work: autoCompact or autoCompactEnabled keys in settings.json are silently ignored, and a native, supported setting for the threshold remains an open feature request.

Can you disable auto-compact?

Not reliably. DISABLE_AUTO_COMPACT=1 circulates and works for some setups, but users report compaction firing anyway, and even where it holds you've traded a controlled failure for an uncontrolled one: the session that never compacts eventually just hits the wall. The productive framing isn't disabling the mechanism, it's beating it to the punch: run /compact yourself at a natural boundary (a finished task, a passing test suite) where the summary has a clean story to tell, or hand the remaining work to a fresh session. A forced auto-compact mid-task is the worst of the options, because it summarizes at an arbitrary point where the nuance it drops is exactly the nuance you were using.

How to see it coming

Claude Code doesn't expose the trigger to status lines: the JSON payload has context_window.used_percentage and context_window_size, but no auto-compact field (the request to add one was closed as a duplicate). You can derive it, though, and a status line is the right place, since it's the one component that receives live context numbers on every refresh:

trigger_pct = (context_window_size - reserve) / context_window_size * 100
headroom    = trigger_pct - used_percentage

with reserve ≈ 33000, honoring the two env vars above when set. The status line the claude role ships implements exactly this: within 20 window points of the derived trigger, the session section grows a ♻️ countdown to the compaction point:

 78%  ███░ 78% ♻️ 5%
 83%  ███░ 83% ♻️ 0%

Because the trigger is derived from the actual context_window_size, the same marker is honest on every model: at 90% context a 200K session is already past the point, while a 1M session still has ~70,000 tokens of headroom and stays quiet. The reserve and the warning lead are both tunables (claude_code_statusline_compact_reserve, claude_code_statusline_compact_lead), so when a future Claude Code release moves the reserve again, the marker moves with one variable instead of a rewrite.

The one-paragraph version

Claude Code auto-compacts at the context window minus a ~33K-token reserve: about 83% of a 200K window, about 97% of a 1M one, undocumented and shifted across versions, which is why every blog quotes a different percentage. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE and CLAUDE_CODE_AUTO_COMPACT_WINDOW move it (unofficially); nothing reliably disables it; and the practical move is a status line that derives the trigger and counts down to it, so you /compact on your terms before Claude Code does it on its own.