[BUG] Turning auto-compact OFF won't allow to continue until you fill the 200K tokens window anymore (it worked before).

Exactly! This thing showed up yesterday and was working fine before! It now doesn't allow to continue on 170+k!

<img width="715" height="433" alt="Image" src="https://github.com/user-attachments/assets/71b6567b-bbfb-48e4-ba99-b0884bdbac64" />

(Note: The following was entirely prepared by Claude Code, and my input was minimal. Please take it with a grain of extra salt. It took me a few sessions to somehow replicate the problems and let Claude Code inspect the logs though.)

(Note 2: I saw this ("Fixed context window blocking limit being calculated using the full context window instead of the effective context window (which reserves space for max output tokens") in the latest change of 2.1.7 and had Claude Code dig deeper and thus got these.)

Possible Root Cause: v2.1.7 Blocking Limit Change

After experiencing premature "Prompt is too long" errors, a source code diff between v2.1.6 and v2.1.7 revealed a change in how the blocking limit is calculated that may explain the reduced effective context window.

### Problem

Sessions appear to hit "Prompt is too long" at ~130K tokens instead of ~197K tokens. The client-side blocking limit validation seems to reject prompts before they reach the API, even when there may be context remaining.

### Source Location

The blocking limit logic is in the bundled CLI:

node_modules/@anthropic-ai/claude-code/cli.js

Since it's minified, search for isAtBlockingLimit: to find the relevant function.

### Key Functions and Constants

v2.1.6:

| Name | Type | Description |
| ---- | ---- | ----------- |
| kp(A) | function | Calculates context thresholds, returns {isAtBlockingLimit, ...} |
| p$(W, _w()) | function | Returns raw context window size (200K or 1M) |
| x8() | function | Returns current model name |
| pR0 | constant | Buffer before blocking, value: 3000 |

v2.1.7:

| Name | Type | Description |
| ---- | ---- | ----------- |
| ic(A) | function | Calculates context thresholds, returns {isAtBlockingLimit, ...} |
| q3A() | function | Returns effective context: contextWindow - maxOutputTokens |
| Jq(A, SM()) | function | Returns raw context window size (200K or 1M) |
| dL0(A) | function | Returns max output tokens for model (64K for Opus 4.5) |
| mL0 | constant | Buffer before blocking, value: 3000 |

### The Change

v2.1.6 (function kp near byte offset 9,913,000):

```javascript
function kp(A){
// ...
W=x8(), // get model name
K=p$(W,_w())-pR0, // BLOCKING = contextWindow - 3000
V=process.env.CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE,
F=V?parseInt(V,10):NaN,
H=!isNaN(F)&&F>0?F:K, // use override if set, else K
E=A>=H; // isAtBlockingLimit
return{...isAtBlockingLimit:E}
}

  **v2.1.7** (function ic near byte offset 9,384,000):

```javascript
  function ic(A){
    // ...
    D=q3A()-mL0,                         // BLOCKING = effectiveContext - 3000
    W=process.env.CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE,
    K=W?parseInt(W,10):NaN,
    V=!isNaN(K)&&K>0?K:D,                // use override if set, else D
    F=A>=V;                              // isAtBlockingLimit
    return{...isAtBlockingLimit:F}
  }

v2.1.7 q3A() definition:

  function q3A(){
    let A=B5(),           // model name
        Q=dL0(A);         // maxOutputTokens (64000 for opus-4-5)
    return Jq(A,SM())-Q   // contextWindow - maxOutputTokens
  }

Observed Impact

The blocking limit formula appears to have changed from using raw contextWindow to using q3A() (effective context), which already subtracts maxOutputTokens:

| Version | Formula | Opus 4.5 Blocking Limit |
| ------- | ------- | ----------------------- |
| v2.1.6 | contextWindow - 3000 | ~197,000 |
| v2.1.7 | (contextWindow - maxOutputTokens) - 3000 | ~133,000 |

This appears to result in ~64K fewer usable tokens for Opus 4.5 and Sonnet 4 (which both have 64K max output).

Workaround

Both versions check for CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE before using the calculated value:

  // v2.1.7:
  W=process.env.CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE,
  K=W?parseInt(W,10):NaN,
  V=!isNaN(K)&&K>0?K:D,   // use override K if valid, otherwise use calculated D
  F=A>=V;                  // isAtBlockingLimit

