[Bug]: Claude picker ignores availableModels and ANTHROPIC_DEFAULT_*_MODEL; picking Haiku on Bedrock silently runs Opus

Note

Claude Opus 5.5 responding on behalf of Marcos Rocha

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Configure Claude Code for Amazon Bedrock in ~/.claude/settings.json, using the ANTHROPIC_DEFAULT_* env vars and an availableModels allowlist with Bedrock IDs:

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-west-2",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "global.anthropic.claude-opus-5-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL_NAME": "Opus 5.5 via Bedrock Global (1M context)",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-5-5[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL_NAME": "Sonnet 5.5 via Bedrock Global (1M context)",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.anthropic.claude-haiku-5-5",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL_NAME": "Haiku 5.5 via Bedrock Global"
  },
  "model": "opus",
  "availableModels": [
    "global.anthropic.claude-haiku-5-5",
    "global.anthropic.claude-sonnet-5-5",
    "global.anthropic.claude-opus-5-5"
  ]
}

Add a Claude provider instance in T3 Code that uses ~/.claude (default config dir, no custom models).
In the model picker, select Claude Haiku 5.5 and send a prompt.

Expected behavior

The Claude picker reflects the Claude Code configuration, the same way /model does in the CLI:

Rows map to the configured Bedrock IDs (ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL), labeled with the *_MODEL_NAME / *_MODEL_DESCRIPTION values when set.
Models not in availableModels are not offered.
Selecting Haiku runs global.anthropic.claude-haiku-5-5.

Passing the alias (haiku, sonnet, opus) or the resolved Bedrock ID to Claude Code would also fix the routing. Both work in the CLI (see Evidence).

Actual behavior

The picker shows T3's bundled first-party catalog (claude-opus-5-5, claude-haiku-5-5, ...) and sends that slug to the SDK. Claude Code rejects it because it is not in availableModels, and silently falls back to the default model (Opus). The UI still shows Haiku. No error appears.

T3's provider event log shows the mismatch for every thread where a non-default model was picked:

query.open  options.model = "claude-haiku-5-5"            # sent by T3
system/init model         = "global.anthropic.claude-opus-5-5"  # what Claude Code actually runs

So users pay for Opus while the UI shows Haiku, and there is no way to get Sonnet or Haiku without extra T3-side config.

Same CLI (claude -p --model <x> --output-format json, modelUsage keys) with the settings above:

`--model`	model actually used
`claude-haiku-5-5` (what T3 sends)	`global.anthropic.claude-opus-5-5` (fallback)
`global.anthropic.claude-haiku-5-5`	`global.anthropic.claude-haiku-5-5`
`haiku`	`global.anthropic.claude-haiku-5-5`

Adding claude-haiku-5-5 to availableModels doesn't help either: Claude Code then sends that raw ID to Bedrock and the request fails.

Related, but not duplicates: #23279 (custom modelPicker in settings, fixed) and #13875 (gateway model discovery, fixed). This report is about availableModels and the ANTHROPIC_DEFAULT_*_MODEL env vars, which T3 doesn't read today. From the discussion on #13875, reported models whose ID or alias matches a catalog entry are skipped, so the catalog slug always wins.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Beta) 0.1.2

Environment

macOS 26 (Darwin 25.6.0), Claude Code 2.1.309, Claude provider via Amazon Bedrock (CLAUDE_CODE_USE_BEDROCK=1, global.* inference profiles)

Workaround

Add the Bedrock IDs as customModels on the Claude provider instance in T3 and pick those rows instead of the built-in ones. This duplicates config that already lives in ~/.claude/settings.json.

I'm hitting the same root cause on macOS (T3 Code Beta desktop Version 0.1.5 (6d450a4), Claude Code 2.1.316), but mine shows up as a 403 instead of a silent fallback.

