[BUG] Cowork (Not Claude Code) 1M context window unavailable on Max 5x — regression from March 20

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/36760

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

Not a duplicate. https://github.com/anthropics/claude-code/issues/36760 is a feature request. This issue is a bug -- users no longer have access to the 1M context window in Cowork because of this regression issue.

I can confirm this regression on Max from local runtime evidence on the same Mac.

This is not just the model picker label. Cowork’s actual runtime context window changed:

• Working Cowork sessions on March 17, 2026 and March 18, 2026 recorded:
• model: "claude-opus-4-6[1m]"
• contextWindow: 1000000

• Fresh broken Cowork sessions on March 22, 2026 recorded:
• model: "claude-opus-4-6"
• contextWindow: 200000

I also asked Cowork directly in a fresh session:
What is your current context window size right now? Reply with only the numeric token limit.
It replied: 200,000 tokens.

Important detail:

• Regular Claude Code on the same machine can still use the [1m] variant
• Cowork cannot
• So this appears to be Cowork / local-agent-mode specific, not an account-wide loss of 1M

I also tried all obvious local fixes without success:

• full desktop restart
• CLI logout/login
• ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m]
• same env var in ~/.claude/settings.json
• cache reset
• older desktop build side-by-side

None of those restored 1M in Cowork.

This looks like a real regression between March 18, 2026 and March 22, 2026, not local misconfiguration. I have a private evidence bundle with logs if Anthropic wants it.

Confirming this on Claude Desktop 1.1.7714 (3bd6f6), macOS, Max plan. Context shows 'Opus 4.6' without the 1M label. New sessions fail consistently — this is blocking active work. Was working correctly before this build. Pls fix!

Same issue here.

Plan: Max
Environment: VSCode extension v2.1.79 (updated from v2.1.76)
OS: Windows 11
Symptom: Opus 4.6 with 1M context was available last week, now only 200k. /model does not show opus[1m] as an option.
Troubleshooting: No settings changes on my end between when it worked and when it stopped.

Adding on to this w/ extra log evidence. I originally posted in #36351 (comment).. the issue is now 5 days old and has persisted through 4 consecutive app updates with zero fix.

Cowork Logs (cowork_vm_node.log)

The [Spawn:create] entries show the actual --model argument passed to /usr/local/bin/claude for each Cowork session - not a UI label, the runtime model.

Last working spawn > first broken spawn, same app version (1.1.7714):

2026-03-19 18:36:58 [Spawn:create] name=great-optimistic-bardeen    --model claude-opus-4-6[1m]
    > session killed 19:33:41, app restarted 19:35:22 (same version) <
2026-03-19 19:59:08 [Spawn:create] name=optimistic-determined-feynman --model claude-opus-4-6

Persisted through every subsequent app version

Version     First seen   Model in Cowork spawn
─────────── ──────────── ──────────────────────────
1.1.7203    Mar 18       claude-opus-4-6[1m]  ← working (13 spawns)
1.1.7464    Mar 18       claude-opus-4-6[1m]  ← working
1.1.7714    Mar 19 19:35 claude-opus-4-6[1m]  ← last working at 18:36
1.1.7714    Mar 19 19:59 claude-opus-4-6      ← BROKE HERE
1.1.8308    Mar 23       claude-opus-4-6      ← still broken
1.1.8359    Mar 23       claude-opus-4-6      ← still broken
1.1.8629    Mar 24       claude-opus-4-6      ← still broken (current)

Reached out to support.. here's the unfortunate ticket timeline

Opened March 19 at 16:40 PT, within ~2 hours of the regression:

• Mar 19 — AI agent acknowledged the Opus 4.6 incident (outage, not the regression).
• Mar 20 — Human support responded, suggested "clear cache and restart." Did it, didn't work, replied within 5 minutes with full log analysis. No response since.
• Mar 23 — Bumped. No response.
• Mar 24 — Bumped again. No response.

5 days, $200/mo Max account, fully documented server-side regression, zero follow-up.

