Feature availability by plan should be clearly documented

Problem

When new features are announced or documented, it's not clear which subscription plans they're available on. This leads to wasted time configuring features that turn out to be unavailable.

Auto Permission Mode

The auto permission mode is documented and configurable (permissions.defaultMode: "auto", autoMode settings block), but when starting a session on a Max $20 plan, the only feedback is:

auto mode temporarily unavailable

• The message says "temporarily", implying a transient issue — not a plan limitation
• Shift+Tab doesn't show auto mode in the cycle, with no explanation why
• The autoMode config block in settings.json is accepted without warning that it won't be used
• There's no documentation page clearly stating which plans support auto mode

I spent significant time migrating my permission setup (slimming 184 allow rules to 14, configuring autoMode.environment, autoMode.allow, autoMode.soft_deny) only to discover after multiple session restarts that the feature simply isn't available on my plan.

1M Context Window

Same pattern — the 1M token context window was announced for Opus, but the rollout details were unclear:

• The model identifier shows "1M context" (e.g., Claude Opus 4.6 (1M context)), suggesting it's active
• No clear indication in the CLI or docs whether the 1M window is available on Max $20 vs Team vs API plans
• No way to check from within Claude Code what your actual context limit is
• Users see the "1M context" label and assume they have it, then hit unexpected compaction/truncation without understanding why

Both cases follow the same pattern: a feature is visible in the UI/config but the actual availability by plan is undocumented, and the error messages don't distinguish between "not on your plan" and "temporarily broken."

Expected Behavior

1. Clear plan requirements in docs: Every feature page should state upfront which plans support it (e.g., "Available on: Team, Enterprise, API" or "All plans")
2. Accurate error messages: "auto mode temporarily unavailable" should distinguish between "service is down, try again later" vs "not available on your plan" — these are very different situations
3. Config validation warnings: If permissions.defaultMode: "auto" is set but auto mode isn't available on the plan, show a warning at session start (e.g., "auto mode is not available on the Max plan — falling back to default mode")
4. Context window transparency: Show the actual context limit in the session status or at startup, not just the model's theoretical maximum
5. Feature availability matrix: A single page listing all features and their plan requirements would prevent this entirely

Impact

• Time wasted configuring unavailable features
• Misleading "temporarily unavailable" message causes repeated troubleshooting attempts
• Users may assume their configuration is broken rather than understanding it's a plan limitation
• The "1M context" label in the model name creates false expectations when the actual limit is lower

🤖 Generated with Claude Code