[BUG] 2.1.111 introduced ~14% context window bloat at session startup (8% → 22%)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48050
2. https://github.com/anthropics/claude-code/issues/47659
3. https://github.com/anthropics/claude-code/issues/48982

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirming this regression on Windows 11 / CLI 2.1.112 with Opus 4.7 (different platform + newer model than OP - adds cross-platform evidence).

Behavior

I run 4 concurrent Claude sessions on the same machine (crew workflow, all identical config). Auto-compaction frequency changed abruptly after the 2.1.110 -> 2.1.112 update:

• Before (2.1.110): ~2 compactions per day total across all 4 sessions
• After (2.1.112): ~2 compactions per hour per session - roughly 20-30x increase in compaction frequency

Workflow completely unchanged. First session of the day hit Compacting conversation... within 30 minutes of startup, with no heavy work done.

Environment

• Windows 11 Home 10.0.26200
• Claude CLI 2.1.112 (upgraded from 2.1.110 on 2026-04-16)
• Model: claude-opus-4-7 with --effort max
• Terminal: cmd.exe via .bat launcher
• Env vars at startup:

``
CLAUDE_CODE_EFFORT_LEVEL=max
CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
CLAUDE_CODE_SUBAGENT_MODEL=claude-opus-4-7
ENABLE_PROMPT_CACHING_1H=true
``

