Desktop Code tab caps Opus 5 / Fable 5 at 400K context on Max 5x; second machine on same account gets 1M

Preflight Checklist

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

What's Wrong?

On a Max 5x plan, the Claude Desktop Code tab on one machine (Windows 10 tower) caps the context window at an undocumented 400.0k for both Opus 5 and Fable 5, while a second machine (Windows 11 laptop) on the same account and same app version correctly shows 1.0M for the same models. Sonnet 5 shows 1M on both machines.

The affected machine's .claude.json contains contradictory entitlement state that survives sign-out/sign-in, and the account profile is not re-fetched on fresh login:

1. Contradictory state: oauthAccount.hasExtraUsageEnabled: true while cachedExtraUsageDisabledReason: "org_level_disabled_until" persists. Before usage credits were enabled, this key read "org_level_disabled"; enabling credits changed it to "org_level_disabled_until" instead of clearing it.
2. Stale cache survives sign-out: the "org_level_disabled_until" value persisted through sign-out -> full quit (from tray) -> relaunch -> sign-in.
3. Profile not re-fetched on login: oauthAccount.profileFetchedAt still predates the sign-out/sign-in cycle by ~20 minutes, i.e. the fresh login reused a stale profile.

The model picker on the affected machine offers only "Fable 5" — no separate 1M variant row — even though additionalModelOptionsCache contains a claude-fable-5[1m] entry.

Related but distinct from #36515, #36662, #55504, #47019, #34958 (those are 200K-vs-1M on older models; this is an undocumented 400K on Opus 5/Fable 5 with a working second machine as control).

What Should Happen?

