Advisor tool returns "unavailable" on claude-fable-5 whenever transcript exceeds ~100K tokens

Confirming repro. Claude Code 2.1.173, macOS (darwin 25.5.0, arm64), main model claude-fable-5, "advisorModel": "fable" in settings.json.

advisor() called in an interactive session on a project with a large baseline context (big CLAUDE.md + auto-memory + several MCP servers — well past 100K before the first user message) returned The advisor tool is unavailable. Do not try to use it again. / UI Advisor unavailable (unavailable). User-visible effect: the red "Advisor unavailable" line appears in essentially every session on this project, since Fable 5 is prompted to consult the advisor at start/finish of any substantive task and the context is always above the apparent threshold.

Consistent with the ~100K-token cutoff described here; also matches the latching behavior in #67411 (subsequent calls in the session short-circuit).

Independent repro on Linux (WSL2), claude-fable-5, Claude Code 2.1.17x, headless -p probes with identical flags — only context size varied: ~256KB and ~512KB of filler read before the advisor() call both return ADVISOR_OK; ~1.2MB of filler returns Advisor unavailable (unavailable). Consistent with the ~100–122K-token boundary you bisected.

One addition worth tracking with this: once the call fails, the client latches the session — every later advisor() call returns "The advisor tool is unavailable. Do not try to use it again." even after /compact brings the transcript well back under the boundary (observed twice; the call visibly attempts and still fails). Filed separately as #67411, since the latch also fires on non-size causes. The flattening of prompt_too_long into a generic "unavailable" is what made this class hard to identify in the first place.

The session-size threshold you've bisected — ~100–122K input tokens — is surprisingly easy to hit in practice, and the gap between Fable-5 and Opus 4.8 behavior at the same context size is the frustrating part. Your bisect confirms it's server-side and specific to Fable-5 as the request model; that needs Anthropic to fix.

On the triggering side though: the reason "any session with a normal system prompt plus a few tool calls crosses the threshold quickly" (as the second commenter also saw, with baseline context past 100K before the first user message) is that CC keeps verbatim tool outputs for every prior turn in the JSONL. Each bash/read/write result goes in in full, turn after turn, and the advisor gets sent that entire history each time it's called.

If you want to keep the transcript size down so the advisor stays reliable longer, we built a tool for exactly this: cozempic prunes session JSONL by stripping verbatim tool outputs from completed older turns — leaving the model's conclusions and summaries intact — which typically cuts JSONL size 2–4x in tool-heavy sessions.

Quick diagnostic: pip install cozempic → cozempic current --diagnose shows a per-message-type token breakdown so you can see exactly what's eating context. The guard daemon (cozempic guard) auto-prunes at a configurable threshold (default 80%, fully configurable) and reloads the session transparently.

Honest limits: this won't lower your baseline — if CLAUDE.md + auto-memory + MCP definitions are already past 100K before turn 1, that overhead is injected at request time, not stored in the JSONL, so pruning can't help there. And it doesn't fix the Fable-5-specific cap, which is the actual bug. But for sessions where the growth is from accumulated tool outputs, staying below the 100K wall is achievable.

Reproduced on 2.1.198, but with a config that isolates the ceiling to fable-as-advisor specifically: main model Opus 4.8 (1M), advisorModel: fable.

Controlled comparison in one session, same transcript (large — full system prompt + a big MCP tool catalog + skills + memory baseline, no user work yet):

• /advisor opus → advisor call succeeds (slow, churns the transcript)
• /advisor fable → advisor call returns unavailable immediately (fast reject, no processing)

Only the advisor model changed. Not entitlement (fable is listed in /model), not session-latch (fable failed instantly right after /advisor fable re-enabled it), not the mechanism (opus works on the identical payload). The fast-reject-vs-slow-churn asymmetry matches the ~100K fable ceiling in this issue — and shows it is the advisor request model that caps, independent of the main model.

Yes, I'm having this exact issue too while the advisor works fine when set to Opus or Sonnet

Adjacent datapoint that may share the same server-side rejection class: we see advisor_tool_result_error: "unavailable" deterministically at tiny context whenever the request contains ToolSearch-loaded deferred tools — advisor succeeds, then one ToolSearch select:WebFetch load (tool never called) makes every subsequent advisor call fail in ~5s, on both claude-fable-5 and claude-opus-4-8 executors on 2.1.200. Filed with a 2×2 repro matrix and srvtoolu_ correlation IDs as #73923.

