Max plan: 1M context window shows 200k, Remote Control unavailable

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/23432
2. https://github.com/anthropics/claude-code/issues/24208
3. https://github.com/anthropics/claude-code/issues/30163

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

Enable telemetry. I had the same issue with 1M context not showing and /remote-control not working, just enabled telemtry and it's working now. PLEASE ANTHROPIC WHY?? WHAT'S THE REASONING?? I HOPE THIS IS A BUG THIS CAN'T BE HAPPENING

Enable telemetry. I had the same issue with 1M context not showing and /remote-control not working, just enabled telemtry and it's working now. PLEASE ANTHROPIC WHY?? WHAT'S THE REASONING?? I HOPE THIS IS A BUG THIS CAN'T BE HAPPENING

Yeah, this is it. my guess is they're doing a rollout right now, and they want to watch their metrics closely. so rolling out to telemetry enabled users first.

"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
still 200K

"CLAUDE_CODE_ENABLE_TELEMETRY": "1", still 200K

Check your ~/.claude/settings.json file. Look for a section like this:

  "env": {
    "DISABLE_TELEMETRY": "1"
  },

and delete it.

I was having the same issue. I can confirm that removing the above from settings.json and then restarting Claude Code immediately made 1M context available. And, if I added the above back in, I lost the 1M context.

Hopefully the need to enable telemetry is temporary while they roll out the feature to all users.

Update: I set up a fresh Linux VM (same account, same Max plan, same version 2.1.76) and it immediately has 1M context and /remote-control. My macOS (Apple Silicon, M3 Max) still shows 200k and no /remote-control.

Telemetry is enabled on both. Tried fresh reinstalls, logout/login, clearing statsig cache - nothing works on macOS. Seems like the rollout is platform-gated (Linux first, macOS not yet).

It's just random. I use it across several machines with identical settings and some have 1M and some don't. Most don't.

Edit: I don't think you're missing out though. I've been trying to figure out why Claude has been so dumb and useless all day and I'm pretty sure the 1 million context window is the answer. Unless it's a coincidence this seems like worst model Claude model I've ever used.

yesterday i had 1mil context window and yesterday also my max plan expired and i bought it again - and now i can see 200k context window, even if i have max plan

> "CLAUDE_CODE_ENABLE_TELEMETRY": "1", still 200K Check your ~/.claude/settings.json file. Look for a section like this: "env": { "DISABLE_TELEMETRY": "1" }, and delete it. I was having the same issue. I can confirm that removing the above from settings.json and then restarting Claude Code immediately made 1M context available. And, if I added the above back in, I lost the 1M context. Hopefully the need to enable telemetry is temporary while they roll out the feature to all users.

Besides of this, delete:

"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1

Here is a minimal binary patch that restores 1M context, /remote-control, and /btw when DISABLE_TELEMETRY=1 or CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 is set. It tries to keep your telemetry settings working. Tested on v2.1.76, Max 20x, macOS: https://gist.github.com/ahundt/158d498f07a10fec4955a70bf475a20b

Workarounds confirmed for 1M context + /remote-control on macOS (Apple Silicon, M3 Max)

Tested on v2.1.76, Max 20x, macOS. Same account works out-of-the-box on a Linux VM but not on macOS - the GrowthBook server simply doesn't return the tengu_ccr_bridge feature flag for some devices.

1M context (env var - survives updates)

Add to ~/.claude/settings.json under "env":

"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6[1m]"

Restart Claude Code - /context should show 1000k. Credit to @ahundt's gist for the finding.

/remote-control (cli.js patch - re-apply after updates)

Since cli.js is plain JS (not compiled), two small patches enable /remote-control:

Patch 1 - make the command visible (change default from !1 to !0):

function dl(){return w8("tengu_ccr_bridge",!1)}
                                          ^^^ change to !0

Patch 2 - bypass the live GrowthBook API check that overrides the cache:

async function Kn6(){return zn6("tengu_ccr_bridge")}
                     ^^^^^^ change to: return!0/*tengu_ccr_bridge*/

