Advisor tool "unavailable" when main model uses the [1m] (1M-context) suffix

Resolved 💬 1 comment Opened Jul 9, 2026 by dvshrzn Closed Jul 9, 2026

Title: Advisor tool "unavailable" when main model uses the [1m] (1M-context) suffix

Version: Claude Code v2.1.205 (native, darwin-arm64), Anthropic API, Claude Max

Summary
The advisor tool returns "The advisor tool is unavailable. Do not try to use it again." whenever the main model is launched with the [1m] long-context suffix (e.g. --model opus[1m]), even though the same main-model/advisor pair works fine without the suffix.

Repro

  1. claude --model 'opus[1m]' --advisor fable → in-session, any advisor tool call → "advisor tool is unavailable".
  2. claude --model opus --advisor fable (identical otherwise) → advisor works: "Advising using Fable 5 ✔".

Only difference is the [1m] suffix on the main model.

Ruled out (verified live)

  • availableModels allowlist: not set anywhere.
  • CLAUDE_CODE_DISABLE_ADVISOR_TOOL, ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_FABLE_MODEL: not set.
  • Advisor model access: claude -p --model claude-fable-5 returns OK (Fable reachable).
  • Pairing validity: per docs, Opus 4.8 accepts Fable as advisor — and it does, once [1m] is dropped.

Likely cause
The docs state the [1m] suffix is stripped before the request is sent, and that "if the main model is a model Claude Code does not recognize, the advisor is not attached." It appears the advisor pairing-validation path runs before the suffix is stripped, so opus[1m] fails the known-model check and the advisor is silently detached → "unavailable".

Expected
The [1m] suffix should be normalized/stripped before advisor pairing validation, so 1M-context main sessions can still use the advisor.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