/advisor reports success setting Fable 5 as advisor, but advisor() then fails with "unavailable"

Edited to correct the original report: the first version included version/pairing "documented" claims and framing I could not verify against official docs. This version states only what I directly observed.

Summary

/advisor accepts and confirms setting Fable 5 (claude-fable-5) as the advisor and prints Advisor set to Fable 5, but the very next advisor() tool call fails with:

The advisor tool is unavailable. Do not try to use it again.

So the command reports success, but the tool then fails at call time with a non-actionable message that also instructs the model to stop using the tool for the rest of the session.

Environment

• Claude Code v2.1.207
• OS: Windows 11

What I actually observed

Each row is a real advisor() invocation and its literal result:

| Main model | Advisor | advisor() result |
|---|---|---|
| Fable 5 | Fable 5 | The advisor tool is unavailable. Do not try to use it again. |
| Opus 4.8 | Fable 5 | The advisor tool is unavailable. Do not try to use it again. |
| Opus 4.8 | Opus 4.8 | works — returns a normal advisor response |

Common factor in the two failures: Fable 5 selected as the advisor. With both main and advisor = Opus 4.8, the tool works.

(I did not test Main = Fable 5 / Advisor = Opus, so I can't report on that combination.)

Expected

Either:

• /advisor validates availability at selection time and refuses/warns if the chosen model can't be used as advisor for this account, instead of reporting success; or
• the advisor() failure returns an actionable reason (which entitlement/version/config is missing) instead of a generic unavailable that tells the model to give up.

Note

I don't have verified documentation on the exact gating rules for Fable 5 as advisor, so I'm not asserting a root cause — only the observed behavior above: /advisor reports success for a Fable 5 advisor selection that then fails at call time.