Both patches target the tengu_ccr_bridge feature gate. The file is at:
~/node_modules/@anthropic-ai/claude-code/cli.js

Note: Function names are minified and version-specific (v2.1.76: dl, Kn6, w8, zn6). They will change in future versions. The approach to find them remains the same - search for tengu_ccr_bridge in the JS source and trace the calling functions.

These patches are lost on claude update and need to be re-applied.

Disabling extra usage at https://claude.ai/settings/usage worked for me, all telemetry disabled.

I've been trying to use an OAUTH token generated by claude setup-token and have run into these issues. I was able to restore 1M context to Opus by using the workaround suggested above, but its clear that Claude Code is not correctly reading my Max plan info and capabilities when I authenticate this way. I also lost access to the remote-control command.

When I use /login from within Claude Code I don't have these issues. However, going that route makes my authentication expire after 8 hours with no automatic token refresh - token refresh straight up doesn't work at all in Claude Code for me.

I've had a horrible time trying to get any response at all for support from Anthrophic on the issues I've been having. They don't respond to any message I try to send. I love the product but I'd have to give them an F for customer support. Please do better.

I have a Max plan, and this is my config and /status output from inside Claude Code for reference:

{
  "env": {
    "CLAUDE_CODE_OAUTH_TOKEN": "xxxxx"
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6[1m]"
  },
  "includeCoAuthoredBy": false,
  "model": "opus",
  "skipDangerousModePermissionPrompt": true,
  "gitAttribution": false
}

  Version: 2.1.81
  Session name: /rename to add a name
  Session ID: xxxxx
  cwd: xxxxx
  Auth token: CLAUDE_CODE_OAUTH_TOKEN

  Model: opus (claude-opus-4-6[1m])
  Setting sources: User settings, Project local settings
  Esc to cancel

  /usage is only available for subscription plans.

  Esc to cancel

Thank you! this fixed my issue with my context suddenly dropping to 200K from 1M!!

Workarounds confirmed for 1M context + /remote-control on macOS (Apple Silicon, M3 Max) Tested on v2.1.76, Max 20x, macOS. Same account works out-of-the-box on a Linux VM but not on macOS - the GrowthBook server simply doesn't return the tengu_ccr_bridge feature flag for some devices. ### 1M context (env var - survives updates) Add to ~/.claude/settings.json under "env": "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6[1m]" Restart Claude Code - /context should show 1000k. Credit to @ahundt's gist for the finding. ### /remote-control (cli.js patch - re-apply after updates) Since cli.js is plain JS (not compiled), two small patches enable /remote-control: Patch 1 - make the command visible (change default from !1 to !0): `` function dl(){return w8("tengu_ccr_bridge",!1)} ^^^ change to !0 ` **Patch 2** - bypass the live GrowthBook API check that overrides the cache: ` async function Kn6(){return zn6("tengu_ccr_bridge")} ^^^^^^ change to: return!0/*tengu_ccr_bridge*/ ` Both patches target the tengu_ccr_bridge feature gate. The file is at: ~/node_modules/@anthropic-ai/claude-code/cli.js **Note:** Function names are minified and version-specific (v2.1.76: dl, Kn6, w8, zn6). They will change in future versions. The approach to find them remains the same - search for tengu_ccr_bridge in the JS source and trace the calling functions. These patches are lost on claude update` and need to be re-applied.

Auto mode also affected (same root cause)

Auto mode (Shift+Tab → auto) is also gated by GrowthBook and fails on the same macOS devices.

What happens: When auto mode is active, Claude Code adds the afk-mode-2026-01-31 beta header to API requests. The API returns HTTP 400 rejecting this header, and the client shows:

Auto mode is unavailable for your plan

Code path (v2.1.90):

// Beta header is added when auto mode is active:
if (c && R16() && w && !_6.includes(tZ6)) _6.push(tZ6)  // tZ6 = "afk-mode-2026-01-31"