Setting this env var and restarting Claude Code may restore v2.1.6 behavior:

  export CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE=197000
  claude  # restart for it to take effect

+1 - This is blocking upgrades past 2.1.6 for users who rely on manual context management.

Use case: When autoCompact is disabled, users expect full control over when compaction happens. The v2.1.7 change forces early blocking at ~65-80% regardless of this setting, which defeats the purpose of disabling auto-compact.

Suggested fix: Only apply the output token reservation when autoCompact is enabled. Users who disable it have explicitly opted into manual management and accept the risk of hitting the true limit.

Thanks for the workaround CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE=197000 - using that for now, but would prefer a proper fix or setting.

Still reproducing on v2.1.42 with Claude Opus 4.6 — and now even worse.

Environment

• Claude Code: v2.1.42
• Model: claude-opus-4-6
• OS: macOS Darwin 24.5.0
• autoCompact: false in settings
• CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE=197000 set in environment

Observed Behavior

Auto-compaction triggers at approximately 150k tokens (~75% of 200k window), despite:

1. autoCompact: false explicitly configured
2. CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE=197000 set (the community workaround from this thread)

The /context command reports against the full 200k window, showing ~67% free space — but compaction fires anyway. This is a regression from the 160-170k limit reported in earlier comments on this issue.

Key Observation: BLOCKING_LIMIT_OVERRIDE Does Not Prevent Auto-Compaction

The CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE env var appears to only control the blocking limit (when CC refuses to send new prompts), not the auto-compaction trigger threshold. These appear to be separate code paths. Even with the override set to 197000, auto-compaction fires at ~150k.

This means the community workaround only partially addresses the issue — it prevents premature blocking but not premature compaction.

Impact

For complex codebases with large CLAUDE.md files and hook infrastructure, the effective usable context is approximately 80-85k tokens of actual conversation (after ~65k of system prompt, tools, and memory files). Auto-compacting at 150k total means we get roughly half the expected working context before catastrophic 93% context loss.

This makes sustained work on complex projects extremely difficult — context compaction destroys working state every 15-20 tool calls, requiring expensive recovery protocols.

Request

1. Fix the auto-compaction trigger to respect autoCompact: false
2. Ensure CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE (or a new env var) controls the compaction threshold too
3. For Opus 4.6 with 128k maxOutputTokens, the formula (contextWindow - maxOutputTokens) - 3000 yields only ~69k effective context — this is catastrophically low

Previously filed as #24856 (auto-duped to this issue).

Using CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE for a while seemed to help. Today, in two separate terminals, I have 2.1.51 and 2.1.56 returning  Context limit reached · /compact or /clear to continue at around 175k token usage.

I have auto compact turned off in the /config as I want to manage this myself.

Please do let me know if I can assist by providing any information to help debug this issue.

agree same issue, I too am back to context limit reached at 179k... quite annoying

I just hit this again today. Including the buffer, I am at 90% used. I usually run to the full 98%. The statusline count says 177413.

