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: the threshold is a percentage outcome, not a percentage setting, and it lands in a different place on every window size.

Every number and mechanism below is read out of Claude Code 2.1.222. Two of the things this post said in July have since changed in the product, and they're marked where they appear.

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. Window size moves 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. Then there are 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?

There's a command for it now:

/autocompact 500k

/autocompact auto puts it back. The value is a window, not a threshold, so the reserve still comes off the top: 500k on a 1M model compacts near 467,000 tokens, not 500,000. It takes auto or 100k to 1M, and the parser's own error message lists the forms it accepts, "e.g. 500k, 200000, or 200 as shorthand".

The command writes autoCompactWindow into ~/.claude/settings.json, so it survives restarts and you can ship it with your dotfiles instead of typing it per machine (with the claude role, one line of claude_code_settings):

{
  "autoCompactWindow": 500000
}

Two undocumented environment variables move the same trigger, and community reports are mixed on whether every version honors them faithfully (#42394), so treat those two as tuning, not contract:

• CLAUDE_CODE_AUTO_COMPACT_WINDOW is the env-side twin of the setting, and outranks it.
• CLAUDE_AUTOCOMPACT_PCT_OVERRIDE takes 1 to 100 and caps the trigger at that percentage of the window minus the 20,000-token summary reservation. Since it's a cap, it only ever compacts earlier: 70 on a 200K window moves the trigger from ~167,000 tokens down to 126,000, while anything above ~93% changes nothing. (This post originally said 90 compacts later. It doesn't. 2.1.222 takes the lower of the override and the reserve point, so the knob has one direction.)

Resolution order, highest first: the env var, the autoCompactWindow setting, a window pushed down server-side, then the model's own context window. Whatever wins is capped at the model's window, so a configured window can only narrow the session, never stretch it.

Can you disable auto-compact?

Yes. /config has an Auto-compact toggle, and turning it off writes autoCompactEnabled: false to ~/.claude/settings.json, which is the key that used to be ignored when this post went out. DISABLE_AUTO_COMPACT=1 does the same job from the environment, and 2.1.222 reads both before anything else in the trigger math. The request for a supported threshold setting was closed as a duplicate in June, and /autocompact reaches the changelog only in passing, in a 2.1.234 note about which dialogs open mid-turn. The feature shipped; the announcement didn't.

Whether you want it off is the other question. With auto-compact disabled the session doesn't get a summary, it gets a wall: Claude Code still blocks the turn a few thousand tokens under the model's usable window, so you've traded a controlled failure for an uncontrolled one. 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.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:

window      = CLAUDE_CODE_AUTO_COMPACT_WINDOW, else the autoCompactWindow
              setting, else context_window_size (and never above it)
trigger_pct = (window - reserve) / context_window_size * 100
headroom    = trigger_pct - used_percentage

with reserve ≈ 33000. Watch the denominator: used_percentage is always measured against the model's full window, which no override touches, so a narrowed window has to be converted back into a percentage of the bar the reader is looking at. Divide by the narrowed window instead and a 500K window on a 1M model reads as 93% when the session will actually compact at 46%.

The status line the claude role ships does this, settings file included: 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 real window rather than fixed at a percentage, the same marker holds 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. /autocompact <tokens> narrows the window it measures against and the /config toggle turns the whole thing off, with CLAUDE_CODE_AUTO_COMPACT_WINDOW and CLAUDE_AUTOCOMPACT_PCT_OVERRIDE outranking both; the trigger stays derived rather than declared, so the practical move is a status line that derives it too and counts down, letting you /compact on your terms before Claude Code does it on its own.