// API rejects it → caught here:
if (status === 400 && message.includes("afk-mode-2026-01-31") && message.includes("anthropic-beta"))
  → "Auto mode is unavailable for your plan"

Key difference from /remote-control: This is a server-side rejection, not just a client-side gate. The API itself refuses the beta header for affected accounts. A client-side patch alone cannot fix this — the server needs to recognise Max plan users as eligible for afk-mode.

The tengu_auto_mode_config feature flag (also fetched via GrowthBook) controls the client-side circuit breaker, but even if the client allows it, the API still rejects the request.

Environment: macOS, Apple Silicon (M3 Max), Max 20x plan, Claude Code v2.1.90, claude-opus-4-6[1m].

I've been running into the "Auto mode is unavailable for your plan" on 2.1.92. Workaround for me was to run /config, turn "Use auto mode during plan" to false, hit enter to save (confusing ux). I seem to have gone in and out of having auto mode available a few times in the past week or so.

Update: still affected on v2.1.104 (13 April 2026)

Attempted to post this on #28098 (77+ upvotes, same root cause) but it's locked. Linking here instead.

Three features are gated by tengu_ccr_bridge and fail on affected devices:

| Feature | Gate type | Can patch client-side? |
|---|---|---|
| /remote-control visibility | Client-side (h8("tengu_ccr_bridge",!1)) | Yes |
| /remote-control activation | Client-side async (UT("tengu_ccr_bridge")) | Yes |
| Auto mode | Server-side (API rejects afk-mode-2026-01-31 beta header with HTTP 400) | No |

Auto mode is the critical one

/remote-control can be patched locally (see earlier comments), but auto mode cannot. When the client sends the afk-mode-2026-01-31 beta header, the API returns HTTP 400 and the client shows "Auto mode is unavailable for your plan". This is a server-side entitlement check - no amount of client patching fixes it.

The tengu_auto_mode_config GrowthBook flag also gates the client-side circuit breaker, so both client and server reject it.

Current code (v2.1.104)

// Sync gate - defaults to false for affected accounts
function xp(){return MY7()&&h8("tengu_ccr_bridge",!1)}

// Async gate - calls GrowthBook API, returns false
async function JY7(){return MY7()&&await UT("tengu_ccr_bridge")}

What's been tried (no effect)

• Telemetry enabled (CLAUDE_CODE_ENABLE_TELEMETRY=1)
• DISABLE_TELEMETRY / CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC removed
• Fresh login via claude auth login
• Same account works immediately on a Linux VM (same version, same plan)

Support status

Anthropic support ticket open since early April (conversation ID 215473746474886). Escalated to human agent. No response after 9+ days despite follow-up.

@stevenpetryk - on #28098 (25 Feb) you mentioned this would be resolved in the next release. Nearly 7 weeks later, the issue persists on macOS. Is there an update on the GrowthBook rollout? The fact that the same account works on Linux but not macOS suggests a platform-specific targeting rule in the rollout config.

Resolved — turns out the cause was local config on my Mac, not server-side flag targeting. Posting for anyone who finds this issue with similar symptoms.

Root cause: I had export DISABLE_TELEMETRY=1 in ~/.zshrc. This silently fails Anthropic's eligibility check for Remote Control and Auto Mode, even on Max. Documented behaviour, see Remote Control troubleshooting docs:

The eligibility check can fail with certain environment variables present: - CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC or DISABLE_TELEMETRY: unset them and try again.

This explained the Mac vs. Linux VM difference too — same Max account, but the VM's shell didn't set the var, so its Statsig telemetry ran and eligibility passed.

Fix: Remove DISABLE_TELEMETRY from shell rc files, open new terminal, /logout then /login. /remote-control appeared in the slash-command list immediately. Auto Mode also started working (no more API 400 with the \afk-mode-2026-01-31\ beta header). \DISABLE_ERROR_REPORTING\ (Sentry) is unaffected — does not gate these features.

1M context portion of this report: moot — Opus 4.7 ships with 1M context as default, no env var needed (\/context\ shows \Xk/1000k\).

Closing.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.