As @mihai-popa-99 noted, this is Cowork-specific.. Claude Code CLI on the same machine still resolves claude-opus-4-6[1m]. The model resolution path in LocalAgentModeSessionManager is evaluating the 1M entitlement differently than CLI, and whatever server-side state it checks has been broken since March 19 19:33 UTC. No client-side workaround exists. This requires a server-side fix.

Confirming this regression — Windows / Max plan / Cowork

Environment:

• Plan: Max 5x ($200/mo)
• Platform: Windows (Claude Desktop)
• Model: claude-opus-4-6
• Product affected: Cowork

What happened:
1M context was available and working in Cowork sessions. After ~March 20, new Cowork sessions reverted to 200k with no changes on my end. Claude Code on the same account is unaffected — this is Cowork-only, consistent with the OP's report.

I have not received any communication from Anthropic about this change, either in-product or via email. I've contacted Anthropic support separately and had no response.

Impact:
I use Cowork with a large workspace (versioned CLAUDE.md, project registry, skills directory, task queue). With 200k, the system context alone consumes a significant portion of the available window, leaving limited headroom for actual work. The 1M window made Cowork genuinely viable for complex multi-file projects; at 200k it's severely constrained.

Cross-references:
This appears to be part of a recurring pattern rather than an isolated incident:

• #36760 identified a server-side feature flag (3885610113) controlling 1M access in Cowork — session JSON files show older sessions using claude-opus-4-6[1m] while new sessions use claude-opus-4-6. This confirms the rollback was a flag change, not a client-side bug.
• #33154 (early March) reported the opposite problem: Cowork was forcing [1m] and causing rate limit errors. The current regression may be an overcorrection from fixing that issue.
• #36603 and #36584 report the same 1M disappearance on macOS around the same date. #36603 was closed as invalid ("not a Claude Code issue") which, while technically accurate, doesn't resolve the problem for affected users.
• #26428 and #15057 show identical regressions (1M silently removed for paying Max subscribers) going back to December 2025 with Sonnet models.

Request:

1. Acknowledge whether this is an intentional rollback or unintended regression
2. If intentional, communicate the change and rationale to affected subscribers
3. If unintended, provide an ETA for restoration
4. Either way, consider exposing a user-facing toggle for 1M context in Cowork (as requested in #36760) rather than controlling it entirely via opaque server-side flags

The March 13 GA announcement stated that 1M context is included at standard pricing for Max, Team, and Enterprise plans. The current state is inconsistent with that announcement.

Same issue, Opus 4.6 1M not available on Cowork but available on Claude Code. Plan: Max 5x. Platform: Mac (Claude Desktop).

Same issue. Max20 here. No one cares at Anthropic. They only put out features for Claude Code, never matching Claude Cowork... it's beyond the pale... and the work compounds and we can never catch up with tiny windows.

I personally had upgraded all my workflows to the 1M context window (20+ MCPs running, 120+ tools running, etc).. then without word or warning, everything is regressed. and now nothing works.

Nice work Anthropic 👎

I asked Claude code and chat what it thought - interesting (without directing it for the answer it prob thought I wanted) was its a clear business decision that they cannot afford the token demand on the servers... I am now running some work in code 1m that should not really be there but its not as hard as I thought. Still, all the systems that worked so well in CW1m are now back to being painful... Not good for $200 - 400 pcm.

same bug at max x20 on claude cli on windows host. in parallel session in docker devcontainer all ok

## Fix: Opus 4.6 1M context "not available for your account"

### Root cause
After Claude Code update, OAuth tokens get cached with subscriptionType: null
and rateLimitTier: null. The client doesn't know you're on Max plan → blocks 1M.
claude logout + claude login does NOT help — it reuses stale tokens.

### Diagnosis
cat ~/.claude/.credentials.json
# If you see "subscriptionType":null,"rateLimitTier":null — that's it.

### Fix (one command)
rm ~/.claude/.credentials.json && claude login

### Verify
cat ~/.claude/.credentials.json | grep subscriptionType
# Should be: "subscriptionType":"max" (or your plan)

Same bug here. Cowork does not have 1M context but Code has.
Above fix does not work, as I have "subscriptionType":"max","rateLimitTier":"default_claude_max_20x"}
Please clarify and fix. I have several Cowork sessions stuck there, even compact does not work.

