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

[paulalbert1]

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?

Environment

• Claude Code 2.1.112 (also 2.1.111)
• Opus 4.6, macOS Darwin 25.3.0
• 200K context window

Summary

Session startup context usage jumped from ~8% to ~22% with no changes to my project, CLAUDE.md files, MCP servers, or plugins. After extensive investigation, the change correlates exactly with the auto-update from 2.1.110 → 2.1.111 on Apr 16 2026.

Evidence

Binary sizes in ~/.local/share/claude/versions/:

• 202,932,416 2.1.110 (Apr 15 — 8% startup)
• 203,956,832 2.1.111 (Apr 16 13:35 — 22% startup)
• 203,956,832 2.1.112 (Apr 16 15:59 — 22% startup)
• 14MB increase between .110 and .111. Timing matches exactly. Nothing else changed in the environment.

Impact

• Startup context floor went from ~16K to ~45K tokens (estimated)
• Effective context burn rate ~5x higher during working sessions
• All available mitigation (pruning agents, skills, plugins, MCP servers) produced negligible improvement — confirming the bloat is inside Claude Code itself, not user configuration

What Should Happen?

• Identify and revert whatever was added to the system prompt / tool schemas in 2.1.111 that caused this, or provide a config flag to opt out of the expanded content.
• Add a /context command showing a per-component breakdown of startup token usage (system prompt, tool schemas, MCP servers, CLAUDE.md, skills list, memory). Without this, users are forced to do blind archaeology when startup bloat occurs. This is the 6th time I've investigated this class of issue; a breakdown command would have resolved it in 60 seconds.

Error Messages/Logs

None

Steps to Reproduce

Pin to 2.1.110: ln -sfn ~/.local/share/claude/versions/2.1.110 ~/.local/bin/claude
Start session, run trivial prompt, note context %
Update to 2.1.112, repeat

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.112

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. System prompt size tripled after update to v2.1.101, causing 3x faster quota consumption #48050
2. Cold start context usage increased significantly between versions #47659
3. [Bug] Session starts with unexplained high token usage (31% consumed on first message) #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

[LostBeard]

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.

[LostBeard]

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.

[LostBeard]

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

[LostBeard]

 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.) 🖖

[paulalbert1]

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.

[LostBeard]

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?

[paulalbert1]

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 (System prompt token bloat: ~40-50% increase between v2.1.92 and v2.1.100 #46339)

[LostBeard]

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)