Advisor (Fable 5) returns "unavailable" whenever the transcript contains any prior tool call — one Bash(ls) suffices; Opus advisor immune

Independent confirmation — reproduced against the Messages API directly (no Claude Code involved), so this is server-side.

Environment: Claude Max subscription (OAuth), Linux/WSL2, field failures observed on CC 2.1.198–2.1.206.

Minimal A/B, anthropic-beta: advisor-tool-2026-03-01, non-streaming:

{
  "model": "claude-opus-4-8",
  "max_tokens": 4000,
  "messages": [
    {"role": "user", "content": "List the files."},
    {"role": "assistant", "content": [{"type": "tool_use", "id": "toolu_01SyntheticAAAABBBBCCCC01", "name": "Bash", "input": {"command": "ls"}}]},
    {"role": "user", "content": [{"type": "tool_result", "tool_use_id": "toolu_01SyntheticAAAABBBBCCCC01", "content": "file.txt"}]},
    {"role": "user", "content": "Consult the advisor now, then say DONE."}
  ],
  "tools": [
    {"type": "advisor_20260301", "name": "advisor", "model": "claude-fable-5"},
    {"name": "Bash", "description": "Runs a shell command", "input_schema": {"type": "object", "properties": {"command": {"type": "string"}}, "required": ["command"]}}
  ]
}

• advisor.model = claude-fable-5 → advisor_tool_result_error, error_code: "unavailable", returned in ~6–10s
• advisor.model = claude-opus-4-8, same payload → advisor_result (success, 40–240s)
• Executor claude-fable-5 (fable+fable, the only accepted pairing for a Fable main): same failure
• Remove the tool_use/tool_result pair, keep everything else: fable advisor succeeds

Also captured a real CC session request via a local proxy and replayed it directly: same unavailable. Bisecting that 735KB request ruled out: transcript size (400KB of plain text passes), thinking blocks (real signed ones pass), system-role messages inside messages, 213 tools in the array, output_config/effort, context_management, and tool-call content (a Bash reading credentials and a bare ls fail identically). The only necessary and sufficient trigger we found is ≥1 tool_use block in the transcript.

Field data matching the OP's ratio: with advisorModel: fable, 45+ real-session advisor calls since Jul 2 = 0 successes (all unavailable); with advisorModel: opus, 67 successes through Jun 30. Failures in Opus-main sessions started exactly when the setting changed to fable on Jul 1.

Independent confirmation on 2.1.206 (first-party API, subscription auth, macOS arm64), with "model": "claude-fable-5" + "advisorModel": "claude-fable-5" — same deterministic trigger reported here and in #76199.

Headless A/B on one machine, minutes apart, --settings '{"advisorModel":"claude-fable-5"}':

• 3/3 tool-free probes → advisor succeeds (returns the documented advisor_redacted_result)
• Tool-free probe with ~291 KB of stdin context → advisor still succeeds. Large-context success alongside the small-context failures reported here severs the size correlation — relevant to #67609's ~100K-token threshold theory (our failing interactive sessions were 120 KB–1.4 MB, but size isn't the trigger)
• Probe with two trivial Bash calls before the advisor call → advisor_tool_result_error / "unavailable" every time
• The successful probes contained thinking blocks (alwaysThinkingEnabled: true), so extended thinking is ruled out as the trigger too

Field data from the same account: 10/10 advisor successes Jun 27–Jul 7 with advisorModel: "claude-opus-4-8[1m]" (including one very large session), then 8/8 failures across 4 projects Jul 3–10, flipping at exactly the settings change to the fable advisor. One of those 8 failures had an opus main model with the fable advisor — consistent with #76199's executor-irrelevance finding.

For backend correlation: failing server_tool_use id srvtoolu_01ARJKZTCJkcK4RuqR7TqDzo at 2026-07-10T15:23Z → {"type": "advisor_tool_result_error", "error_code": "unavailable"}.

