[BUG][bedrock] claude-opus-4-8[1m] from /model picker writes invalid model ID → 400 "The provided model identifier is invalid"

[MSAdministrator]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When using Claude Code against AWS Bedrock, selecting Claude Opus 4.8 [1m] via the /model picker or setting "model": "claude-opus-4-8[1m]" in settings.json causes every request to fail with:

API Error (claude-opus-4-8[1m]): 400 The provided model identifier is invalid.. Try /model to switch to us.anthropic.claude-opus-4-1-20250805-v1:0.

The /model command lists claude-opus-4-8[1m] as a valid option, but the identifier it persists is not Bedrock-qualified. Bedrock requires the us.anthropic. prefix (e.g. us.anthropic.claude-opus-4-8-v1[1m]).

Additionally, the opus[1m] shorthand does not resolve to the latest Opus version — it stays pinned to an older release (currently resolves to Opus 4.6).

What Should Happen?

1. /model should persist the Bedrock-qualified model ID when the active provider is Bedrock.
2. The opus[1m] shorthand should float to the latest available Opus version on the configured provider.

Workaround

Use the fully qualified Bedrock inference profile ID directly:

/model us.anthropic.claude-opus-4-8-v1[1m]

Prior Art

This is a recurring regression — the same bug was filed and fixed for Opus 4.6 (#23499, closed) and Opus 4.7 (#61495, open/stale). Each new model release re-introduces it because the picker's ID resolution doesn't account for the Bedrock prefix.

Error Messages/Logs

API Error (claude-opus-4-8[1m]): 400 The provided model identifier is invalid.. Try /model to switch to us.anthropic.claude-opus-4-1-20250805-v1:0.

Steps to Reproduce

1. Configure Claude Code with AWS Bedrock as the provider
2. Run /model and select claude-opus-4-8[1m] — OR — set "model": "claude-opus-4-8[1m]" in settings.json
3. Send any message
4. Observe 400 error

Claude Model

Claude Opus 4.8 (1M context)

Is this a regression?

Yes, this worked for older model versions after manual fixes (#23499)

Last Working Version

N/A — Opus 4.8 has never worked via the picker on Bedrock

Claude Code Version

2.1.175

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related issues:

• [BUG][bedrock] Opus 4.6 [1m] selection writes invalid model id → 400 "The provided model identifier is invalid" #23499 — Same bug for Opus 4.6 [1m] on Bedrock (closed/fixed)
• [BUG] API Error (claude-opus-4-7[1m]): 400 The provided model identifier is invalid.. Try --model to switch to us.anthropic.claude-opus-4-1-20250805-v1:0. #61495 — Same bug for Opus 4.7 [1m] (open/stale)
• [Bug] Silent model routing ignoring pinned claude-opus-4-7 setting in settings.json #65889 — Pinned model in settings.json silently ignored

[Raymoz101]

The MacOs label is misleading, I encounter this bug on Ubuntu 24 also.
Quite frustrating as I need to stay at 2.1.160 version, otherwise bedrock models with [1m] in the name fail /model picker for all users, defaulting to 200K context variants instead.

Would be great to see this looked at.

[Raymoz101]

How is this still not getting any attention?

This has been a bug since 2.1.172 - "Fixed availableModels allowlists hiding the /model picker’s Opus and Sonnet 1M rows when entries use version-specific IDs like claude-opus-4-8"

We cannot specify 1M model variants in allow lists for users within AWS Bedrock environments, please help.

[adrianhoffmann]

Confirming this is not Bedrock-specific - it reproduces identically on a custom ANTHROPIC_BASE_URL gateway with forceLoginMethod: claudeai, on v2.1.206. Same root cause: the /model picker persists an unqualified model ID that the gateway can't route.

Setup: managed plist sets ANTHROPIC_DEFAULT_SONNET_MODEL=claude-ai/claude-sonnet-4-6[1m] (our gateway namespaces models under claude-ai/).

Behavior, captured with --debug-file (dispatching to firstParty model=...):

model in settings.json	dispatched model	result
(none) → falls back to org default	claude-sonnet-4-6 (bare)	❌ 403 claude-sonnet-4-6/undefined
sonnet[1m] (alias)	claude-ai/claude-sonnet-4-6[1m]	✅
claude-sonnet-4-6[1m] (what the picker writes for the 1M row)	claude-sonnet-4-6[1m] (bare)	❌ 403

So the alias form resolves correctly through ANTHROPIC_DEFAULT_*_MODEL, but the moment the picker writes the resolved bare literal to settings.json, that literal is sent verbatim and bypasses the env-var prefix mapping → the gateway rejects it. Selecting the "Sonnet 4.6 (1M context)" row breaks the session every time; the plain "Sonnet" row (which stays an alias) works.