[BUG] Advisor always "unavailable" with Fable 5 advisor (Opus 4.8 main) across all sessions (v2.1.198)

Same thing

also got the same

🙏 https://x.com/JohnEggz/status/2073090659255525473?s=20

Same

<img width="573" height="285" alt="Image" src="https://github.com/user-attachments/assets/a1872006-ef3e-4f26-821d-990f1216557e" />

Right now, my workaround is just launching a Fable 5 agent. Not ideal since seamless handoff is preferred, but it works. Does anyone know if the advisor mechanism actually saves on Fable 5 tokens, considering how differently they run?

-- Same

-- Same

aUpdate: this is context-size dependent — reproduced live within a single session (Fable 5 advisor)

Correction / refinement of my original report. I first wrote that the Fable 5 advisor fails deterministically regardless of transcript size, even in fresh short sessions. On re-testing today the picture is different: it works at small context and only starts failing once the context grows past a threshold — matching the behavior in #67609.

Reproduced inside one continuous session (advisor = Fable 5, main model = Opus 4.8 [1m], Windows 11, PowerShell, Anthropic subscription billing):

| Point in session | Context size | Advisor (Fable 5) |
|---|---|---|
| First call, start of session | small (~a few K of transcript) | ✅ worked — returned a correct answer that even quoted session-specific details |
| Later call, same session | grown | ❌ The advisor tool is unavailable. Do not try to use it again. |

Nothing changed between the two calls except the accumulated context (a handful of web searches / fetches / tool calls in between). The advisor stayed Fable 5 the whole time — I did not switch models.

Measured context at the failing call: the session transcript file was ~268 KB ≈ ~67K tokens of conversation (measured, chars/4), plus the (large) Claude Code system prompt on top — putting the total in the ~100–130K range, i.e. right around the ~100K threshold reported in #67609.

Error (verbatim):

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

Config note: my settings.json has advisorModel: "opus", yet the runtime advisor was actually Fable 5 (Fable 5 promo active through July 7). So the effective advisor model can differ from what settings.json states — worth flagging for repro.

Takeaway: the generic "unavailable" is masking a context-size limit specific to the Fable 5 advisor — not a hard "no access to Fable 5." Same root cause as #67609. The error should surface the real reason, e.g. "advisor transcript exceeds Fable 5 limit (~100K)" instead of a bare "unavailable."

_Env: Claude Code v2.1.198, Windows 11, PowerShell, Anthropic API/subscription (not Bedrock/Vertex/Foundry)._

Most likely a Fable 5 safety filter, so not a bug, but could be better explained:

<img width="977" height="567" alt="Image" src="https://github.com/user-attachments/assets/e7c51041-6f21-442d-b15a-3d23b48bdb27" />

Dont think it' a safety feature, it happens for nearly any context

-- Same

Same,Mac OS

-- Same

Advising using Fable 5
Advisor unavailable (unavailable)
Same

● Advising using Fable 5
Advisor unavailable (unavailable)

Same

Advising using Fable 5
Advisor unavailable (unavailable)

same

Anthropic tweeted recommending Fable as an advisor, while not fixing this bug: https://x.com/ClaudeDevs/status/2074606058128224365?s=20

What the heck is this?

Same issue

<img width="702" height="110" alt="Image" src="https://github.com/user-attachments/assets/32f167b2-0011-4421-8b70-b9e4bce9c105" />

"can we get a revenue:positive label added to this one?

thanks, dario"

-- Same

Please stop spamming "same" in the thread.
Only post if you have something relevant to say as it has been established that this isn't functioning correctly.

Datapoint on the open question (entitlement vs bug): on my Max account, Fable 5 works as the main session model, so account-level Fable access exists - yet with advisorModel: fable the first advisor call returns the generic "unavailable" in every session (Opus 4.8 main on high, v2.1.202 desktop and v2.1.204 CLI, macOS, fresh small-transcript sessions, deterministic). /advisor opus restores a working advisor in the same setup. So this does not look like missing Fable access, unless Fable-as-advisor is gated separately from Fable-as-main.