Confirming this too. Max 20 plan on MacOS, latest Claude desktop version. And like the message above, ton of compaction errors with context being saved to a temporary claude.md files incorrectly. I can work within my plugins and skills fine but any sort of development is pretty much halted. You all need to fix this. Not paying $200 a month for a tiny context window, constant compaction and errors.

Confirming this regression on Max 5x as well.

Context: I use Cowork daily for strategic advisory work (deeptech commercialization) -- long document analysis, multi-step reasoning over market research, adversarial stress-testing of proposals. The 1M context window was a genuine workflow improvement when it was available.

Since the regression, I've switched back to Claude Code CLI which still has 1M context working correctly. But Cowork's UI is materially better suited for non-coding strategic work -- the CLI workaround means losing the UX benefits that made Cowork compelling for this use case in the first place.

Would appreciate any visibility on whether this is a known temporary rollback (possibly related to the rate limiting issues in #33154?) or an unintended regression. Even a rough ETA would help us plan around it.

Today I tried the old session and it seems 1M context restored, although the model still shows Opus 4.6

Today I tried the old session and it seems 1M context restored, although the model still shows Opus 4.6

Is this in CoWork? And if so, how are you determining your context window size? When I look at my session json files it still shows 4.6 without the 1m like it shows in code.

Still at 200k (cowork) in UK 20x plan. Easy to test v code 1m.

Confirming this regression on Max 20x, macOS.
I relied on 1M context in Cowork for long-horizon strategic work — multi-file analysis, extended planning sessions where maintaining full context across hours of iteration was the entire value prop. The drop back to 200K fundamentally changes what Cowork is useful for.
Claude Code on the same account still has 1M, which makes this feel like an oversight rather than an intentional product decision. If the rollback was driven by rate limit complaints (#33154), the fix should be plan-aware gating or an opt-in toggle — not a blanket kill switch that punishes Max subscribers who had zero issues.
Happy to help test if a fix ships behind a flag.

Confirming this regression on Max 20x, macOS. I relied on 1M context in Cowork for long-horizon strategic work

Same. The quiet rollback is highly frustrating, but even worse is the lack of transparency about it, without offering any kind of an opt-in toggle (even a paid one!)

Adding to this. 1M context is essential for some tasks, and while I like Cowork I'm getting pushed off to Claude Code instead. Please give us a toggle of the same type given for Claude Code on the desktop app.

MacOS, Max 20x - Really need this fixing, causing no end of issues with my workflow that was build around 1M.

Unacceptable decline in the quality of the work and the platform, with the capacity of the 1M model—on which all workflows were based—reduced to one-fifth of its original level. A complete lack of transparency and communication for the past month, despite repeated reports of the issue. No interest in restoring a critical feature that has been unavailable for a month, even though users are paying the same subscription fee and spending hundreds of dollars on APIs for poor-quality content and a limited scope.

Unacceptable decline in the quality of the work and the platform, with the capacity of the 1M model—on which all workflows were based—reduced to one-fifth of its original level. A complete lack of transparency and communication for the past month, despite repeated reports of the issue. No interest in restoring a critical feature that has been unavailable for a month, even though users are paying the same subscription fee and spending hundreds of dollars on APIs for poor-quality content and a limited scope.

edit: at around 02:00 GMT+2 on 16/04 there was again the 1M context for Opus and Sonnet 4.6 for a while. After few hours it was disabled again and set to 200k for all in Cowork

OMG - thanks @Campa202 for your comment (1M back briefly then 200K again) - I thought I was hallucinating ! What happened on my side :

• I thought : "weird, no compaction yet - let me check what's left (/context) and then : wow : 1M but no mention of it in the app, I still have 58% free
• then next message : compaction
• then cowork crash
• after restart : text within the task : none (like starting a new task from scratch but with the next step starting
• context check : back to 200K

Again - this is totally unacceptable. With Opus 4.7 it's even worse - the compaction has gotten better in that it hasn't broken anything but even with exporting context (wrote a skill to do this), it's very inefficient. I dont want to have to use code for things I do in CoWork. I keep them separate. This needs fixed. I dont understand how no now has even looked at this and how only 12 people complain about this - we cant be the only power users.

Love all the upgrades with Anthropic, but this one really needs to be moved to the front of the line.

They have added 2-3 features daily for a month to Claude Code. They truly
don’t give a flying fig about cowork

The result? 120 sessions instead of 30, I use it more hitting a wall and
they would rather I not use the compute. Guess what? Any delegation to
other model increases hallucinations. It’s worse using dispatch.

On Sat, Apr 18, 2026 at 11:44 planginc @.***> wrote:

planginc left a comment (anthropics/claude-code#37413) <https://github.com/anthropics/claude-code/issues/37413#issuecomment-4274243074> Love all the upgrades with Anthropic, but this one really needs to be moved to the front of the line. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/37413?email_source=notifications&email_token=ADDL6P3PWYMKVR2LHZVSR734WO5GVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQZDIMZQG42KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4274243074>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDL6PYW4SL753LMVJV3OTL4WO5GVAVCNFSM6AAAAACW2VBKGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGI2DGMBXGQ> . You are receiving this because you commented.Message ID: @.***>

Same issue with both Team and Max 20x plan

Reproducing on macOS, Cowork with Max plan, confirmed with logs

Adding log evidence to support this report. My claude.ai-web.log shows consistent 404s on the [1m] model config across 3 weeks, with no fallback to the standard 200K model:

2026-05-14 07:46:31 [error] endpoint: model_configs/claude-opus-4-7[1m] — Not found
2026-05-14 11:26:11 [error] endpoint: model_configs/claude-opus-4-7[1m] — Not found
...
2026-05-29 08:51:15 [error] endpoint: model_configs/claude-opus-4-8[1m] — Not found
...
2026-06-02 16:55:08 [error] endpoint: model_configs/claude-opus-4-8[1m] — Not found

40+ identical errors spanning May 14–June 2, across both opus-4-7[1m] and opus-4-8[1m].

Impact: Because Cowork tries and fails to load the 1M config on every session, it never falls back cleanly. Sessions hit the context limit and cut off entirely rather than compacting. Adding CLAUDE_CODE_DISABLE_1M_CONTEXT: "1" to ~/.claude/settings.json has no effect. These errors are in the web layer, not the CLI.

When I enabled usage credits to resolve it, sessions expanded into the full 1M window with no compaction triggering (correct behaviour for 1M, but unexpected and expensive, burned ~£20 in a couple of hours on normal Cowork tasks).

The fix needed: Cowork should fall back to the standard 200K model when the [1m] config returns 404, rather than silently failing.

Confirming this still reproduces on a newer build (2026-06-13).

Same symptom as the original report: the Opus 1M-context option is missing from
the Cowork model picker in the desktop app, while the standalone Claude Code
CLI offers and uses 1M correctly on the same signed-in account.

Environment:

• Claude desktop app: 1.12603.1
• Cowork's embedded Claude Code (under ~/Library/Application Support/Claude/claude-code/): 2.1.170
• Standalone Claude Code CLI: 2.1.177 (1M works here)
• OS: macOS
• Plan: paid org/Enterprise-tier plan with Opus 1M entitlement (confirmed — the CLI

offers/uses 1M on the same account)

Notes:

• Verified Cowork and the CLI are signed into the identical account, so this is not

an entitlement difference.

• No CLAUDE_CODE_DISABLE_1M_CONTEXT and no availableModels restriction in local settings.
• Restarting the desktop app did NOT restore the 1M option and did NOT pull a newer

embedded Claude Code (still 2.1.170).

• Regression appeared after a desktop app update around 2026-06-09.

So the Cowork-only 1M regression persists on desktop 1.12603.1 / embedded CC 2.1.170,
a newer build than the original report.

Mine works again - however, CoWork does not say 1m anymore - but the context is in fact 1m - just run /context and see. Anthropics emailed me and told me they were aware of the problem and that they thought it was fixed in previous releases. I said it wasn't because there was no 1m but the reality is that the context window size is there. YMMV.

accurate thank you! i just tried and it worked. I appreciate it!!!!

<img width="988" height="196" alt="Image" src="https://github.com/user-attachments/assets/90cab60b-f50e-40f1-aa73-bd9c3a97702f" />