[BUG] Fable 5 advisor silently disabled by its own safety classifier — no Opus fallback, generic "unavailable", sticky-off for the session
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment
- Claude Code v2.1.172
- VS Code integrated terminal
- Subscription (Max) account, direct Anthropic API auth
- Main model: Opus 4.8
- advisorModel: claude-fable-5
Per the Claude Code advisor accepted-pairs table, an Opus 4.6+ main accepts a Fable advisor, so this is a documented-valid pairing.
What happens
When the transcript contains content that trips Fable 5's safety classifier (cyber / bio / frontier_llm / reasoning_extraction), the advisor call fails with:
"The advisor tool is unavailable. Do not try to use it again."
The executor (Opus 4.8) then continues without any advice, and because of the "do not try again" instruction the advisor stays effectively disabled for the rest of the session.
Repro
- Main model Opus 4.8, set advisorModel to claude-fable-5.
- Put classifier-triggering material in context (e.g. an offensive-security/CTF or biology-adjacent file, or a CLAUDE.md/skill that instructs the model to "explain/show your reasoning").
- Force an advisor call: "consult the advisor before continuing."
- Observe the advisor call return "unavailable" and the executor proceed with no advice; subsequent advisor calls stay disabled.
Expected
Consistent with the main-model path, a Fable advisor refusal should fall back to an Opus advisor (Fable→Opus 4.8), so the executor still receives a second opinion — instead of silently losing the advisor.
Actual / root cause
The advisor is a server-side model call made inside tool execution. The Refusals-and-fallback docs note that the fallbacks configuration does not propagate into model calls made inside tool execution, and that declines after server tools run return the refusal rather than advancing to a fallback. So the Fable advisor's classifier decline never reaches the Fable→Opus fallback machinery; it surfaces to the executor as a generic advisor error (apparently advisor_tool_result_error with error_code "unavailable"), with no category information and no Opus substitution.
Impact
- The advisor is disabled precisely in the domains where a stronger reviewer is most valuable (security audits, biology-adjacent code).
- reasoning_extraction can trip on benign coding contexts whenever prompts/skills ask the model to explain its reasoning, so this is not limited to security/bio work.
- Net effect: Fable cannot be relied on as an advisor for any Opus/Sonnet/Haiku main, despite being an accepted pairing.
What Should Happen?
Requests
- Apply classifier fallback to the advisor sub-inference (Fable→Opus 4.8 advisor), or auto-select a policy-compatible advisor model when Fable declines.
- Replace the generic "advisor tool is unavailable" with a distinct message that names the refusal category (cyber/bio/frontier_llm/reasoning_extraction), so it isn't confused with config/auth failures.
- Treat a classifier decline per-request, not sticky per-session — don't disable the advisor for the rest of the session after a single fire.
- Tune the classifiers to fire on genuinely harmful intent rather than topic adjacency, and/or loosen the threshold to cut false positives. As currently shipped they are conservative enough to block benign defensive-security work, beneficial life-sciences work, and ordinary ML work, plus reasoning_extraction on routine "explain your reasoning" prompts. This is a the most serious problem of the Fable 5. The false-positive rate is the root driver of every problem above; reducing it would resolve most of them even before the fallback/UX fixes land.
Error Messages/Logs
Steps to Reproduce
- Main model Opus 4.8, set advisorModel to claude-fable-5.
- Put classifier-triggering material in context (e.g. an offensive-security/CTF or biology-adjacent file, or a CLAUDE.md/skill that instructs the model to "explain/show your reasoning").
- Force an advisor call: "consult the advisor before continuing."
- Observe the advisor call return "unavailable" and the executor proceed with no advice; subsequent advisor calls stay disabled.
Claude Model
Other
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.172
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Adding an empirical data point that confirms the workspace-context trigger described here, on Claude Code v2.1.172 (Max subscription, direct Anthropic API auth).
A/B test, holding the model pairing fixed (
main = claude-fable-5,advisorModel = fable— the only accepted pairing for a Fable main):| Workspace | Advisor result |
|---|---|
| Empty scratch project (minimal
.claude/settings.json) | ✅ Success — advisor returns normally || Security-tooling repo (CLAUDE.md + AGENTS.md describe a defensive-security framework: guard hooks, attack-pattern rule lists, CVE references, credential-read guards) | ❌
advisor_tool_result_error,error_code: "unavailable"on the first advisor call of the session |So the differentiator is purely the workspace context that rides along on the request (CLAUDE.md / AGENTS.md / file set), not the model pairing or the user's actual question — exactly as the docs warn ("a repository that contains security or biology material can trip the classifier on that context alone"). The content here is entirely defensive security tooling, yet it reliably trips the cybersecurity classifier.
Two consequences worth highlighting:
unavailableand stays sticky-off for the session, matching this report.advisorModel: opuswith a Fable main is rejected outright:400 tools.10.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'.So for a Fable main in a security/bio-adjacent repo, there is currently no working advisor at all:
fabletrips the classifier with no Opus fallback, andopus/sonnetare rejected by the pairing rule.The requested fix (apply the Fable→Opus content fallback to the advisor sub-inference, or auto-select a policy-compatible advisor) would resolve both the sticky-off behavior and the Fable-main dead-end.
Thanks — your write-up really moved this forward. As your A/B test showed, the trigger is purely the workspace context riding along on the request, which is the piece my single case couldn't isolate; and as you flagged with the Fable-main case, the obvious fix runs into its own wall — "Fable advisor declines → fall back to Opus advisor" collides with the pairing rule that rejects an Opus advisor under a Fable main (400 ... cannot be used as an advisor when the request model is 'claude-fable-5'), so any fallback would have to either exempt that path or auto-select another policy-compatible advisor.
Also seeing this shape of failure on Claude Code 2.1.199, with a Sonnet 5 main model rather than Opus 4.8, so it's not limited to that pairing.
Setup:
advisorModel:fableThe advisor call failed with the generic
"The advisor tool is unavailable. Do not try to use it again."on first invocation, and per #67411 it then stayed latched off for the rest of the session. I can't independently confirm the classifier is the root cause on our side without more diagnostics than the client currently surfaces, but the symptom matches this report closely. +1 on the ask to surface the refusal category distinctly from the config/latch failure modes (see #67411), right now they all look identical to the end user.