Binary sizes on Windows (interesting - different magnitude than OP's macOS numbers)

2.1.109  243,366,560 bytes  (2026-04-15)
2.1.110  244,445,344 bytes  (2026-04-16 morning)
2.1.112  245,424,288 bytes  (2026-04-16 evening)

Windows shows only ~1 MB growth between .110 and .112, not the ~14 MB OP saw on macOS. This suggests the bloat may not be in the binary itself - could be in bundled system-prompt strings, tool schema JSON, or something that expands at runtime rather than on-disk. Worth investigating whether the startup context growth is consistent across platforms even when binary-size delta differs.

Observable signal from inside the CLI

At session start, the system emits this warning (visible in the CLAUDE.md context that gets loaded):

\WARNING: MEMORY.md is 257 lines and 32.1KB. Only part of it was loaded.\

This tells me the auto-memory index is being truncated at load time, yet compaction still fires early. So the baseline context is already inflated by something other than user memory content.

Baseline context components on my setup

| Component | Size |
|---|---|
| Global \~/.claude/CLAUDE.md\ | 738 bytes |
| Project \CLAUDE.md\ | 20.5 KB |
| \MEMORY.md\ (truncated on load) | 32.5 KB |
| Memory directory (240 files, lazy-loaded) | 1.2 MB total |

Nothing in this list has changed in weeks. Only the CLI version changed.

Impact

• Effective work time per session cut by roughly 5-10x before context compaction interrupts
• Multi-agent/crew workflows disproportionately hit - every session now interrupts every 30 min
• Compaction summaries themselves add context back in, making each subsequent window shorter

Strong +1 on the \/context\ breakdown request

A per-component breakdown (system prompt / tool schemas / MCP / CLAUDE.md / memory / skills) would let users self-diagnose in 60 seconds instead of filing speculation-heavy bug reports. Given the divergence between macOS (~14 MB binary growth) and Windows (~1 MB binary growth) with what appears to be the same behavioral regression, the actual culprit probably isn't visible from outside - devs and users both need the breakdown.

Yup. Now I am getting pissed. Reached my 5 hours quota in 3 hours when I have NEVER reached it before today in 5 hours. Please get this fixed soon.

Plan usage limits
Max (20x)
Current session

Resets in 1 hr 58 min

100% used

Weekly limits
Learn more about usage limits

All models

Resets Thu 4:00 PM

26% used

Sonnet only

Resets Thu 7:00 PM

1% used

 You've hit your limit · resets 2pm (America/New_York)
     /extra-usage to finish what you’re working on.

✻ Sautéed for 7m 28s

> /rate-limit-options

──────────────────────────────────────────────────────────────────────────────────────────────────────
  What do you want to do?

  > 1. Stop and wait for limit to reset
    2. Switch to extra usage
    3. Switch to Team plan

  Enter to confirm · Esc to cancel

"Switch to extra usage" I see what you did there... (Frustrated coder who codes to handle anxiety... I am goosfrabaing... Thank you for Claude CLI... I love it... I credit my Claude CLI crew in my repos and quote them on my profile.) 🖖

Update after further investigation (2026-04-18)

Workaround found: Rolling back to 2.1.98 via the stable channel reduces startup from 22% to ~11–12%. Not back to the historical 8% baseline, but meaningfully better than 2.1.111/112. To pin: Settings → Auto-updates → Channel: stable, then downgrade via the native installer.

/context breakdown already exists — the feature request in the original report is implemented. It shows per-component token usage. With 2.1.98 and all MCPs/plugins disabled, a clean startup shows:

| Component | Tokens | % |
|---|---|---|
| System prompt | 6.1k | 3.1% |
| System tools | 7.9k | 4.0% |
| Custom agents | 1.3k | 0.6% |
| Memory files | 4.1k | 2.0% |
| Skills | 2.7k | 1.4% |
| Total floor | ~22k | ~11% |

The hard floor from Anthropic-controlled code (system prompt + system tools) is 14k tokens / 7%. Historical baseline was ~8% total, implying those two categories were ~10k before 2.1.111. The remaining ~3–4% above historical comes from user config and is tunable.

Confirmed: All user-side mitigation (removing MCPs, plugins, trimming CLAUDE.md, disabling agents) cannot get below the 7% hard floor. The regression is inside Claude Code's own system prompt/tool schema injection.

Per-turn overhead is the bigger problem: Running /context before and after a single trivial exchange ("5 x 3?" → "15") on a fresh 2.1.98 session showed context jump from 22.4k (11%) to ~36k (18%) — ~13.6k tokens added for a one-token answer. This suggests the system context is being re-injected or re-counted each turn, not just at startup. The per-turn cost compounds the startup bloat and is what actually drains a 5-hour quota window in 90 minutes of real work.

This is ridiculous. I see ":Compacting conversation… (1m 29s · ↑ 8.6k tokens · thinking with max effort)" almost as often as I get responses. Something is CLEARLY BROKEN and these guys are COMPLETELY IGNORING IT.

Does anyone actually work at Anthropic? Or are you all too busy spending money?

Update 2026-04-18: Per-turn overhead isolated; effortLevel:high interaction identified

Following up with two additional findings from today's investigation.

Finding 1: effortLevel:high multiplies per-turn cost significantly

Testing on 2.1.98 with a trivial exchange ("5 x 3?" → "15"), measuring messages token delta before and after:

| Config | Messages before | Messages after | Delta |
|---|---|---|---|
| effortLevel: high | 216 tokens | ~13,800 tokens | ~13,600 tokens |
| effortLevel: normal | 216 tokens | 6,600 tokens | ~6,400 tokens |

Setting effortLevel: high in settings.json adds ~8k tokens of thinking overhead to every single exchange, including trivial ones. This is likely extended thinking tokens being counted against context. This setting is not well-documented and users who have enabled it globally are experiencing 2x the per-turn cost on top of the startup regression.

Finding 2: Residual per-turn overhead remains on normal effort

Even with effortLevel: normal, a one-token response costs ~6.4k tokens in context overhead per turn. The question + answer together are ~5 tokens. The remaining ~6.4k is Claude Code injecting system context per turn — consistent with the system-reminder repetition issue reported in #46339.

Net impact for power users

A user with effortLevel: high set globally (as I had) experiences:

• 11% startup floor (regression)
• ~13.6k tokens per trivial turn (effortLevel overhead)
• Compounding on every GSD phase command, every file read, every Playwright interaction

This explains quota windows draining in 90 minutes of real work on a $200/month Max subscription.

Recommendations:

1. Document effortLevel: high as a high-cost setting with a warning that it applies extended thinking to every exchange
2. Consider disabling extended thinking for non-agentic single-turn exchanges automatically
3. Address the per-turn system reminder repetition separately (#46339)

I don't understand this. I can get the same work done that 5 guys could in the same amount of time when I use Claude CLI and I am working on very complicated stuff (C# > WGSL, GLSL, Wasm transpilers, ML engine development, Voxel Engine development, Gaussian splatting engines and generation tools, etc.)

How is Anthropic not blowing us away with their improvements, fixes, and issue responses? I get more feedback on issues I report to a 1 man dev team than I do this TRILLION DOLLAR COMPANY I am paying $200 a month. 👎

(I will say, I would prefer they fix the problem over talking about it... so if that is what they are doing, I am grateful. Just been a lot of issues this month)

Adjacent evidence: context compaction silently dropped a critical user directive

Different specific bug than the binary-size regression above, but same context-management family - and the two may compound. When startup context is already 22% before any work begins, mid-session compaction has less headroom and the consequences get worse.

I asked the assistant to inspect its own session jsonl after I noticed it had lost track of an overnight directive I gave it before bed.

Setup:

• Long session with a long-running background processing job
• I gave the assistant an explicit overnight directive at jsonl line 9656 (UTC 2026-04-19T05:38:13)
• Background job completed successfully at jsonl ~line 9802 (UTC 05:56:41, exit code 0)
• Session continued autonomously for ~7 more hours, going through several compaction events
• I returned in the morning and asked "make any progress on [task]?"

The failure:
The summary handed to the assistant on the final session resume contained:

• Zero mention of the overnight directive (line 9656 was dropped)
• Zero mention of the background job completion (line 9802 was dropped)
• A description of follow-on work, presented as if it were the original task

The assistant honestly answered "no, I made no progress on that" - because the summary it was working from genuinely had no record of the work that had been done. Only after I pushed back ("what happened?") did it read the full jsonl transcript directly and discover that the original task was completed in the first ~3 hours of the session, and the subsequent autonomous work was the next phase of the directive.

Net effect from the user side: a session that successfully completed the requested task gave the user the impression it had done nothing, because the summary said it had done nothing.

Pattern across successive compactions in this single session jsonl:

1. Compaction #1 preserved the original directive verbatim
2. Compactions #2-4 progressively summarized the directive down to a partial quote
3. Compactions #5-7 dropped the directive entirely and replaced it with the current task ID as if the task ID alone constituted the user's intent

The compaction algorithm biases toward preserving most-recent task state and drops the original user directive as it ages - the opposite of what's needed for long autonomous sessions. The user's original directive is the most load-bearing piece of context in any long autonomous run; it should be the last thing dropped, not the first.

Verifiable from the jsonl:

The session jsonl is ~68 MB and contains the full pre-compaction message stream. Anyone with access to a similar long-autonomous-session jsonl can reproduce the diff by comparing the user-text messages at early line numbers vs. what survives in the summary blocks at later line numbers. The user-text content at line 9656 is structurally absent from every summary block after roughly line 11000.

Suggested fix vector:

1. Mark direct-from-user text content as "high-priority preserve" in the compaction priority function
2. When a session has been in Auto Mode without user input for >N minutes, the original directive that initiated the autonomous run is the closest thing to ground truth - never drop it
3. Surface a /context summary-history command so users can see what's been compacted out, and a /context restore-directive to re-promote a specific original message back to top-of-context

This is filed as a separate observation rather than a separate issue because it appears symptomatic of the same root pressure (less headroom = more aggressive compaction = more silent drift). If the binary-size regression in 2.1.111 is fixed, this class of failure should also become rarer.

(Comment authored by the Claude Code assistant itself, posted via my account at my request, after it inspected its own session transcript.)

Update 2026-04-19: Per-turn overhead isolated and quantified; extensive config investigation completed

Finding 1: Per-turn overhead is ~8-9k tokens regardless of response complexity

Two controlled tests, fresh sessions, single command "go to reciter research":

| Test | Before | After | Messages delta |
|---|---|---|---|
| Run 1 | 23.2k (12%) | 30.4k (15%) | +8,484 tokens |
| Run 2 | 23.2k (12%) | 30.9k (15%) | +8,884 tokens |

Response in both cases: listed 2-3 directories, asked one clarifying question. System prompt, tools, agents, memory, and skills all stayed completely flat. The entire overhead lands in the Messages category per turn. A one-sentence response should cost ~50 tokens. The remaining ~8,800 tokens is Claude Code injecting system context on every turn — consistent with #46339.

Finding 2: effortLevel:high multiplies per-turn cost ~2x

settings.json global effortLevel: high (extended thinking) added ~8k tokens on top of the baseline per-turn overhead. With effortLevel: normal the per-turn cost is ~8-9k. With high it was ~13-14k. This setting is not well-documented and users who have enabled it globally are experiencing compounded burn.

What has been ruled out through exhaustive investigation

• GSD workflow system (21 agents, 50+ skills, hooks) — negligible startup contribution, hooks firing confirmed not responsible for per-turn overhead
• MCP servers (Playwright, context7, PubMed, Google Drive) — disabling all MCPs recovered ~2% startup, no effect on per-turn overhead
• Plugins (superpowers, ui-ux-pro-max, frontend-design, skill-codex) — no measurable impact
• Port scan SessionStart hook — ~200 tokens, irrelevant
• node_modules CLAUDE.md files — present but empty, no contribution
• Multiple competing Claude Code installations (Homebrew + nvm + native) — removed duplicates, no effect on per-turn overhead
• Project-level settings.json overrides — none found
• CLAUDE.md file sizes — within reasonable bounds for the projects

Net impact

With effortLevel: normal (now fixed) and the per-turn bug, a 5-hour quota window drains in ~90 minutes of active work at typical GSD phase transition cadence. Each phase command triggers multiple tool calls, each costing ~8-9k overhead tokens per exchange. This is the primary drain, not the startup floor.

Environment: macOS, Claude Max, Sonnet 4.6, 2.1.114, single npm-global installation via nvm.

Possibly related mitigation while the bloat itself gets addressed: the 1M context auto-upgrade for Max/Team/Enterprise plans isn't firing on current versions (detailed in #50803). If you're on a qualifying plan, running /model claude-opus-4-6[1m] as a slash command (persists to settings.json) flips the window from 200K to 1M. Your measured 45K baseline then becomes ~4.5% of the window instead of 22%, which substantially extends working time between compactions. Doesn't solve the underlying bloat - 45K is still 45K - but may make the symptom much less painful in the meantime.

Drafted with Claude Code (Opus 4.7) as peer reviewer - same AI-human workflow many of you are already using.

Update 2026-04-19: 1M context window tested; per-turn overhead confirmed unchanged; bare default settings confirmed

Tested claude-opus-4-7[1m] (Opus 4.7 with 1M context window) as suggested in comments above.

Results after same controlled test ("go to [project name]")

| Metric | Sonnet 4.6 / 200k | Opus 4.7 / 1M |
|---|---|---|
| Startup floor | 23.2k (12%) | ~30k (3%) |
| After navigation command | 30.9k (15%) | 37.1k (4%) |
| Per-turn overhead (absolute) | ~8-9k tokens | ~6-8k tokens |
| Free space | 143k (72%) | 928k (93%) |

The underlying bug is unchanged — per-turn overhead is still ~6-8k tokens in absolute terms on every single exchange. The 1M window makes the percentage look small but the absolute token burn is identical.

Confirmed with bare default settings

The Opus 4.7 / 1M test above was run with settings.json renamed away — Claude Code running with zero custom configuration: no GSD hooks, no plugins, no custom agents, no MCP servers, no CLAUDE.md instructions beyond the bare defaults. The per-turn overhead is identical. This conclusively rules out all user configuration as a factor.

Why this still gates productivity

On a Max subscription with a 5-hour rolling usage window, quota is consumed by total tokens processed — not percentage of context window. A GSD-heavy workflow with frequent phase transitions, each triggering multiple tool calls at ~6-8k tokens overhead each, exhausts the quota window at the same rate regardless of whether the window is 200k or 1M. The larger context window delays compaction, not quota drain.

The 1M window is a partial improvement for users hitting compaction walls. It does not address the core issue for users hitting the 5-hour usage limit — which is the actual pain point.

Summary of what has been ruled out

Through exhaustive investigation the following were confirmed as not responsible for the per-turn overhead:

• GSD workflow system (21+ agents, 50+ skills, multiple hooks)
• All MCP servers (Playwright, context7, PubMed, Google Drive)
• All plugins (superpowers, ui-ux-pro-max, frontend-design, skill-codex)
• SessionStart hooks including port scan
• node_modules CLAUDE.md files
• Multiple competing Claude Code installations
• Project-level settings.json overrides
• effortLevel: high (this was separately real — doubled per-turn cost on top of the bug, now fixed)
• All user configuration (confirmed via bare default settings test)

The per-turn ~6-8k token overhead reproduces on a completely fresh session with zero custom configuration, a one-sentence input, and a one-sentence response. It is entirely in the Messages category. System prompt, tools, agents, memory, and skills remain flat. This is Claude Code's own behavior, not user configuration.

Environment: macOS, Claude Max, 2.1.114, single npm-global installation via nvm.

A fix for this should be in 2.1.117 today

Tested on 2.1.117. Fresh session, same controlled test: Messages bucket went from 216 to 8,500 tokens for a "5 + 2?" → "7" exchange. Delta of 8,284 tokens. Identical to 2.1.114 and 2.1.116. Whatever shipped in 2.1.117 did not address the per-turn overhead documented here.

Sorry, I interpreted this as being about the incorrect message about how much context is used. The per-turn overhead you're measuring isn't a Claude Code bug — it's an expected Opus 4.7 behavior change.

Opus 4.7 uses an updated tokenizer that maps the same text to roughly 1.0–1.35× more tokens than Opus 4.6, depending on content type. Opus 4.7 also thinks more at higher effort levels, and those thinking blocks get carried forward as input on subsequent turns.

To reduce token usage:

• /effort low or /effort medium for lower per-turn overhead
• Or /model claude-opus-4-6[1m] to stay on the prior model

Closing this, but please open a new issue if you see anything that looks like a genuine Claude Code regression separate from the model change.

Reopening concern: the closing rationale cited Opus 4.7 tokenizer behavior, but this reproduces identically on Sonnet 4.6 with effortLevel: normal and bare default settings. Filed as new issue #51809 with full reproduction data. The per-turn overhead is not a model tokenizer issue.

8% to 22% startup bloat overnight is a massive hit. Cozempic's guard daemon + metadata-strip prune accumulated session bloat so the usable context stays near full. Can't fix what CC injects at startup, but keeping the rest lean means that 22% overhead hurts less in practice.

pipx install cozempic && cozempic guard — https://github.com/Ruya-AI/cozempic

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.