Opus 4.7 ([1m] variant) capped at 200K context in Claude Code Desktop on Max plan

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/47019
2. https://github.com/anthropics/claude-code/issues/35677
3. https://github.com/anthropics/claude-code/issues/34143

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

+1

Same bug, new data point that disproves the existing hypothesis.

I'm a Claude Max user on Claude Code Desktop v2.1.141, Windows 11. The bug fires identically for me. But I haven't changed plans, haven't re-authed, and haven't changed local config between working and broken states — so the "plan-change entitlement cache" hypothesis can't be the full root cause. The bug is broader than that.

Trigger math, verified live on my machine

Claude Code computes the auto-compact trigger as:

trigger = min(CLAUDE_CODE_AUTO_COMPACT_WINDOW, detected) × CLAUDE_AUTOCOMPACT_PCT_OVERRIDE
        = min(1_000_000, ~200_000) × 0.95
        = ~190_000

That matches the cascade onset I observe exactly. My env is correctly set to WINDOW=1000000 and PCT_OVERRIDE=95, so whatever feeds the detected value is reading the served window as ~200K for the [1m] variant on Max, not 1M.

30-day data from my local ~/.claude/cache/compaction-log.jsonl

| Metric | Value |
|:--|--:|
| Total compaction events | 607 |
| auto triggered | 602 |
| manual triggered | 5 |
| Unique sessions with at least one compaction | 153 |
| Sessions with ≥2 compactions | 114 |
| Sessions exhibiting thrash (sub-120s gap between successive compactions) | 99 (87% of multi-compaction sessions) |
| Worst single session | 29 compactions, shortest gap 59.8s |
| Worst single day | 2026-05-20 — 59 auto-compactions |

Multiple sessions show sub-second cascade gaps:

• session 826765dc-934: 12 compactions, shortest gap 0.91s
• session b8367848-30f: 8 compactions, shortest gap 0.39s
• session 588913e9-6b8: 7 compactions, shortest gap 0.57s

The harness has been logging this for a month from a single JSONL file — happy to share the raw log (120KB filtered to 30-day window).

Six client-side mitigations have all failed

Five different WINDOW/PCT permutations and one "disable via high threshold" attempt — all thrashed within 24h. Cannot be defeated client-side because min(WINDOW, detected) clamps to the wrong detected value before any client config applies.

Also filing as a Max-entitlement-not-delivered support case

The Anthropic docs at code.claude.com/docs/en/model-config#extended-context state that Max auto-upgrades Opus to 1M context. I'm being served ~200K. That's materially a paid-feature-not-delivered situation, not just a CC bug, so it's also going to support@anthropic.com in parallel — that should route to the accounts/entitlement team, not just CC engineering.

Second-order bug: manual /compact past ~350K never finishes

When the session is already in the thrash zone, /compact registers in compaction-log.jsonl with trigger: "manual" but the displayed context bar never moves. The session does not return to a usable state. Reading this as the manual /compact being queued behind the auto-cascade rather than preempting it. Even with the 200K cap, manual /compact should be a high-priority interrupt that preempts cascading auto-compactions.

One concrete debugging suggestion

Log the detected window value into compaction-log.jsonl alongside the trigger reason. Right now users and Anthropic both have to infer it from the trigger threshold. If the runtime emitted {"detected_window": 204800} we'd see this immediately and stop guessing.

Repro environment

• Claude Code Desktop v2.1.141 (latest as of 2026-05-23)
• Windows 11 Home (10.0.26200), PowerShell 5.1
• Claude Max plan, account stable for months
• Model selector: Opus 4.7 [1m], UI shows "1.0M" context

Reporter: tristen@innovation-labs.co — happy to share raw JSONL, full env dump, and a recorded thrash session on request.

cc'ing the related-issue cluster for visibility: #47019, #35677, #34143, #43989, #42375, #34332, #50204, #19567.

Another data point, on a different surface — and a concrete local field that looks like the gate.

