Skip to content

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

New issue
New issue
Open
Open
[BUG] Turning auto-compact OFF won't allow to continue until you fill the 200K tokens window anymore (it worked before).#18152
Assignees
timgu0
Labels
bugSomething isn't working

Description

@alessandroavenali
alessandroavenali
opened on Jan 14, 2026

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

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

What Should Happen?

You should continue conversation until you fill the 200K tokens window, not when you reach the recommended limit to run /compact! It used to work prior to 2.1.7 maybe even < 2.1.5

Error Messages/Logs



Steps to Reproduce


Just keep clauding until you reach the 0% remaining threshold and check the context.


Claude Model


Opus


Is this a regression?


Yes, this worked in a previous version


Last Working Version


No response


Claude Code Version


2.1.7


Platform


Anthropic API


Operating System


Ubuntu/Debian Linux


Terminal/Shell


WSL (Windows Subsystem for Linux)


Additional Information

Image
Activity
  1. alessandroavenali
    added 
    bugSomething isn't working
     on Jan 14, 2026
  2. i-dedova commented on Jan 14, 2026 
    @i-dedova
    i-dedova
    on Jan 14, 2026
    Exactly! This thing showed up yesterday and was working fine before! It now doesn't allow to continue on 170+k!
    
Image
  3. tfvchow commented on Jan 14, 2026 
    @tfvchow
    tfvchow
    on Jan 14, 2026
    (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):
    

    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):
    

      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

  4. thielm commented on Jan 15, 2026 
    @thielm
    thielm
    on Jan 15, 2026
    +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.
  5. timgu0
    self-assigned this
    on Jan 16, 2026
  6. cversek commented on Feb 14, 2026 
    @cversek
    cversek
    on Feb 14, 2026
    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. 

    2. CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE=197000 set (the community workaround from this thread)
      3. 

    

    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. 

    2. Ensure CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE (or a new env var) controls the compaction threshold too
      3. 

    3. For Opus 4.6 with 128k maxOutputTokens, the formula (contextWindow - maxOutputTokens) - 3000 yields only ~69k effective context — this is catastrophically low
      4. 

    

    Previously filed as #24856 (auto-duped to this issue).
  7. brandall76 commented on Feb 25, 2026 
    @brandall76
    brandall76
    on Feb 25, 2026
    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.
  8. i-dedova commented on Feb 25, 2026 
    @i-dedova
    i-dedova
    on Feb 25, 2026
    agree same issue, I too am back to context limit reached at 179k... quite annoying
  9. cseickel commented on Mar 16, 2026 
    @cseickel
    cseickel
    on Mar 16, 2026
    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.
  10. tacertain commented on Mar 22, 2026 
    @tacertain
    tacertain
    on Mar 22, 2026
    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.
  11. hi-fox commented on Mar 26, 2026 
    @hi-fox
    hi-fox
    on Mar 26, 2026
    Confirmed still occurring on 2.1.84:
    
Image

    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.
  12. i-dedova commented on Mar 26, 2026 
    @i-dedova
    i-dedova
    on Mar 26, 2026
    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.
    
#34958 (comment)
    

    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.
  13. vlwkaos commented on Apr 10, 2026 
    @vlwkaos
    vlwkaos
    on Apr 10, 2026
      

    1. But using opusplan, it still uses the old context limit models.
      2. 

    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?
      3. 

  14. loonylabs commented on Apr 23, 2026 
    @loonylabs
    loonylabs
    on Apr 23, 2026
    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
  15. cseickel commented on Apr 23, 2026 
    @cseickel
    cseickel
    on Apr 23, 2026
    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.
  16. junaidtitan commented on May 21, 2026 
    @junaidtitan
    junaidtitan
    on May 21, 2026
    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.
  17. J-Swift commented on Jul 13, 2026 
    @J-Swift
    J-Swift
    on Jul 13, 2026
    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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
Labels
bugSomething isn't working
Type
No type
Projects
No projects
    Milestone
    No milestone
    Relationships
    None yet
    Development
    No branches or pull requests
    Issue actions