Add Opus 5 (1M) to the curated Claude Code model list

[SawyerHood]

Summary

• add Opus 5 (1M) (claude-opus-5[1m]) to CLAUDE_CODE_ACTIVE_CATALOG and point DEFAULT_CLAUDE_CODE_MODEL at it
• relabel the selected-only opus[1m] alias as current and give it the xhigh-capable effort ladder, since it now resolves to Opus 5
• keep Opus 4.8 (1M) as an explicit curated row

Ground truth

Probed the installed Claude Code (2.1.219) via the SDK's initializationResult().models rather than assuming the id shape. Opus 5 is advertised only in 1M form, with the full low→max ladder:

value	resolvedModel	displayName
default	claude-opus-5[1m]	Default (recommended)
opus[1m]	claude-opus-5[1m]	Opus (1M context)
claude-fable-5[1m]	claude-fable-5	Fable
sonnet	claude-sonnet-5	Sonnet
haiku	claude-haiku-4-5-20251001	Haiku

claude-opus-4-8[1m] is no longer advertised at all.

Why the default moves

Claude Code's own default row already resolves to claude-opus-5[1m], and markDefaultModel prefers the discovered default. So once the curated row exists, a successful probe marks Opus 5 as default regardless of BB's constant. Leaving DEFAULT_CLAUDE_CODE_MODEL on Opus 4.8 would only desync the preloaded/probe-failure list from the probe result, making the picker's default visibly jump from 4.8 to Opus 5 once discovery lands.

Opus 4.8 (1M) stays in the catalog rather than moving to selected-only: the curated list is deliberately offered unfiltered, so accounts that can still run it keep a labelled row.

The opus[1m] alias fix

CLAUDE_CODE_SELECTED_ONLY_CATALOG labelled opus[1m] "Opus Alias (1M, Legacy)" with OPUS_4_6_REASONING_EFFORTS, which omits xhigh and ultracode. That alias now resolves to Opus 5, so a user with a stored opus[1m] selection was being offered a strictly narrower effort ladder than the model supports. Relabelled "Current" with CLAUDE_XHIGH_CAPABLE_REASONING_EFFORTS, matching the sibling opus entry and the probe's reported supportedEffortLevels.

Verification

Fed the real probe output through buildClaudeCodeModels and the strict parseAvailableModelList the adapter runs:

  claude-fable-5      — Fable 5        [low,medium,high,xhigh,ultracode,max] default=high
* claude-opus-5[1m]   — Opus 5 (1M)    [low,medium,high,xhigh,ultracode,max] default=high
  claude-opus-4-8[1m] — Opus 4.8 (1M)  [low,medium,high,xhigh,ultracode,max] default=high
  claude-opus-4-7[1m] — Opus 4.7 (1M)  [low,medium,high,xhigh,ultracode,max] default=medium
  claude-sonnet-5     — Sonnet 5       [low,medium,high,xhigh,ultracode,max] default=medium
  claude-haiku-4-5-20251001 / claude-horchata-eap[1m]  (discovered passthrough)
selected-only: opus[1m], sonnet, haiku

Tests: @bb/agent-providers, @bb/agent-runtime (799), @bb/app (2079), @bb/server (1254) pass; typecheck clean on all four. apps/server/test/internal/internal-skill-trees.test.ts fails identically on a stashed clean tree — pre-existing on main, unrelated to this change.

Protocol version

Not bumped. This is catalog data only: no field shapes, requiredness, or provider.list_models semantics change, so a previously shipped daemon stays wire-compatible. An older daemon simply returns a probe list without the curated Opus 5 label, which the server's own fallback already supplies.

🤖 Generated with Claude Code