Advisor/model mismatch (400) silently hidden by fallbackModel — misleading "could not be retried" on Fable 5

Summary

When the advisor is enabled and a fallbackModel is configured, an advisor/model incompatibility error is silently swallowed by the fallback mechanism. The user only sees a misleading "returned an error that could not be retried" message and gets bumped to the fallback model — the real, actionable 400 error is never surfaced.

This makes it look like the primary model (Fable 5) is broken, banned, or flagging the user's prompts, when in fact the only problem is an incompatible advisor model.

Environment

• Claude Code v2.1.170
• Plan: Claude Max
• Primary model: claude-fable-5[1m] (set via model in ~/.claude/settings.json)
• advisorModel: an Opus model (resolves to claude-opus-4-8)
• fallbackModel: ["claude-opus-4-6[1m]"]

The real (hidden) error

Every request — even a trivial hey — fails immediately with:

API Error: 400 tools.10.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'.

The advisor tool injects itself as a tool pinned to the Opus advisor model. The API rejects an Opus advisor when the request model is claude-fable-5, returning a non-retryable 400.

What the user actually sees instead

● Switched to Opus 4.6 (1M context) because Fable 5 returned an error that could not be retried

Because the 400 is non-retryable, Claude Code immediately switches to fallbackModel (Opus 4.6), which works fine — so the session continues on Opus and the user never learns that:

1. The failure was caused by the advisor/model mismatch, not by Fable 5.
2. Fable 5 itself is perfectly healthy.

Steps to reproduce

1. Set "model": "claude-fable-5[1m]", "advisorModel": "opus", and "fallbackModel": ["claude-opus-4-6[1m]"] in ~/.claude/settings.json.
2. Start Claude Code and send any message (e.g. hey).
3. Observe the silent switch to Opus 4.6 with the "could not be retried" message.
4. Remove fallbackModel entirely and repeat → the real 400 ... cannot be used as an advisor ... error is now visible.
5. Alternatively, run /advisor to disable the advisor → Fable 5 works normally with no switch.

Impact

The fallback mechanism hides a non-retryable 400 that the user needs to see. Diagnosis required removing fallbackModel entirely just to surface the underlying error — a confusing, non-obvious debugging path. Users reasonably conclude their model is broken/flagged/banned.

Expected behavior

1. Compatibility: The advisor tool should select an advisor model compatible with the request model (or skip injecting itself) rather than hard-pinning Opus when the primary model is Fable 5.
2. Error visibility: When a request fails with a non-retryable 4xx (as opposed to an overload/5xx), surface the real API error message alongside the fallback notice instead of the generic "returned an error that could not be retried." Silently falling back on a 400 config error masks a problem the user must fix.

Workaround

Disable the advisor (/advisor) or unset advisorModel when using Fable 5 as the primary model.