/context shows plenty of free space

  ⎿  Context Usage
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛁ ⛁ ⛀ ⛁   claude-opus-4-5 · 177k/200k tokens (88%)
     ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   Estimated usage by category
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System prompt: 3.7k tokens (1.9%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System tools: 7.2k tokens (3.6%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ MCP tools: 3.7k tokens (1.9%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Custom agents: 46 tokens (0.0%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Memory files: 1.5k tokens (0.7%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Skills: 519 tokens (0.3%)
     ⛁ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀   ⛁ Messages: 161.2k tokens (80.6%)
                           ⛁ Compact buffer: 3k tokens (1.5%)
                           ⛶ Free space: 19k (9.6%)

... (removed)

      Suggestions
      ⚠ Context is 88% full
        Autocompact is disabled. Use /compact to free space, or enable autocompact in
         /config.

      ℹ Read results using 50k tokens (25%) → save ~15k
        Use offset and limit parameters to read only the sections you need. Avoid
        re-reading entire files when you only need a few lines.

Even more interesting is that after an exit and resume it seems to have auto-compacted some file reads in the background and recovered a huge chunk of context space, but I still can't continue. At this point, the top line 88% free is overstated. This is interesting but not 100% relevant because even before this I should have been allowed to continue.

  ⎿  Context Usage
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛁ ⛁ ⛀ ⛁   claude-opus-4-5 · 177k/200k tokens (88%)
     ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   Estimated usage by category
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System prompt: 3.9k tokens (1.9%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System tools: 7.2k tokens (3.6%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ MCP tools: 3.7k tokens (1.9%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Custom agents: 46 tokens (0.0%)
     ⛁ ⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Memory files: 1.5k tokens (0.7%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Skills: 519 tokens (0.3%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀   ⛁ Messages: 124k tokens (62.0%)
                           ⛁ Compact buffer: 3k tokens (1.5%)
                           ⛶ Free space: 56k (28.1%)

... (removed)

      Suggestions
      ⚠ Context is 88% full
        Autocompact is disabled. Use /compact to free space, or enable autocompact in
         /config.

      ℹ Read results using 40.4k tokens (20%) → save ~12.1k
        Use offset and limit parameters to read only the sections you need. Avoid
        re-reading entire files when you only need a few lines.

You may have noticed I use opus 4.5. I have access to opus 4.6 with 1m token window, but it is inferior and I prefer opus 4.5 with a 198k context window. I do really need that last 20k though.

I'm hitting this as well. Super frustrating as it stopped in the middle of outputting a bunch of code changes when clearly there was enough space to do so.

  ⎿  Context limit reached · /compact or /clear to continue · /model opus[1m]

✻ Cooked for 1m 46s

❯ /context
  ⎿  Context Usage
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛁   claude-opus-4-6 · 175k/200k tokens (88%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   Estimated usage by category
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System prompt: 6.3k tokens (3.1%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ System tools: 10.4k tokens (5.2%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Skills: 410 tokens (0.2%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Messages: 160.4k tokens (80.2%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁   ⛁ Compact buffer: 3k tokens (1.5%)
     ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛶   ⛶ Free space: 20k (9.8%)
     ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ ⛀

     Skills · /skills

      Suggestions
      ⚠ Context is 88% full
        Autocompact is disabled. Use /compact to free space, or enable autocompact in
         /config.

PS. I have no idea why it reports my model as opus[1m]. I'm using the normal opus.

Confirmed still occurring on 2.1.84:

<img width="1075" height="407" alt="Image" src="https://github.com/user-attachments/assets/47d4ca77-91f0-495d-b373-19779cf81d17" />

Please can we get a dev to acknowledge this issue? I know you're vibecoding every new update now but this has been occurring for months and means we're literally not getting the full context we're paying for.

I commented on another thread how to troubleshoot it, if you implemented CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE, there's nothing Anthropic can do about it. It is your custom settings that is forcing the problem and not letting you access the 1m. You need to remove it on your machine, and it will work.
https://github.com/anthropics/claude-code/issues/34958#issuecomment-4071028919

If you are on the Max plan, your Opus 4.6 has 1m context by default. And it will not render if you have that blocking limit in place.

1. But using opusplan, it still uses the old context limit models.
2. Context limit not repsecting autocompact off is a bug itself (regression). It seems like a nobrainer bug, why don't you guys fix it?

reproducable easily in 2.1.117
I have this all the time with Max plan and Sonnet
this usually happens when there is 11/12/13% context remaining until the 200k

pretty odd since we can no longer use Opus 4.6 or just be able to use Sonnet 4.6 1M :/
Sonnet 4.6 is in many situations useless or hard to work with in many workflows

Does anyone else with this issue use a custom system prompt or disable built-in tools like I do? I was just wondering if the difference is actually the difference between the standard system prompt and tool schemas and what I actually have, which could be the 30k tokens difference.

For folks who turn auto-compact off specifically to avoid losing context, an offline prune is a good middle path: it reclaims space by stubbing old tool results and dropping superseded file reads, without the summarization that compaction does. We built cozempic for this — cozempic treat <session-id> --execute (install via uvx cozempic) shrinks the transcript so you can resume with real headroom (it writes a backup first), and a guard daemon can auto-prune at thresholds you set instead of relying on CC's compaction trigger. Doesn't fix the regression in the blocking-limit calc, but it unblocks the session.

Hitting this as well lately. Very frustrating to disable auto compact and get none of the pros but all of the cons. Something is not working correctly here