Silent model downgrade from Opus to Sonnet after re-authentication (Max subscriber)

Summary

After API authentication failure and re-login (/login), my Claude Code session was silently downgraded from Opus to Sonnet. No notification or warning was shown. I only discovered this by manually running /model approximately 1 hour into the session.

Impact

I was performing security-critical infrastructure work (firewall rules, fail2ban configuration, honeypot architecture, network segmentation) under the assumption I was using Opus-level reasoning. The downgraded model:

• Unexpectedly output Korean text mid-conversation (completely wrong language)
• Failed to recall prior context and configurations
• Made reasoning errors that would not be expected from Opus

Evidence

Same day, same user, same machine, same Max subscription:

Session A (before re-auth): 0879ca12

• 852 assistant responses tagged claude-opus-4-6
• 0 responses tagged Sonnet

Session B (after re-auth): 86cbd671

• 0 assistant responses tagged Opus
• 283 assistant responses tagged claude-sonnet-4-6

Timeline (UTC+8)

04:37 - /login (re-authentication attempt in Session A)
04:46 - /login (another attempt)
06:49 - /login (new Session B starts)
06:53 - User begins security work, assumes Opus
06:57 - Model outputs Korean text unexpectedly (red flag)
06:59 - User notices "Anthropic has been weird lately, API kept failing"
07:40 - User suspects wrong model, runs /model
07:41 - User: "Wait! Are you sure you're Sonnet right now?"
07:45 - User: "Opus model is really weird... worse than Sonnet... wrong region?"

Environment

• Claude Code: 2.1.63
• Subscription: Max (Opus tier)
• Platform: Linux (Ubuntu VM)
• No custom model settings in settings.json (only alwaysThinkingEnabled: true)
• No /fast mode enabled

Expected Behavior

1. If a model downgrade occurs, show a clear and prominent warning to the user
2. Ideally, prevent silent downgrades entirely for paid Opus/Max subscribers
3. At minimum, the /login flow should confirm which model tier the user is reconnected to

Why This Matters

Silent downgrades are particularly dangerous when users are performing tasks that rely on the model's reasoning capability — security operations, infrastructure changes, architectural decisions. Users make risk assessments based on which model they believe they're using.