Also reproduced the session-latch behavior tracked in #75903: after the first failure the client reports "The advisor tool is unavailable. Do not try to use it again." and no advisor call is possible for the remainder of the session.

🤖 Generated with Claude Code

Independent confirmation, 2026-07-10, matching the matrix in the issue description.

Environment: Claude Code 2.1.206, macOS (darwin 25.5.0, arm64), first-party API, subscription auth (Claude Max).

Live A/B probe, same machine, same minute, headless:

# fails
printf '%s' "Run ls, then call the advisor tool once, report ADVISOR_OK or ADVISOR_ERROR verbatim." | claude -p --settings '{"advisorModel":"claude-fable-5"}' --allowedTools "Bash(ls)"
# -> ADVISOR_ERROR The advisor tool is unavailable. Do not try to use it again.

# succeeds
printf '%s' "Run ls, then call the advisor tool once, report ADVISOR_OK or ADVISOR_ERROR verbatim." | claude -p --settings '{"advisorModel":"claude-opus-4-8"}' --allowedTools "Bash(ls)"
# -> ADVISOR_OK

Transcript forensics across all local projects (16 total advisor server_tool_use calls, 2026-07-08 through 2026-07-10, all with 10+ prior tool calls in-session): 16/16 failed with advisor_tool_result_error / error_code: unavailable. The advisor never succeeded in any real (post-tool-call) session on this account, consistent with the "100% broken in real sessions" finding above.

Workaround in place: switched advisorModel to claude-opus-4-8, confirmed working via the probe above.

Independent confirmation — first report on native Linux and on 2.1.207 (latest), including a claude-fable-5[1m] main; fresh A/B correlation IDs below.

Environment: Claude Code 2.1.207, native Linux x86_64 (kernel 6.17), first-party Anthropic API, subscription OAuth (Max). settings.json: "model": "claude-fable-5[1m]", "advisorModel": "fable".

A/B probes, same machine, minutes apart (2026-07-11, headless claude -p, --allowedTools "Bash(ls)", prompt = run ls once, then call the advisor once):

| advisorModel | Main model | Prior tool use | Result | Round trip | server_tool_use id | UTC |
|---|---|---|---|---|---|---|
| fable | claude-fable-5[1m] | 1× Bash(ls) | ❌ advisor_tool_result_error / unavailable | 7.9s | srvtoolu_0175ZrxCAp7RcsTgHEAuY6rv | 06:27:53.959Z |
| claude-opus-4-8 | claude-opus-4-8 | 1× Bash(ls) | ✅ advisor_result | 16.0s | srvtoolu_018vFtN7dMbHn9qfHJjpbgTu | 06:28:23.889Z |
| claude-opus-4-8 | claude-fable-5[1m] | 1× Bash(ls) | tool not declared at all (client-side pairing rank check) | — | — | — |

Same failure minutes earlier in a real session (a Claude Code background job, transcript naturally full of tool calls): srvtoolu_013amqze16CmSX3q9AuoPQoL at 2026-07-11T06:25:24.659Z → unavailable in 5.5s.

The latency signature matches the OP exactly: failures return in ~4–8s (validation rejection, no advisor inference), successes in 16s+.

Two impact notes, possibly useful for prioritization:

1. Since a Fable main only accepts a Fable advisor (row 3: an opus advisor is silently not declared under a claude-fable-5[1m] main), users running Fable 5 as their main model currently have no working advisor at all in any session that contains tool calls — i.e. every real session.
2. Background/agent sessions are hit 100% by design: their system prompt explicitly instructs the model to consult the advisor after orientation (i.e. after tool calls), so the first advisor call always fails and the tool latches off for the rest of the session.

Consistent with the deterministic trigger in the OP and #76199: fable advisor + ≥1 prior tool_use block ⇒ unavailable; executor-irrelevant; opus advisor immune.

Independent reproduction + full local-history scan supporting the client tool_use trigger, with a regression window.