Separately, our non-ToolSearch failures (success early in a session, unavailable minutes later as the transcript grows; large-deferred-manifest sessions failing from the first call) look consistent with the size threshold bisected here — corroborating this thread rather than a second cause.

same problem with fable-5 as advisor

Still hitting this on 2.1.201 (macOS). My setup: main model claude-opus-4-8[1m], advisorModel: "fable".

One thing to add to the "fails from turn 1" case @kpam29 mentioned: I work in a repo with a big pile of MCP servers, a large skills catalog and auto-memory, and just the baseline system prompt already blows past that ~100K line before I've typed anything. So there's no "works early, breaks later" window for me — every advisor call comes back unavailable from the very first one.

The frustrating part for my case specifically: the usual workaround (point advisorModel at opus) doesn't really help me, because opus is already my default model. The whole reason I aimed the advisor at fable was to get a stronger reviewer than my main model. Falling back to opus just makes the advisor a peer of the model that's already answering, so in practice the feature is dead weight for me right now — the only advisor worth calling (something above my main model) is exactly the one that's capped.

Minor UX thing others already touched on: the bare Advisor unavailable (unavailable) gives no hint it's about transcript size + advisor model. Even a prompt_too_long or "advisor transcript exceeds fable's limit" would've saved me a good while.

Same as @sebastian-reolon here—MacOS 26.5.1, claude code 2.1.201, sonnet-5 as main model, failure is not “works early, breaks later”—it breaks immediately. I can call a fable agent, which performs essentially the same function, but it doesn’t work automatically as an advisor, which is annoying.

Same issue. no way to get fable as advisor (Max 5 user). Fable works fine when using only that but never, never advised opus when requested:

Ho un quadro completo. La linea è una riga flex di rettangoli (24px), raggruppati a cinquine (space-after) e con le prime 5 di ogni decina più corte (shorter). Nel sum-game il firstOperand è colorato, il bimbo clicca sul risultato; le domande sono sia addizioni che sottrazioni.

Prima di scrivere codice consulto l'advisor sull'architettura, poi verifico con te un paio di scelte progettuali.

● Advising using Fable 5
Advisor unavailable (unavailable)

particularly irritating considering that tomorrow id the deadline to test it.

same issue on windows

● Advising using Fable 5
Advisor unavailable (unavailable)

Adding a clean within-session data point that directly supports the context-size theory in this thread (and the two comments here from @sebastian-reolon / @mdgld about failing from turn 1 on heavy setups).

Setup: Claude Code v2.1.204, main model Sonnet 5, advisorModel: fable, no other config changes between the two calls below — same session throughout, same repo/workspace context (CLAUDE.md + several rule files loaded).

1. Switched advisor to Fable 5 immediately after running /compact (small transcript). First advisor() call succeeded — normal review response, no error.
2. Later in the same session, after several large file reads and tool outputs had accumulated in context (no /compact, no model/config change), called advisor() again. It failed: "The advisor tool is unavailable. Do not try to use it again." — and per the sticky-latch behavior described in #67411/#73128, it's stayed off for the rest of the session since.

Nothing else changed between the two calls except context size. This is consistent with your ~100K-token threshold theory and inconsistent with a pure "safety classifier flags this repo's content" explanation (same repo content was present both times) — the trigger tracks context size at call time, not a one-time content trip.

Same problem even for Opus as advisor.

Seen on Claude Code 2.1.205 (Windows 11), main model Sonnet 5.

In a long-running session (heavy multi-step tool use before the call; I did not capture a transcript token count), a single advisor() call returned exactly:

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

One warning: /advisor fable was run in this session only after that failed call, and I have not retried since — so I cannot confirm the failing call was bound to Fable rather than the session's prior or default advisor binding.

Possibly useful for triage:

• A Windows data point (most reports in this thread are macOS/Linux; I see one earlier Windows report).
• Occurs on 2.1.205, newer than any version mentioned in this thread so far.

I can reproduce this deterministically on 2.1.205 (macOS arm64, first-party Max OAuth), and controlled A/B testing shows the trigger is not transcript token count and not the main/request model — it is:

advisor model = fable + any tool_use/tool_result block in the conversation → advisor_tool_result_error / error_code: "unavailable".

Evidence matrix (fresh claude -p sessions unless noted)