• Opus 5 and Fable 5 sessions in the Desktop Code tab should get the 1M context window on Max plans (matching the second machine's behavior and the extended-context documentation at https://code.claude.com/docs/en/model-config#extended-context).
• cachedExtraUsageDisabledReason should be cleared when hasExtraUsageEnabled becomes true.
• Sign-out/sign-in should invalidate cached entitlement state and re-fetch the account profile.
• 400K does not correspond to any documented context window tier; if it is an intentional intermediate state, it is undocumented.

Error Messages/Logs

Relevant .claude.json state on the affected machine, captured AFTER sign-out -> full quit -> relaunch -> sign-in (UUIDs/email redacted):

"oauthAccount": {
  "organizationType": "claude_max",
  "organizationRateLimitTier": "default_claude_max_5x",
  "hasExtraUsageEnabled": true,
  "billingType": "stripe_subscription",
  "profileFetchedAt": <timestamp ~20 minutes BEFORE the sign-out/sign-in cycle>
},
"cachedExtraUsageDisabledReason": "org_level_disabled_until",
"additionalModelOptionsCache": [
  { "value": "claude-fable-5[1m]", "label": "Fable", "description": "Fable 5 · Most capable for your hardest and longest-running tasks" }
],
"modelAccessCache": [],
"autoCompactWindowsCache": null

Context pill on affected machine (fresh session, post sign-out/sign-in): "Context window 67.7k / 400.0k" on Opus 5; Fable 5 sessions also show x / 400.0k.
Context pill on working machine, same account: "127.9k / 1.0M" on Fable 5.

During the earlier 200K phase, the app intermittently showed: "Authentication service was unavailable. You can try again."

Steps to Reproduce

1. Max 5x plan, usage credits initially DISABLED. Both machines showed 200K for Opus 5 / Fable 5 in the Code tab (Sonnet 5 showed 1M). At that point .claude.json showed hasExtraUsageEnabled: false, cachedExtraUsageDisabledReason: "org_level_disabled".
2. Enabled usage credits in Settings -> Usage. Fully quit and relaunched the app on both machines.
3. Machine A (Windows 11 laptop): immediately correct — Fable 5 session shows 127.9k / 1.0M.
4. Machine B (Windows 10 tower): new sessions show x / 400.0k for both Fable 5 and Opus 5. Not 200K, not 1M — 400K.
5. On Machine B: signed out, fully quit (from system tray), relaunched, signed back in, started a brand-new conversation -> still 67.7k / 400.0k on Opus 5.

Note: before the usage-credits toggle was ever touched, Machine A (the laptop) had also displayed a 400K window for a period, then dropped to 200K on its own with no configuration change. So the undocumented 400K state has now appeared on both machines at different times.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude for Windows Version 1.24012.9 (03c61d)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment:

• Plan: Max 5x (default_claude_max_5x, Stripe subscription)
• Affected machine: Windows 10 tower — Claude Desktop app, Code tab, latest version
• Working machine: Windows 11 laptop — same account, same app version, shows 1M correctly
• Models affected: claude-opus-5, claude-fable-5 (both 400K). claude-sonnet-5 unaffected (1M on both machines)
• Troubleshooting already attempted on affected machine (no change): full quit from tray + relaunch; new conversations; sign-out -> quit -> relaunch -> sign-in -> new conversation

Happy to provide full redacted .claude.json snapshots from both machines (before and after enabling usage credits) on request.

Laptop Screen after relaunch:
<img width="550" height="308" alt="Image" src="https://github.com/user-attachments/assets/999d9ed3-70d8-45dc-a0db-d7137bd8034f" />

Tower PC After Relaunch (was the same before):
<img width="441" height="239" alt="Image" src="https://github.com/user-attachments/assets/d30a2ff5-bd79-459c-9ff1-4261fc4e5159" />

Laptop Before enabling usage credits (shows Opus 5 at 200K; Fable 5 was the same):
<img width="542" height="607" alt="Image" src="https://github.com/user-attachments/assets/18aff0b4-a69a-4417-98d0-ad8f6e778e19" />

Note: The tower showed 400K prior to the current version as well, to the best of my recollection, so it does not appear tied to a specific app version. Both machines are confirmed on the identical version: 1.24012.9 (03c61d). The Windows 11 laptop is now working fine on this version after enabling extra usage and restarting the app. The Windows 10 Tower is currently not.

---

Update 2026-07-24 — additional state read from the affected machine

Re-read ~/.claude.json on the affected tower a few hours after filing. Everything above still holds — hasExtraUsageEnabled: true and cachedExtraUsageDisabledReason: "org_level_disabled_until" are still coexisting, modelAccessCache is still empty, autoCompactWindowsCache is still null. Four additions:

1. Cleaner evidence for the stale-profile claim (item 3 above). Rather than relying on my recollection of when I signed in — the same file holds two cache timestamps written during the same app run:

oauthAccount.profileFetchedAt : 1784925403028  ->  2026-07-24 13:36:43 -0700
cachedGrowthBookFeaturesAt    : 1784931104627  ->  2026-07-24 15:11:44 -0700

~1h35m apart. The app refreshed its feature-flag cache without refreshing the account profile, in the same session — verifiable from the file alone, no reliance on when I clicked sign-in.

2. There is no Opus [1m] variant cached at all. additionalModelOptionsCache contains exactly one entry — the claude-fable-5[1m] one quoted above. So the missing-1M-row symptom is narrower than I described: for Opus 5 the app has no [1m] option cached to offer in the first place.

3. seatTier and userRateLimitTier are both empty on oauthAccount, while organizationRateLimitTier is populated (default_claude_max_5x). orgModelDefaultCache is null and additionalModelCostsCache is {}.

4. Possibly relevant flags in cachedGrowthBookFeatures on the affected machine:

tengu_hawthorn_window          = 200000
tengu_velvet_hammer_fable_5    = false
tengu_velvet_mallet_fable_5    = false
tengu_velvet_hammer_opus       = false
tengu_velvet_mallet_opus       = false
tengu_velvet_hammer_opus_4_8   = true
tengu_velvet_mallet_opus_4_8   = true

I don't know what these control, so treat the interpretation as unverified — but the Opus 5 / Fable 5 entries reading false while the 4.8 pair reads true is a visible asymmetry, and a 200000 window value sitting next to a 400K display seemed worth including.

Happy to pull the same fields from the working laptop for side-by-side comparison if that would help.