My ~/.claude/settings.json has:

  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1",
    "AWS_PROFILE": "<sso-profile>",
    "ANTHROPIC_MODEL": "global.anthropic.claude-sonnet-5-5",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-5-5",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.anthropic.claude-haiku-5-5"
  }

T3 detects Bedrock auth fine and shows the provider as authenticated. But when I pick Claude Sonnet 5.5, the first turn fails with:

API Error: 403 ... is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource: arn:aws:bedrock:us-east-1::inference-profile/us.anthropic.claude-sonnet-5-5

Our IAM policy only allows the global. inference profile, so the us. one is denied. The CLI works with the same settings.

From reading the bundled server code, T3 resolves the picker selection to the catalog slug (claude-sonnet-5-5) and passes it as the SDK model. That overrides ANTHROPIC_MODEL, and the ANTHROPIC_DEFAULT_*_MODEL
values never get used. Same cause as above.

Workaround that works for me: add the full profile IDs as custom models (Settings > Providers > Claude, or providerInstances.claudeAgent.config.customModels in settings.json) and hide the built-in claude-*-5-5
entries.

For a fix, either of these would cover my case:

Send the alias (sonnet, haiku, opus) so Claude Code resolves it through ANTHROPIC_DEFAULT_*_MODEL.
When CLAUDE_CODE_USE_BEDROCK is set, build the picker from ANTHROPIC_DEFAULT_*_MODEL instead of the bundled catalog, as suggested here.

▎ [!NOTE]
▎ Posted with help from Claude Code (Opus 5.5, model claude-opus-5-5) running T3 Code's t3 triage playbook.

Same root cause on a different backend: a custom Anthropic-compatible gateway (ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN) instead of Bedrock. Here the gateway returns a hard error, not a silent fallback.

Setup

Claude Code settings.json (used as the instance's CLAUDE_CONFIG_DIR) sets ANTHROPIC_BASE_URL to an internal gateway and ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL to aws-gov.claude-{opus,sonnet,haiku}-5-5, with "model": "opus" and availableModels: ["opus","sonnet","haiku"].
The claude CLI (2.1.302) works normally with this config.
T3 Code desktop app, local server v0.1.7, Windows 11 x64.

What happens
Picking Claude Opus 5.5 in T3 and sending a prompt fails right away. T3 sends its bundled slug claude-opus-5-5 (the DEFAULT_MODEL_BY_PROVIDER value in packages/contracts/src/model.ts). The gateway only knows aws-gov.claude-opus-5-5, so it returns:

Failed to authenticate. API Error: 403 The requested model 'claude-opus-5-5' is not available for this API key, or the model name is invalid. Check the models available to you and try again.

The provider event log has "model":"claude-opus-5-5" on the request side. The SDK result is a assistant
message with terminal_reason: "api_error". Tording is misleading: the credentials arevalid, only the model ID is wrong.

Repro

Point Claude Code at any Anthropic-compatrst-party model IDs, throughANTHROPIC_BASE_URL and ANTHROPIC_DEFAULT_*_MODEL.
Add a Claude provider instance in T3 that
Pick any built-in Claude model and send a prompt. You get a 403 "model not available".

Workaround
Add the gateway IDs (aws-gov.claude-opus-5-5 Settings → Providers → Claude → Models, andstart new threads with them. (Pending confirmation that it works on this setup.)

Passing the alias (opus/sonnet/haiku) to the SDK, or resolving through ANTHROPIC_DEFAULT_*_MODEL, would fix both the Bedrock case and the gateway case. #28325 (ddels on configured gateways) would also cover this one.

Navigation Menu

Repository navigation

[Bug]: Claude picker ignores availableModels and ANTHROPIC_DEFAULT_*_MODEL; picking Haiku on Bedrock silently runs Opus #24214

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Claude picker ignores availableModels and ANTHROPIC_DEFAULT_*_MODEL; picking Haiku on Bedrock silently runs Opus #24214

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Workaround

Activity

nicklaw5 commented on Nov 3, 2026

zrjones commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions