Custom Bedrock models not discoverable in /model command list

Status Open

Maintainer reply None cached

Activity 5 comments · opened Oct 23, 2025

Description

Custom Bedrock inference profile models defined in ~/.claude/settings.json environment variables work when explicitly invoked (e.g., /model sonnet), but they do not appear in the /model command's interactive model list.

Current Behavior

Models are configured globally via environment variables in ~/.claude/settings.json:

``json { "env": { "ANTHROPIC_MODEL": "arn:aws:bedrock:us-west-2:...:application-inference-profile/rrjhxbsk14o0", "ANTHROPIC_DEFAULT_SONNET_MODEL": "arn:aws:bedrock:us-west-2:...:application-inference-profile/rrjhxbsk14o0", "ANTHROPIC_DEFAULT_OPUS_MODEL": "arn:aws:bedrock:us-west-2:...:application-inference-profile/5ikipd8fzffx", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "arn:aws:bedrock:us-west-2:...:application-inference-profile/4b25vfl56msg" } }``

Running /model sonnet, /model opus, and /model haiku successfully switches to these models
However, running /model (without arguments) to list available models does not show these custom models

Expected Behavior

The /model command should discover and display custom models defined through environment variables or the settings file, allowing users to see all available models including their custom Bedrock inference profiles.

Steps to Reproduce

Define custom models via environment variables in ~/.claude/settings.json
Restart Claude Code
Run /model to view the model list
Notice that custom models are not displayed in the list
Run /model sonnet - successfully switches to the custom model
Run /model opus - successfully switches to the custom model

Environment

Claude Code version: 2.0.22
Platform: macOS
Bedrock inference profiles configured with custom ARNs

Desired Outcome

Custom models should be discoverable in the /model command list so users can see all available options when listing models, not just when they already know the alias to use.

View original on GitHub ↗

5 Comments

github-actions[bot] · 8 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

silva-renan · 7 months ago

This behavior is a real issue for our workflow as users can accidentally switch into the wrong regional models through the selector, even though we’ve configured global models as the standard. In practice this makes it hard to ensure consistency, enforce our global configuration, and avoid accidental use of restricted regional variants.

amanagarwal0505 · 6 months ago

East-rayyy · 5 months ago

If anyone's looking for a solution to this — I built claude-alias-patch which patches Claude Code to dynamically register custom model aliases from ANTHROPIC_DEFAULT_*_MODEL env vars.

It's a single install script — run it locally and it auto-patches your Claude instance. Custom models show up in the /model picker, the Task tool's model parameter, and agent definitions.

After installing, just add your models to ~/.claude/settings.json and restart Claude. No need to re-patch when you add or remove models.

Related: #34821

phdgil · 1 month ago

Confirming this is still happening for Bedrock on Windows.

Environment:

Claude Code 2.1.204
Windows 11
AWS Bedrock bearer-token flow
AWS_REGION=us-east-1

Config:

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "us.anthropic.claude-opus-4-8"
  }
}

What works:

claude -p "reply exactly: ok" --model us.anthropic.claude-sonnet-5
claude -p "reply exactly: ok" --model us.anthropic.claude-opus-4-8

Both return ok, so the Bedrock models are callable and the account/region setup is fine.

What does not work:

/model still does not list Sonnet 5 or Opus 4.8 in the picker.

So this looks like the same discovery/listing bug, not a Bedrock access problem.

One Windows-specific footgun during setup: if ~/.claude/settings.json already has an env object, PowerShell cannot add missing properties with plain $settings.env.NAME = ... when that property does not already exist; Add-Member is required. That's not the root cause here, but it made the Bedrock setup look broken at first.