[BUG] Opus 4.7 [1M] context capped at 500K on Max x20 — server-side enforcement persists across fresh install (org_level_disabled stale flag)

+1 having same issue

+1 — reproducing the exact same bug.

Environment

• Claude Code: 2.1.119
• OS: Linux (WSL2)
• Plan: Max

Symptom
/context for claude-opus-4-7[1m] shows xxx / 500k tokens instead of the documented 1M.

Same flags present in ~/.claude.json:

```json
"cachedGrowthBookFeatures": {
...
"tengu_amber_redwood2": "500000",
...
},
"cachedExtraUsageDisabledReason": "org_level_disabled",
"opusProMigrationComplete": true,
"unpinOpus47LaunchEffort": true,
"migrationVersion": 12

This confirms the bug is OS-independent (Linux + Windows both reproduced) and account-bound on the server side, as described by the OP.

Please escalate the backend reset for affected Max accounts.

Update: the workaround does work on Linux, contrary to what the OP observed on Windows.

Steps:

1. /exit from Claude Code.
2. Edit ~/.claude.json — remove cachedGrowthBookFeatures.tengu_amber_redwood2 and root-level cachedExtraUsageDisabledReason.
3. Restart claude.
4. /context immediately reports xxx / 1m tokens for claude-opus-4-7[1m].

This suggests the server-side enforcement might not be strictly account-bound, or the rewrite happens on a longer interval than the OP's reproduction window. Will report back if the cap returns on next launch.

A backend reset of the org_level_disabled flag is still needed — manual JSON edits are not a sustainable fix for end users.

Reproducing on Max 5x / Windows 11 Pro / Claude Code 2.1.119.

/context reports 500k despite model showing "Opus 4.7 (1M context)".

~/.claude.json contains:
"cachedGrowthBookFeatures": {
...
"tengu_amber_redwood2": "500000",
...
}

cachedExtraUsageDisabledReason is already null on my account.

Tried the Hobbit233 fix:

1. /exit
2. Backed up ~/.claude.json
3. Removed the tengu_amber_redwood2 line, validated JSON
4. Restarted Claude Code
5. /context → still 500k

The server rewrote tengu_amber_redwood2: "500000" back into the file on launch (file size grew 29897 → 31080 bytes, mtime updated). Same Windows failure mode the OP described — local edit doesn't hold.

Adding Max 5x to the confirmed-affected list (OP: Max x20, Hobbit233: Max). Affects all Max tiers, not just x20.

Update: tried the full Hobbit233 fix on Windows 11 / Max 5x / Claude Code 2.1.119 — removing both cachedGrowthBookFeatures.tengu_amber_redwood2 AND root-level cachedExtraUsageDisabledReason (the latter was
already null, removed the key entirely).

After /exit + restart, the server rewrote both keys back into ~/.claude.json. File grew 31109 → 31350 bytes. /context still reports 500k.

Confirms the full procedure (not just the partial) fails on Windows.

+1 — reproducing on macOS / Max plan / Claude Code 2.1.121.

Environment

• Claude Code: 2.1.121
• OS: macOS (Darwin 25.4.0, arm64)
• Plan: Max ($200/mo)
• Model: claude-opus-4-7[1m]

Symptom
Effective auto-compact window measured at ~100k via threshold backsolving from compaction event logs (compactMetadata in session JSONL). Compactions fire at ~67-72k preTokens, which back-solves to a 100k window using the binary's threshold formula: threshold = min(0.95 * (window - 20000), (window - 20000) - 13000).

Flags in ~/.claude.json:

"cachedGrowthBookFeatures": {
  "tengu_amber_redwood2": "400000"
},
"cachedExtraUsageDisabledReason": "org_level_disabled"

Note my tengu_amber_redwood2 value is "400000" (different from OP's "500000" and other reporters) — suggesting per-account Statsig cohort assignment rather than a single broken value.

Workaround found: Switching to claude-opus-4-6[1m] bypasses the gate entirely — the binary's ea_ function only checks tengu_amber_redwood2 for claude-opus-4-7. Opus 4.6 with CLAUDE_CODE_AUTO_COMPACT_WINDOW=1m correctly provides the full 1M window.

Confirming Elusive7733's workaround

Max 5x / Windows 11 Pro / Claude Code 2.1.121 (it had silently auto-updated)

Fresh session still showed 500k max context.

After setting /model claude-opus-4-6[1m], /context correctly shows 1M max context.

Note: within the same session, when switching from "claude-opus-4-6[1m]" (with correct 1M max context) then using command /model opus[1m], it reverts back to model "claude-opus-4-7[1m]" (still with incorrect 500k context)

Demonstrating Elusive7733's workaround does not work as a workaround for Opus 4.7.

hey 👋 please use the /autocompact command to configure the larger context window in these cases (there should be a notification on compaction about this new command when it happens)

Update from OP — /autocompact workaround confirmed

Following @hackyon-anthropic's suggestion, /autocompact 1m in a fresh session restores the full 1M window: /context now reports
135.1k / 1m tokens (14%) on claude-opus-4-7[1m].

Env: Claude Code 2.1.121 / Win11 Pro / Max x20.

This is a client-side workaround, not a fix. ~/.claude.json still contains cachedExtraUsageDisabledReason: "org_level_disabled" and cachedGrowthBookFeatures.tengu_amber_redwood2: "500000" after the workaround — both are re-written by the server on launch.

Cohort values reported in this thread vary per account ("500000" for OP and @Hobbit233, "400000" for @Elusive7733), and the gate is scoped to claude-opus-4-7 only — consistent with a per-account Statsig cohort assignment rather than a uniform default.

Workaround for affected Max users (cc @arrev-dev @Hobbit233 @melanthius99 @Elusive7733):

/autocompact 1m

Still outstanding:

• [ ] Backend reset of org_level_disabled on affected accounts
• [ ] Documented opt-out from tengu_amber_redwood2
• [ ] Clarification on whether server-side context capping is an intentional rollout for Max plans, and how it is disclosed

Keeping this issue open until those land.

Thanks @hackyon-anthropic for the immediate workaround.

+1, reproducing this on Max 5x ($100/mo) plan, not just Max 20x.

• Plan: Claude Max 5x ($100/mo, verified active at claude.ai/settings/billing)
• Claude Code version: 2.1.123
• OS: Windows 11
• Model: claude-opus-4-7[1m] (startup header shows "Opus 4.7 (1M context)")
• /context output: 35.4k / 500k tokens — capped at 500k instead of 1M
• Local config is clean: no model override in ~/.claude/settings.json,

no ANTHROPIC_BETAS or ANTHROPIC_MODEL env vars, no project-level overrides.

• Sonnet 4.6 and Haiku 4.5 appear unaffected on the same machine.

Same symptom as the original report — confirms this isn't limited to Max 20x.
Per the docs, "On Max, Team, and Enterprise plans, Opus is automatically
upgraded to 1M context with no additional configuration" — Max 5x should
qualify.

Happy to share a redacted ~/.claude.json or full /context screenshot if useful.

+1, same issue on Max x20 since 2026-04-27.

Environment

• Plan: Max x20 (active, billing verified)
• Claude Code: 2.1.123
• Region: Yerevan, AM

/context denominators

• Opus 4.7: 1m displayed, but effective cap is 500k (matches OP)
• Sonnet 4.6: 200k
• Haiku 4.5: 200k
• Model versions all correct.

~/.claude.json flags

"cachedExtraUsageDisabledReason": "org_level_disabled",
"migrationVersion": 12

---
Update: After having the 500K bug for 10 days it now became 700K

Adding another reproduction: Windows Desktop + mobile, logout/login resolves it

Same issue here on Claude Desktop for Windows (v2.1.121) and the Claude mobile app.

Symptom: "Out of extra usage" error blocks all usage entirely, despite plan limits showing capacity remaining (5-hour: 16%, Weekly all-models: 80%). The only way to recover is to log out and log back in — this clears the stale state and restores access to remaining plan allocation immediately.

What the logs show:

config.json contains "cachedExtraUsageDisabledReason": "org_level_disabled" persisting between sessions
Repeated IndexedDB: Internal error opening backing store errors in the web log, preventing fresh entitlement fetches
When the app can't fetch a fresh usage state and falls back to the stale cached flag, it blocks all usage — not just extra usage
What differs from OP: Logout/login does resolve it for me (temporarily), whereas OP reports it had no effect. But it recurs and requires another logout/login cycle each time.

Platform: Windows 11, Claude Desktop 2.1.121 + Claude mobile (same account)

Core bug: org_level_disabled (extra usage exhausted) is being treated as "block all usage" rather than "block only extra usage spend, fall back to remaining plan allocation." These should be independent.

Having the same issue

Same issue yet different limit.

Environment

• Claude Code: 2.1.
• OS: Fedora
• Plan: Max (x5)
• Model: claude-opus-4-7[1m]

Issue
Exact same issue except I am capped at 600k tokens instead of 500k

Closing for now — inactive for too long. Please open a new issue if this is still relevant.