Same core symptom on Claude Code CLI v2.1.185, macOS, Max plan, org admin role, account stable for months (no plan change and no re-auth between the working and broken states). So this isn't Windows/Desktop-specific, and — consistent with @hiddenlayer1 — the "plan-change entitlement cache" hypothesis doesn't explain it for me either.

Concrete local state that appears to gate 1M. ~/.claude.json contains an undocumented cache:

"s1mAccessCache": {
  "<org-uuid>": {
    "hasAccess": false,
    "hasAccessNotAsDefault": false,
    "timestamp": <several months old>
  }
}

hasAccess: false lines up exactly with being served a ~200K window for the [1m] model. What stands out is that this entry is stuck — I could not get the client to re-fetch it:

• Re-login does not refresh it. After re-authenticating, the ~/.claude.json mtime updates, but the s1mAccessCache[<org>] entry keeps its old timestamp and hasAccess: false.
• Deleting the key entirely + full restart does not regenerate it. With the app closed I removed s1mAccessCache (kept a backup) and restarted; the client rewrote ~/.claude.json but did not repopulate s1mAccessCache — the key stays absent and 1M is still not served.

So on both of these triggers the client never re-fetches the 1M entitlement, which fits @hiddenlayer1's point that the wrong served window is decided before any client-side config applies.

Other related flags alongside it (booleans/enums only):

• hasAvailableSubscription: false — despite an active Max subscription (billingType: stripe_subscription). That inconsistency looks relevant.
• hasOpusPlanDefault: false
• cachedExtraUsageDisabledReason: "org_level_disabled"

Actionable asks (extending @hiddenlayer1's logging suggestion):

1. At session start, log both the detected window and s1mAccessCache.hasAccess, so this is observable instead of inferred from the compaction threshold.
2. Provide a supported way to force a re-fetch of the 1M entitlement. Today neither re-login nor deleting the cache key triggers a refresh, so there's no client-side recovery path.

Additional data point — Windows 11, Claude Code CLI v2.1.136, cap triggered specifically on sub-agent spawn (Task/Agent tool), not parent session.

Working on a heavy multi-agent project (dense CLAUDE.md + handoffs + ~30 custom subagents defined in .claude/agents/, so boot context ≫100K tokens). Parent session starts with the model string claude-opus-4-7[1m] — parent works.

Failure mode: spawning a subagent via Task (e.g. our /desarrollador TK-NNN workflow) gets rejected at 1M and silently capped to ~200K on the subagent side. This matches @hiddenlayer1 and @kiyono, but adds a new trigger surface: sub-agent spawn specifically. Trivial-payload subagents (e.g. one that just echoes a token) still complete because they never approach the 200K cap; the cap only manifests when the spawned agent's own context nears the ceiling.

Local ~/.claude.json state on affected machine:

s1mAccessCache: KEY ABSENT (not just hasAccess:false — entire subtree missing)
hasAvailableSubscription: false
cachedExtraUsageDisabledReason: "org_level_disabled"
hasOpusPlanDefault: ABSENT
billingType: ABSENT
subscriptionType: ABSENT

Strictly worse than @kiyono's report — they had s1mAccessCache[<org>].hasAccess: false stuck stale. Here the whole s1mAccessCache key has never existed. Reinforces their point that there is no client-side path to refresh this cache — mine was never populated in the first place. Re-login + restart do not create it.

Env:

• OS: Windows 11 Home 10.0.22000, PowerShell 7 + Git Bash
• Claude Code CLI: 2.1.136
• Plan: Max (org-billed)
• Reproduced: multiple times across weeks in one dense multi-agent project; does not reproduce in trivial projects

Extending @kiyono's actionable asks:

1. Log the served context window into the subagent transcript at spawn time (spawn.detected_window in the JSONL). Today the subagent has no way to know it was capped — from inside it looks like a normal [1m] session that mysteriously runs out of space.
2. s1mAccessCache absent is also a stuck state — bootstrap logic doesn't populate it. Login/re-login/config-delete-restart do not trigger the first fetch. No client-side recovery path.