| Main model | Advisor | Tool calls before advisor | Context size | Result |
|---|---|---|---|---|
| sonnet | sonnet | none | ~50K | ✅ advice returned |
| sonnet | fable | none | ~50K | ✅ |
| opus | fable | none | ~50K | ✅ |
| fable | fable | none | ~50K | ✅ |
| fable | fable | none, padded prompt | ~115K and ~150K | ✅ ← contradicts the ~100K-threshold theory |
| fable | fable | 1× Read (text file) | ~52K | ❌ unavailable ← well under 100K |
| fable | fable | 1× Read (small PNG / large PNG) | ~52K | ❌ |
| fable | fable | 1× Bash echo hello | ~52K | ❌ |
| opus | fable | Bash + Read | ~52K | ❌ ← not fable-main-specific |
| sonnet | fable | Bash + Read | ~52K | ❌ |
| sonnet | sonnet | Bash echo hello | ~52K | ✅ ← non-fable advisors unaffected |
| sonnet | opus | Bash + Read | ~52K | ✅ |

Single-session repro (same session, ~2K tokens apart): advisor call #1 before any tool use succeeds; after one Read, advisor call #2 fails with unavailable:

claude -p --model fable --advisor fable "Do these steps in exact order: (1) Call the advisor tool. (2) Use the Read tool to read /tmp/anyfile.txt. (3) Call the advisor tool a second time. (4) Report verbatim what each advisor call returned, labeled FIRST: and SECOND:."

Why this matters more than the title suggests

