[BUG] /model picker drops Sonnet (1M context) when modelOverrides maps to Bedrock inference profile ARNs

What's Wrong?

When using modelOverrides to map Anthropic model IDs to AWS Bedrock application inference profile ARNs, the /model picker drops "Sonnet (1M context)" when availableModels is also set. "Opus (1M context)" still appears, creating an inconsistent experience. Removing availableModels entirely restores the missing entry.

What Should Happen?

The /model picker should show all model variants including "Sonnet (1M context)" and "Opus (1M context)" when both modelOverrides and availableModels are configured.

Error Messages/Logs

No error — the entry is silently filtered from the picker.

Steps to Reproduce

1. Configure Claude Code for AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1)
2. Set modelOverrides and availableModels in ~/.claude/settings.json:

``json
{
"modelOverrides": {
"claude-sonnet-4-6": "arn:aws:bedrock:us-west-2:123456789012:application-inference-profile/abc123",
"claude-opus-4-6": "arn:aws:bedrock:us-west-2:123456789012:application-inference-profile/def456"
},
"availableModels": ["sonnet", "sonnet[1m]", "opus", "opus[1m]", "haiku"]
}
``

1. Start Claude Code and run /model
2. Observe: "Sonnet (1M context)" is missing from the picker. "Opus (1M context)" appears.
3. Remove availableModels key from settings, restart — "Sonnet (1M context)" reappears.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Claude Code Version

2.1.81

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The issue appears to be in how the availableModels filter interacts with modelOverrides for [1m] context variants on Bedrock.

When modelOverrides remaps model IDs to ARNs, the internal model constants become ARN values. The picker builds 1M entries by appending [1m] to the resolved model value, producing strings like "arn:...abc123[1m]".

The filter normalizes each picker value via a reverse lookup through modelOverrides (finding a key whose value matches). For base entries this works — "arn:...abc123" resolves back to "claude-sonnet-4-6" which contains "sonnet", matching the allowlist.

For [1m] entries, "arn:...abc123[1m]" doesn't match any override value (values are plain ARNs without the suffix), so the reverse lookup fails and the raw ARN+[1m] string is compared against availableModels — which doesn't match.

Suggested fix: The reverse-lookup should strip the [1m] suffix before searching override values, or resolve [1m] variants through their base model's override mapping.

Workaround: Remove availableModels from settings. modelOverrides alone still routes API calls correctly.