Environment: macOS 26, Claude Code 2.1.206/2.1.207, Max subscription (OAuth), models claude-fable-5 and claude-sonnet-5. Reproduces identically in interactive and headless (claude -p), and both through a local proxy chain and direct.

Minimal repro (fresh mktemp -d project, tiny context):

• Advisor called as the very first action, no other tools → success (advisor_redacted_result). 7/7 zero-tool runs succeeded same day.
• Same prompt but run one Bash: ls first, then call advisor → server returns {"type":"advisor_tool_result_error","error_code":"unavailable"}. Fails on both fable-5 and sonnet-5 mains. Context is a few KB, so this is not size-related.

Full scan of 265 historical advisor calls (all local session transcripts, 2026-04-11 → 2026-07-12), cross-tabulated by result × "any client tool_use before the advisor call":

| period | OK w/ tools | OK w/o tools | ERR(unavailable) w/ tools | ERR w/o tools |
|---|---|---|---|---|
| 04-11 → 07-01 | 185 | 7 | 0 | 0 |
| 07-02 → 07-12 | 0 | 25 | 43 | 1* |

\* the single exception appears to be a resumed session carrying earlier tool history.

Last success with prior tool_use: 2026-07-01T21:30Z. First unavailable: 2026-07-02T05:34Z. So this looks like a server-side regression deployed around 2026-07-02, presumably in how the executor transcript is serialized into the advisor's input. Server-side server_tool_use blocks (tool_search, advisor itself) do NOT trigger it — only client tool_use/tool_result.

Additional observations:

• After the first failure, advisor stays disabled for the rest of the session (matches #67411).
• The ~100K size threshold reported elsewhere (#67609) looks like a collinear artifact: in real sessions size and tool-use history are almost perfectly correlated. Zero-tool sessions with inline content up to ~110K tokens succeed; tiny sessions with a single Bash call fail.
• advisorModel: claude-opus-4-8 is immune (Bash first, then advisor → OK) on sonnet/opus mains, confirming the A/B earlier in this thread. On a fable-5 main the API rejects it: tools.N.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5' (invalid_request_error, e.g. req_011CcwjyG7i8mEC2QHm3pojd), so fable-main sessions have no advisor workaround other than calling it before any tool use.
• error_code: overloaded is a separate, genuinely transient per-turn error (same 453KB prompt retried 15 minutes later succeeded 4/4) — not this bug.

This is essentially a silent fallback failure — the Fable advisor drops out without escalating to the Opus alternative when the transcript has tool calls.

For production systems, a three-level fallback pattern handles this robustly:

1. Primary fails (Fable unavailable) → automatically retry with backup model/route (Opus advisor here should be automatic, not manual)
2. Backup also fails → cached/graceful degraded mode (return last successful advisor response, or a helpful partial advisory)
3. Total failure → surface the error clearly to the user + log to admin dashboard

The key insight: users should never see a bare "unavailable" error when there's a known working alternative (Opus). That's a routing/gating gap, not a model limitation.

I built a free diagnostic tool that can scan agent configs for these types of fallback chain gaps — shows exactly where each link is missing protection: ark-6ek.pages.dev/diagnose

A lot of token churn here. With Advisor on, the entire transcript is sent as input on every call!

CLI allows for Fable set as Advisor, but it fails 100% of the time. For now we just need to remember to turn it off when you're not using the Sonnet + Opus combination.

<img width="551" height="141" alt="Image" src="https://github.com/user-attachments/assets/f26bbe93-ccce-4a87-a3f4-cca3341df635" />

<img width="292" height="50" alt="Image" src="https://github.com/user-attachments/assets/c217ef18-513f-466d-8cdf-f9d255d907fc" />

For me Fable is now unavailable as a Advisor selection. Wondering if they deactivated for everybody.

<img width="801" height="343" alt="Image" src="https://github.com/user-attachments/assets/b935a662-d925-48d4-bf97-e4a4d9111054" />