• Long sessions always contain tool calls, so "fails above ~100K tokens" was the visible correlate — but padding a tool-free fable:fable session to ~150K tokens succeeds, and a ~52K session with one echo hello fails. Tool blocks, not size, are the discriminating variable.
• Because the advisor-rank check is enforced server-side (400: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5' — CLAUDE_CODE_ENABLE_EXPERIMENTAL_ADVISOR_TOOL=1 does not bypass it), a Fable 5 main-model session currently has no functioning advisor configuration at all: fable advisor hits this bug after the first tool call, and every other advisor is rejected by rank.
• Per #67411, the first failure then latches the advisor off for the whole session, so in practice Fable 5 users see Advisor unavailable (unavailable) on every session.

Workarounds (verified): advisorModel: "opus" — silently skipped on fable-main sessions (no error spam), fully functional on opus/sonnet-main sessions; or CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1 to remove the tool entirely.

When TF is this going to be fixed? Fable is f'n expensive and I'd like to leverage it as my Opus' Advisor.

Their docs say that should work, but I'm tired of seeing "The advisor tool is unavailable this session, so I'll rely on the evidence gathered" by my Opus agent(s).

somebody please fix this

Tool use matrics from @AliAltivate correlates with my observations. Fable advisor stops working after a few tool calls even on a smaller ~30K sessions.

Reproduced consistently on macOS (v2.1.197–2.1.204, subscription OAuth), with some additional data points that may help isolate the cause:

• Executor claude-opus-4-8 + advisor fable: succeeds around 70K tokens (both headless CLI and desktop app, fresh session), but fails on the first call in sessions whose starting context is already ~105K+ (desktop app with MCP tool definitions loaded). Same day, same machine, same surface — only context size differs.
• Boundary observed across multiple runs on different days: ~70–86K success / ~105–111K failure (context measured as input + cache_read + cache_creation at the advisor call).
• A/B with only the advisor model changed, same session at ~119K: --advisor fable fails, --advisor opus succeeds. So the limit appears specific to Fable as the advisor, not the executor, the surface, or pairing validation.
• Also reproduces with executor claude-fable-5 (advisor fable, the only accepted pairing): the first advisor call fails in any real-work desktop session, since typical starting context there already exceeds the threshold.
• The client shows the generic "The advisor tool is unavailable. Do not try to use it again." — same message as #66784; that issue's pairing (Opus 4.8 main + fable advisor) succeeds below ~70K in our tests, so it looks like this same threshold bug rather than an unsupported pairing.

The docs list no such limit for a Fable advisor, and the failure surfaces as a generic unavailable rather than prompt_too_long.

Having the same issue. Big bummer as this is a very useful tool if it worked!

I also same error .

Instead, add the advisor policy to CLAUDE.md as follows:

Executor = Sonnet. For judgment reviews, use Agent(model="fable") —
pass the relevant content/document explicitly in the prompt since
Agent does not share conversation history.

Controlled 2×2 on 2.1.209 — the trigger appears to be any prior tool_use block, not model or token count

Ran fresh headless claude -p one-shot probes, one variable per probe, on Claude Code 2.1.209 (macOS); probes run 2026-07-14. Each probe's prompt asks the agent to call the advisor tool exactly once and report the outcome verbatim.

| Probe | Session context | Request model | tool_use before advisor call | Result |
|---|---|---|---|---|
| P1 | minimal (empty dir, no MCP) | claude-opus-4-8 | none | works |
| P2 | minimal | claude-fable-5 | none | works |
| P3 | large project (MCP servers + plugins loaded) | claude-opus-4-8 | none (advisor was first tool call) | works |
| P4 | minimal | claude-fable-5 | one Read (small text file) | unavailable |
| P5 | minimal | claude-opus-4-8 | one Read (same file) | unavailable |

Also reproduced interactively: a Fable-5 session failed after ordinary Reads at a transcript far below 100K, and a Sonnet-5 subagent with many prior tool calls failed identically (anecdotal, uncontrolled).

Observations:

• The failure is model-independent here: P5 fails on Opus 4.8 with a single Read at a tiny transcript. Reconciling with the earlier data in this thread — including the OP's June probes, where Fable sessions with Reads succeeded at ~40K/75K, so tool_use did not then trigger the failure — the primary explanation is a server-side change between June and these 2026-07-14 probes (the trigger condition has shifted, not merely gone unnoticed); secondarily, some earlier successes such as "Opus works even at ~296K" may reflect tool-free sessions.
• Token count doesn't discriminate: all failures were at tiny transcripts, and the tool-free successes include a large-context session (P3).
• This may subsume #73923: a ToolSearch deferred-tool load is itself a tool_use, so "fails after loading a deferred tool" looks like a special case of "fails after any tool_use". ENABLE_TOOL_SEARCH=false wouldn't help — ordinary Reads trigger it too.
• The error latches per session ("The advisor tool is unavailable. Do not try to use it again."), consistent with #67411.

Local law across all probes: the advisor fails iff the transcript contains any prior tool_use block (2.1.209).

Independent replication of @eqmike67's tool_use finding, plus one new within-session data point (v2.1.204, macOS arm64, subscription OAuth; fresh headless claude -p probes, executor claude-opus-4-8 + --advisor fable, probes run 2026-07-15):

• A (advisor as first tool call): works — ~70.2K tokens at the call, advice received.
• B (one Read of a small text file, then advisor): advisor_tool_result_error: "unavailable" — ~70.3K tokens. Near-identical context size; the single prior Read flipped the outcome, matching the "any prior tool_use" law.
• C (new): advisor → Read → advisor, same session: first call succeeds, second call after the Read returns unavailable. Event sequence verbatim: advisor OK → Read → advisor_tool_result_error: "unavailable".

C rules out "call the advisor early" as a workaround: the first pre-tool call works, but any later consultation — the tool's actual purpose (mid-task guidance after gathering context) — fails. This also matches our earlier data in this thread reinterpreted: our 2026-07-12 "succeeds light / fails heavy" pattern was confounded, since every success was an advisor-first call and every failure followed tool use. On current behavior, token count doesn't discriminate; prior tool_use does.

Update on v2.1.210 (released 2026-07-14): Anthropic has acknowledged this in the release notes, but it's a client-side mitigation, not a fix to the underlying trigger discussed in this thread.

The v2.1.210 changelog's only relevant line: "Fable temporarily shows as unavailable in the advisor picker while a server-side issue causing Fable advisor failures is fixed." That's the first Anthropic acknowledgment I've seen across any of the ~27 issues tracking this family of bugs.

Confirmed live on v2.1.210 just now — /advisor picker output:

   Advisor (experimental)
     1. Fable 5 (temporarily unavailable)
   ❯ 2. Opus 4.8 ✔
     3. Sonnet 5
     4. No advisor

Fable is no longer selectable at all, so the tool_use-triggered failure @eqmike67 and @kangj21 characterized above can no longer be hit — but per Anthropic's own wording, the server-side cause is still being worked on, not shipped yet. So: the picker-level symptom (users hitting the generic "unavailable" error mid-session) is gone, but the underlying bug this issue tracks is still open. Worth knowing before assuming this is resolved from the release notes alone.