Reproduced with a similar setup (macOS, Opus main + Fable 5 advisor). First advisor() call in a fresh session (small transcript, well under 100K tokens) returns the generic "unavailable" immediately. Confirmed /model fable works fine in the same session right after — the account/session clearly has access to the Fable model itself, which argues against "missing Fable 5 access" and toward this being a real bug in the advisor-specific model resolution/pairing check.

It seems to be working on a new session now, but it's still unavailable for an old session.

macOS, Sonnet main + Fable 5 advisor, fresh context and session - shows the "Advisor unavailable (unavailable)" error

Same issue here...

same

Same setup, still reproducing on the latest published CLI.

Environment

• Claude Code CLI v2.1.204 (2.1.205 is out now; will retest and report back)
• macOS (Darwin 25.6)
• Main model: Opus 4.8, effort xhigh
• ~/.claude/settings.json: "advisorModel": "fable" (correct per the docs — Fable is a listed advisor for an Opus 4.7+ main)

Symptom — the first advisor() call returns, deterministically:

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

The "Do not try to use it again" wording is notable: the tool latches off for the rest of the session after that first failure, so there is no recovery within the session.

Diagnostics that point at an advisor-specific resolution bug, not missing access

• Fable 5 works fine as the main model on the same account (/model fable), so account-level Fable access clearly exists — it only fails as the advisor.
• /advisor opus immediately restores a working advisor in the identical setup. So the Opus executor path resolves; the Fable-as-advisor path does not. This lines up with the other reports here (Opus/Sonnet main + Fable advisor → unavailable, while Fable-as-main is fine), suggesting Fable-as-advisor may be gated or resolved separately from Fable-as-main.

