I thought Fable 5 was broken. It was my own config lying to me.

I switched to Fable 5 the day it dropped, and almost immediately Claude Code started quietly kicking me off it. I'd open a session, type something as dumb as hey, and get this:

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

No status code. No stack trace. Nothing I could actually do anything with. So my brain went straight to the scary explanations: my account got flagged, Fable 5 is down, or something in my prompts is tripping a safety filter. I burned a real amount of time on all three before realizing none of them were it.

The part that fooled me

The first thing I tested was whether Fable 5 even worked at all. It did. A one-off call from the terminal was completely fine:

claude -p "say hi" --model claude-fable-5   # works
claude -p "say hi" --model "claude-fable-5[1m]"   # also works

So the model wasn't banned and it wasn't down. It only fell over inside a full interactive session. That narrowed things down, but it also made it weirder.

What kept me confused the whole time was the fallback. Claude Code lets you set a fallbackModel — if your main model throws a non-retryable error, it switches over so you can keep working instead of staring at a dead session. Mine was Opus 4.6, and Opus worked perfectly. Which sounds great, except that's exactly why I couldn't see the bug. The fallback caught the real error, swallowed it, and handed me a polished "couldn't be retried" message instead. The thing I actually needed to read never made it to my screen.

Killing the safety net

So I did the blunt thing: I deleted fallbackModel from my settings entirely. No plan B, nowhere to hide. Next session, the real error finally showed up:

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

And there it was. Nothing to do with Fable 5 being broken at all.

What was actually happening

I had advisorModel set to Opus. The advisor feature rides along on every request as a tool, pinned to whatever model you gave it — in my case claude-opus-4-8. The API won't let you pair an Opus advisor with a Fable 5 request; they have to be compatible. So every single request died on a 400 before it ever ran, and the fallback dutifully covered for it.

Quickest confirmation: I ran /advisor to turn the advisor off, and Fable 5 worked immediately. No switch, no error, nothing.

What I took from it

The annoying lesson here isn't really about models. It's that a fallback that works can hide a bug better than no fallback at all. As long as plan B keeps the session alive, you have no reason to suspect plan A is dead on arrival. The single most useful debugging move I made was removing the safety net so the system was forced to tell me the truth.

The fix itself is boring: if you're running Fable 5 as your main model, either turn the advisor off or drop the Opus advisorModel so the pairing is valid. I also opened an issue on the Claude Code repo asking for two things — that the advisor pick a compatible model on its own, and that a non-retryable 400 like this gets shown to you instead of getting buried under the fallback message. Hiding a config error behind a working fallback is a great way to make people think their model is broken when it isn't.