Triage note (to keep this distinct from #67609 and #73923) — the specific session where I captured the error was large and had ToolSearch-loaded deferred tools present, so that one instance could overlap with #67609 (>~100K transcript) or #73923 (deferred tools). But the reports above show the same failure in fresh, small, tool-free sessions with the same pairing, so the Opus-main + Fable-advisor case looks like a genuine advisor-specific model-resolution issue independent of transcript size or deferred tools.

Happy to provide a minimal fresh-session repro and a 2.1.205 retest if that helps narrow it down.

Still reproducing on the latest published CLI (v2.1.205), Opus 4.8 main + Fable 5 advisor. Captured live just now in a single session, both states observed back-to-back:

• With "advisorModel": "opus", an advisor() call returned a full, normal advisory response — the Opus-advisor path resolves fine.
• Switched to Fable mid-session via /advisor fable (CLI confirmed "Advisor set to Fable 5"), then called advisor() once. It returned, deterministically, on the first call:

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

So on the same account, same session, same CLI build: Opus-as-advisor works, Fable-5-as-advisor fails immediately. Fable 5 also works fine as the main model on this account (/model fable), so account-level Fable access clearly exists — it only fails in the advisor role. The "Do not try to use it again" wording latches the tool off for the rest of the session; there is no recovery within that session.

Environment

• Claude Code CLI v2.1.205
• macOS (Darwin 25.6)
• Main model: Opus 4.8
• ~/.claude/settings.json: "advisorModel": "fable" at repro time (documented as a supported advisor for an Opus 4.7+ main)

Happy to provide a minimal fresh-session repro if that helps narrow it down.

Still reproducing a day on, same Max account as my note above. Today, 9 Jul, CLI v2.1.204 (macOS), Opus 4.8 main with advisorModel: fable: the first advisor() call in a working session failed immediately with the verbatim The advisor tool is unavailable. Do not try to use it again., and stayed latched off for the rest of the session.

The bit worth adding to my earlier datapoint: this was the first call, on a modest transcript well under the ~100K in #67609 (a handful of file reads, no ToolSearch-loaded deferred tools in play). So on this account it's failing below the size threshold too, not only above it. /advisor opus still restores a working advisor in the same setup, and Fable 5 still works fine as the main model, so it stays Fable-as-advisor specifically, on an account that plainly has Fable access.

A week of reports in, the message is still the generic "unavailable" with no reason given. Even just surfacing which case it is (entitlement, unsupported pairing, or the >100K path) would let people stop guessing.

Same Problem. Even with a new session, "Advisor unavailable" with Fable as advisor. Others in my team have the same problem.

still an issue in 2.1.205. i tried the toolsearch fix in https://github.com/anthropics/claude-code/issues/73923 but still an issue.

Still reproduces on v2.1.205 (macOS), and #73923 looks like the mechanism

Confirming this on a newer build than any report here — including #73923, which was closed as "not planned."

Environment

• Claude Code: 2.1.205
• Platform: macOS (Darwin 25.5)
• Main model: Opus 4.8 (claude-opus-4-8)
• Advisor model: Fable 5 — "advisorModel": "fable" in ~/.claude/settings.json
• Billing: subscription
• No availableModels allowlist set anywhere (user / project / managed settings) — so the documented allowlist-blocking path is ruled out for this repro.

Symptom
First advisor() call in the session returns the generic, latching string:

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

/advisor accepts and confirms the Fable 5 selection; switching the advisor to Opus in the same setup behaves differently. The Opus-4.8-main + Fable-advisor pairing is listed as valid in the docs.

Likely mechanism — this is #73923, not a Fable entitlement issue
The failing sessions are ones where deferred tools were loaded via ToolSearch before the advisor call (stock Claude Code does this routinely for built-ins like WebFetch). That matches #73923's deterministic repro exactly, and #73923 shows the failure hits both claude-fable-5 and claude-opus-4-8 executors — i.e. it's the deferred-tool interaction, not Fable access. That also explains the "intermittent / not every session" reports here: sessions that never touch ToolSearch get a working advisor; once a deferred tool is loaded, it dies.

Given #73923 is closed as "not planned" but still reproduces on 2.1.205 with the documented-valid Fable+Opus pairing, could this be re-triaged? At minimum, the two asks from #67411 would make it diagnosable:

1. surface the real error_code (too_many_requests / overloaded / prompt_too_long / unavailable) instead of flattening to one string, and
2. don't latch the tool off for the whole session on a transient/first failure.

Same here. The Fable 5 advisor fails on the very first call for me too, in every session — I've never once gotten it to succeed. Switching the advisor to Opus works fine in the same setup, which matches exactly what you're describing.

Question for everyone hitting this: is it a 100% failure for you as well, with the advisor never working? Or does it succeed occasionally / intermittently? Trying to narrow down whether this is a hard "no Fable 5 access" block or something flaky.

How are they posting articles about having Sonnet + Fable advisor is 92% of base fable performance when it doesnt even work..

Same here, doesn't work with fable 5 as advisor.

Decided to use Fable 5 directly for the whole session, but my my, can't afford to spend my weekly limits like 5hour limits.

same issue

same issue, happening on empty context too. So not context related

opps，same issue。

same issue for days in desktop and terminal

I have also the same issue and it's been a couple of days I can not resolve this issue for myself

I also have the same issue every single time it tries to use the Advisor with Fable

Same here. Always fails.

same here, still failing

same here still failing

same here

⏺ Advising using Fable 5
Advisor unavailable (unavailable)

same same

same here

same here

Facing the same issue

it looks like its a bug in the ui when setting the advisor name. try updating your settings.json yourself (or setting via cmdline flag) to either "fable" or "claude-fable-5". "fable5" will fail when you try to use.

claude-fable-5

Did such a trick work for you?
@ahringer

> claude-fable-5 Did such a trick work for you? @ahringer

yes works using: "advisorModel": "fable",

❯ ask advisor: what is 1+1

I'll call the advisor as you asked.

● Advising using Fable 5
✔ Advisor has reviewed the conversation and will apply the feedback

The advisor says 1 + 1 = 2.

✻ Cogitated for 18s

it looks like its a bug in the ui when setting the advisor name. try updating your settings.json yourself (or setting via cmdline flag) to either "fable" or "claude-fable-5". "fable5" will fail when you try to use.

Doesn't work for me. Tried "fable" and "claude-fable-5".

> it looks like its a bug in the ui when setting the advisor name. try updating your settings.json yourself (or setting via cmdline flag) to either "fable" or "claude-fable-5". "fable5" will fail when you try to use. Doesn't work for me. Tried "fable" and "claude-fable-5".

did you try modifying in settings.json? i didnt test using cmd line argument.

> > claude-fable-5 > > > Did such a trick work for you? @ahringer yes works using: "advisorModel": "fable", ❯ ask advisor: what is 1+1 I'll call the advisor as you asked. ● Advising using Fable 5 ✔ Advisor has reviewed the conversation and will apply the feedback The advisor says 1 + 1 = 2. ✻ Cogitated for 18s

This worked for me.

NOTE: You need to exit and start a new session for the modification to take affect.

"advisorModel": "fable", 2.1.197 (Claude Code) - latest available in brew atm OS: macOs 26.5.2 (25F84)

❯ ask advisor: what is 1+1

⏺ Advising using Fable 5
Advisor unavailable (unavailable)

The advisor tool is unavailable (it errored again and instructs not to retry).
But I can answer directly: 1 + 1 = 2. 🙂

NOTE: You need to exit and start a new session for the modification to take affect.

That was on the new clean session started as Opus 4.8 😢

Env: Claude Code v2.1.198, Windows 11, PowerShell, main model Opus 4.8 (claude-opus-4-8[1m]), "advisorModel" set to the working string form (fable / claude-fable-5, not fable5), Anthropic subscription billing (not Bedrock/Vertex/Foundry).

Repro — same session, advisor stayed Fable 5 throughout, nothing changed but accumulated context:

| Point in session | Approx. total context | Advisor (Fable 5) |
|---|---|---|
| First call, start of session | small (a few K) | ✅ worked — returned 1 + 1 = 2, even referenced session-specific details |
| Second call, still small | small–moderate | ✅ worked — same correct answer |
| After I deliberately inflated context by ~96K tokens (reading a synthetic filler file) | ~150K+ total (system prompt + tools + transcript + filler) | ❌ The advisor tool is unavailable. Do not try to use it again. |

The advisor answered reliably twice while the transcript was small, then went unavailable immediately after the ~96K-token jump, and latched off for the rest of the session (the "Do not try to use it again" wording is literal — no recovery within the session).

Caveats, to keep this honest:

• Single failure data point. The hard "do not use again" latch means I couldn't bisect to pin the exact threshold, so I can't fully separate a strict context-size ceiling from a per-session call cap. Both are consistent with what I saw, but the fact that it worked twice at small context and only died after the big jump points at size.
• Plausible mechanism: the advisor forwards the entire transcript to the Fable executor on every call, so the forwarded payload grows with the session — a size ceiling on the advisor side would manifest exactly like this (fine early, dead after a big context addition).
• My config used the working fable string, so this is not the fable5-vs-fable settings bug some folks just found further up — it's the size path.

i have the same issue

Started working for me in 2.1.206+

as of today same here

same issue. can confirm it works when context is a still small. if failes once it grew a bit.

<img width="1530" height="1002" alt="Image" src="https://github.com/user-attachments/assets/e41606d2-ce8e-4154-a125-c96704674476" />

Ubuntu
CC Version: 2.1.207

On 2.1.207 and updated settings.json but still the same issue. Opus 4.8 [1M] with fable advisor always returns advisor unavailable

+1

Any timeline for the fix? Or if there is a workaround?!

Confirming this reproduces on Claude Code v2.1.207, Windows 11, advisorModel: "fable", Opus 4.8 main. First advisor() call in the session returned the generic unavailable, latched off for the rest of the session.

One data point possibly linking this to #73923: my session had several ToolSearch-loaded deferred tools (WebFetch, subagent tools, etc.) already present before the failing advisor call — matches the deferred-tool trigger described there, even though #73923 is closed. Given the last comment on #73923 ("tried this and still get unavailable"), the ToolSearch trigger doesn't look fully resolved.

Workaround confirmed: switching advisorModel to "opus" in settings.json (or /advisor opus) restores normal advisor behavior in the same session/config.

Same here. Main model Opus 4.8, advisor Fable. Would be nice to have it working as long Fable is available.

I wanted to share a deterministic reproduction pattern for this. The advisor 'unavailable' error is triggered as soon as there is at least one tool call in the session transcript. Once a tool is invoked, any subsequent advisor call fails with the 'unavailable' error, and the session gets permanently locked into this state.

However, in a fresh session where no tools have been invoked yet, the advisor works perfectly fine. This behavior occurs 100% of the time as long as the advisor is set to Fable 5, regardless of whether the main model is Sonnet or Opus.

I wanted to share a deterministic reproduction pattern for this. The advisor 'unavailable' error is triggered as soon as there is at least one tool call in the session transcript. Once a tool is invoked, any subsequent advisor call fails with the 'unavailable' error, and the session gets permanently locked into this state.

However, in a fresh session where no tools have been invoked yet, the advisor works perfectly fine. This behavior occurs 100% of the time as long as the advisor is set to Fable 5, regardless of whether the main model is Sonnet or Opus.

I wanted to share a deterministic reproduction pattern for this. The advisor 'unavailable' error is triggered as soon as there is at least one tool call in the session transcript. Once a tool is invoked, any subsequent advisor call fails with the 'unavailable' error, and the session gets permanently locked into this state.

However, in a fresh session where no tools have been invoked yet, the advisor works perfectly fine. This behavior occurs 100% of the time as long as the advisor is set to Fable 5, regardless of whether the main model is Sonnet or Opus.

@ashwin-ant @roy-ant @williamqian12 could you please take a look at this reproduction pattern? It seems to isolate the issue to the presence of tool_use/tool_result blocks in the transcript when using the Fable advisor.

I wanted to share a deterministic reproduction pattern for this. The advisor 'unavailable' error is triggered as soon as there is at least one tool call in the session transcript. Once a tool is invoked, any subsequent advisor call fails with the 'unavailable' error, and the session gets permanently locked into this state.

However, in a fresh session where no tools have been invoked yet, the advisor works perfectly fine. This behavior occurs 100% of the time as long as the advisor is set to Fable 5, regardless of whether the main model is Sonnet or Opus.

@ashwin-ant @roy-ant @williamqian12 could you please take a look at this reproduction pattern? It seems to isolate the issue to the presence of tool_use/tool_result blocks in the transcript when using the Fable advisor.

I wanted to share a deterministic reproduction pattern for this. The advisor 'unavailable' error is triggered as soon as there is at least one tool call in the session transcript. Once a tool is invoked, any subsequent advisor call fails with the 'unavailable' error, and the session gets permanently locked into this state.

However, in a fresh session where no tools have been invoked yet, the advisor works perfectly fine. This behavior occurs 100% of the time as long as the advisor is set to Fable 5, regardless of whether the main model is Sonnet or Opus.

@ashwin-ant @roy-ant @williamqian12 could you please take a look at this reproduction pattern? It seems to isolate the issue to the presence of tool_use/tool_result blocks in the transcript when using the Fable advisor.

same issue, v2.1.207, linux

Claude Code v2.1.207
Exactly the same. I can't remember even one time with an advisor worked.

Reproduced on macOS + v2.1.207 — then recovered mid-session with no config change

• Symptom: every advisor call returned The advisor tool is unavailable. Do not try to use it again. — deterministic, immediate (no timeout), across many calls over one long session.
• Platform: macOS (Darwin 24.6.0) — this issue is labeled platform:windows, so it is not Windows-specific.
• Version: Claude Code v2.1.207 (newer than the reported v2.1.198).
• Config: main model claude-opus-4-8, advisor set to Fable 5 via /advisor fable.
• Failed identically on a >100K-token transcript with the generic message — distinguishes this from #67609.
• Later in the same session, with no config change (advisor still Fable 5), calls began succeeding — 2/2 consecutive. Suggests a transient/server-side availability condition rather than a permanent client-side pairing bug.

I am experiencing this issue as well. Currently, I initiate the conversation with Fable and ask it to assign the task of running Opus as a subagent, which feels a bit unconventional.

I've yet to see this feature work using a Fable advisor.

• Fresh CC session using Opus 4.8 (1M context) with advisor set to Fable = immediate Unavailable (Unavailable).
• Fresh CC session using Sonnet 5 with advisor set to Fable = immediate Unavailable (Unavailable).

Maybe they'll fix this bug the day after they remove Fable from Max plan users.

so much for rust port

Datapoint against the context-size refinement: fails on a near-empty context (Windows, v2.1.209)

The update above refines the report to "context-size dependent". I can't reproduce that dependence — here the Fable 5 advisor failed on a session that had barely started.

Environment:

• Claude Code v2.1.209, Windows 10 Pro (19045)
• Main model: Opus 4.8 [1m]; "advisorModel": "fable" in ~/.claude/settings.json
• CLAUDE_CODE_DISABLE_ADVISOR_TOOL not set
• Background (daemon-spawned) session

Observations, in order:

1. First advisor() call, ~6 tool calls into a fresh session (a few ls/grep results, no large files read — context was a few thousand tokens): The advisor tool is unavailable. Do not try to use it again.
2. Fable 5 itself was live at that moment. A probe subagent launched with model: fable (run_in_background: false) answered normally in ~8s. So this isn't entitlement or a model outage — the account has Fable 5 access (the in-app announcement extends it through July 19) and the model served a request minutes either side of the failing advisor calls.
3. Retried advisor() a few minutes later — identical verbatim error.

So on this machine the failure is not size-gated: it reproduces at near-zero context, with the same main-model/advisor pairing (Opus 4.8 main + Fable 5 advisor) as the original report. That matches the original phrasing ("every session, regardless of transcript size") rather than the refinement.

One more, offered with a caveat:

1. I set "advisorModel": "opus" by editing settings.json directly mid-session (not via /advisor) and called advisor() again — still unavailable. I would not read this as evidence for the sticky-state bug in #75903: a file edit plausibly just isn't hot-reloaded, since the advisor model is likely resolved at session start. Someone testing #75903 should use /advisor mid-session, which is what that issue actually describes.

Do we have solution for this yet?

Confirming on v2.1.209, main model Opus 4.8 [1m], "advisorModel": "fable" (subscription OAuth, first-party Anthropic API). Verbatim failure on the first advisor() call of the session, right after routine orientation (a few Read/Bash tool calls):

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

Adding a cross-context datapoint I haven't seen isolated in this thread: the failure is caller-context- and executor-independent in the strong sense. Across ~10 independent sessions on the same account over a single day, advisor() failed identically on the first call in every one — top-level/orchestrator sessions, Task-tool-spawned subagents, and long-lived background agents alike — spanning Sonnet 5, Fable 5, and Opus 4.8[1m] executors. The single constant is advisorModel: fable; the executor model is irrelevant. Not one successful advisor() invocation across any of them.

This corroborates #76199's "executor-irrelevant, fails after any tool_use, Opus advisor immune" characterization and this issue's "every session, first call" framing — it is specifically not a subagent-provisioning gap.

Switching advisorModel to opus is the only known workaround, but that pins Opus as a deliberately-chosen tier (with the attendant spend) rather than reserving it as a capacity fallback, so it isn't a free fix. The actionable ask remains: either make the Fable advisor actually serve requests, or have the Fable→Opus availability fallback apply to the advisor path the way it applies to the main model — instead of latching the tool off for the whole session with a generic "unavailable / do not try again".

couldn't fix yet ig "Fable temporarily shows as unavailable in the advisor picker while a server-side issue causing Fable advisor failures is fixed" in v2.1.210 lol

couldn't fix yet ig "Fable temporarily shows as unavailable in the advisor picker while a server-side issue causing Fable advisor failures is fixed" in v2.1.210 lol

😄 It's easier to disable as fix a problem