Safety-classifier model switch (Fable 5 → Opus 4.8) fires on benign content and can't be overridden with /model

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/67006
2. https://github.com/anthropics/claude-code/issues/67127
3. https://github.com/anthropics/claude-code/issues/67002

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Another data point — same Fable 5 → Opus 4.8 switch, but the domain is commercial supplement market research, not security and not academic, which widens the false-positive surface beyond what's already reported here and in #65721.

What triggered it

A routine market-analysis session over a dietary-supplement / nutraceutical product category. The session naturally accumulated vocabulary that is completely standard in this commercial vertical but reads as "biology" to the classifier — product-positioning terms like cellular senescence, DNA repair, cellular repair, anti-aging mechanism, plus common ingredient names (NAD precursors, resveratrol, etc.).

Nothing in the session was wet-lab, pathogen, or dual-use — it was ordinary product-category market analysis. The notice also fired on a turn whose actual request was benign (inspecting a document's structure); the thing that got scored was the accumulated context, not the user's current message — matching the accumulated-vocabulary mechanism in #65721 and the "scores the wrong thing" observation in #66657.

Notice shown

Fable 5's safety measures flagged this message for cybersecurity or biology
topics. They may flag safe, normal content as well. These measures let us bring
you Mythos-level capability in other areas sooner, and we're working to refine
them. Switched to Opus 4.8. Send feedback with /feedback or learn more

Why this matters beyond the existing reports

The closest existing issues frame the bio false-positive as an academic research problem (#65721) or a security-vocabulary problem (#67246's failover case). This adds a third, large category: the dietary-supplement / nutraceutical commercial vertical, where cellular-repair and similar terms are routine product-positioning language. Any market-research or e-commerce catalog workflow in this vertical will accumulate this vocabulary and trip the classifier on benign turns — with no documented way to switch back (/model won't override, per the original report).

Same issue here.

I'm a heavy Claude Code user on the $180 Max plan and started seeing this behavior repeatedly after the Fable 5 rollout.

What frustrates me is not the safety system itself. False positives happen.

What frustrates me is this combination:

Fable 5 gets replaced by Opus 4.8 mid-session.
The notice explicitly admits safe content can be flagged.
There is no obvious way to override the decision.
Asking about the trigger often seems to trigger it again.

In my case, the content is not offensive, malicious, or related to attacks.

Most of my work revolves around software governance, architecture, audits, quality gates, approval workflows, authority models, compliance, and documentation.

Ironically, the more security-conscious and governance-focused the documentation becomes, the more likely it appears to trigger the system.

The result is a strange user experience:

The system acknowledges the possibility of false positives, but the restriction is still enforced immediately and the user receives very little information about why.

I don't need less safety.

I need more transparency.

Questions I'd like Anthropic to answer:

What exactly is being classified?
Is the classification based on context or keyword matching?
Why is Fable 5 removed instead of showing a warning?
Is there an appeal/override mechanism planned?
Are governance, compliance, audit, architecture, and security-review documents known sources of false positives?

At first I thought this was something unique to my environment.

Finding this issue and the growing number of similar reports suggests it may be a broader pattern.

#ClaudeCode #Anthropic #AI #DeveloperExperience #AISafety #Fable5

Literally same issue here !

My First Prompt :
"Okay is it possible to make an application for windows, that basically user can lock an app such as Steam for certain time period and as he/she locked it, there will be absloutley no way to open that app unless they actually change their windows "

And Recived Below with switch :

"● The project directory is empty, so this is a fresh build. Good.

Before I dig into questions, let me set one honest expectation, because it shapes everything: a self-imposed lock that an admin user truly cannot bypass is, in the strict
sense, impossible on Windows. If you have admin rights on your own machine, you can always kill a process, boot into Safe Mode, or edit the registry. The realistic goal is a
strong commitment device: make bypassing it annoying and effortful enough that your willpower wins in the moment, while keeping a sane escape hatch for emergencies. Tools
like Cold Turkey and Freedom work exactly this way. I'll design toward that — maximally resistant, not literally unbreakable.

With that framing, my first question:

Who is this for?

1. Just you / personal use — you're building a self-discipline tool for your own machine, and you're okay with it being "hard to bypass but not NSA-proof."
2. Distributable product — you want to ship this to other people (free or paid), which means installers, signing, support, and handling users who aren't admins.
3. Controlled/managed device — e.g. a parent locking a kid's PC, or an org, where the person setting the lock is different from the person being restricted (this actually

makes "unbreakable" achievable, because the locked user isn't an admin).

Which one matches your intent?

● This model has safety measures that flagged something in this session. This sometimes happens with safe, normal conversations. These measures let us bring you Mythos-level
capability in other areas sooner, and we're working to refine them. Switched to Opus 4.8. Send feedback with /feedback or learn more:
https://support.claude.com/en/articles/15363606
⎿ Tip: You can configure model switch behavior in /config"

Another data point — same Fable 5 → Opus 4.8 switch, but with a trigger mechanism worth isolating: the workspace context alone, with zero security vocabulary in the actual prompt.

What triggered it

The prompt was pure git housekeeping: "create a PR, delete the branch, and merge to the other feature branch." No mention of security, credentials, exploits, or anything adjacent. The classifier still fired and switched the session to Opus 4.8.

Why: the repo, not the request

The project is a multi-repo microservices backend where recent legitimate defensive work has left security language everywhere in the ambient context the first request carries:

• branches named fix/security-hardening across several repos (visible in git status)
• project memory / CLAUDE.md notes describing that hardening work (JWT/session handling, admin-console lockdown, Cloudflare Access)

This matches the documented behavior in model-config: fallback can trigger on the first request "because the first request carries workspace context such as your CLAUDE.md content and git status." The practical consequence is nasty: rewording the prompt cannot avoid the flag, because the prompt was never the problem — every session in this workspace re-sends the same context. The "edit and retry" path offered by ask-first mode is a dead end for this class of false positive.

Compounding pattern

In the same project, /security-review (Anthropic's own bundled skill, run on my own code — defensive review, nothing offensive) also triggers the switch. So the loop is: do legitimate security hardening → the work leaves security vocabulary in branches and project docs → the classifier then flags unrelated routine turns (PR/merge/branch cleanup) forever after. The more responsibly you secure your own code, the less usable Fable 5 becomes in that repo. Same irony @Aslan4u73 described for governance/compliance docs.

Adding another data point from a different domain: Japanese business-compliance work (government subsidy application support, accounting audit, internal security controls).

The Fable 5 safeguard classifier repeatedly fires on ordinary Japanese business terminology such as 審査 (screening/review), 返還 (refund/repayment), 改ざん検知 (tamper detection), 回避 (avoidance — as in "avoiding disqualification"), 持ち出し統制 / egress control (data-loss-prevention policy), and 検知 (detection). These are standard vocabulary in subsidy-program compliance and audit contexts, with no offensive-security intent.

Observed behavior:

• The flag fires even on trivially benign messages — e.g. a two-word "continue" prompt (「続きを」) and a message complaining about the model switching itself were both flagged.
• Frequency is high enough that Fable 5 is effectively unusable for this workload: sessions keep getting switched to Opus 4.8 mid-task, and switching back manually every time defeats the purpose of setting "model": "fable" in settings.json.
• Adding clarifying context via a UserPromptSubmit hook does not prevent the flagging.

Requests:

1. Improve classifier precision for non-English (Japanese) business/compliance vocabulary — the current behavior looks like surface-level keyword matching on translated terms.
2. Provide a user-visible option to stay on / return to Fable 5 after a flag is reviewed, instead of a sticky switch that /model cannot reliably override.

Follow-up with a severity data point: this is no longer "occasional flags" for us — an entire legitimate workload is now locked out of Fable 5.

Our sessions for drafting Japanese government subsidy applications (ものづくり補助金 / Monodzukuri manufacturing-SME grant, a flagship METI program) flag so frequently that every session gets force-switched to Opus 4.8 almost immediately. The vocabulary that appears to trigger it — 審査基準 (screening criteria), 足切り (cutoff threshold), 返還 (repayment of grants), 改ざん検知 (tamper detection for audit compliance) — is the unavoidable core vocabulary of the official government documents themselves. We checked our side: no injected instructions or CLAUDE.md content contains anything resembling offensive-security phrasing. There is nothing left for the user to sanitize without rewriting the government's own terminology.

The net effect is that a paying user cannot use the model tier they pay for on ordinary, fully lawful business-compliance work, purely because the domain's Japanese vocabulary superficially resembles attack terminology. #67305 described the same "effectively unusable for a whole domain" pattern for defensive CTI before it was closed.

Reiterating the two asks, in priority order:

1. A way to keep or restore Fable 5 after a flag (session-level "reviewed, continue on Fable" option) — this decouples the classifier's precision problem from the lockout problem.
2. Classifier precision work on non-English business/compliance/government-program vocabulary.

Correction + much better telemetry on my two comments above. We pulled the actual local logs, and my earlier root-cause guess was wrong. Posting the measured facts since they're far more useful:

• The flag category is reasoning_extraction, not a vocabulary/cyber match. All 10 flag events in the affected session (2026-07-02, 17:39–18:56 JST) have apiRefusalCategory: reasoning_extraction records. My earlier claim that Japanese subsidy/audit terminology was the trigger is unsupported — please weigh the vocabulary anecdotes in my previous comments accordingly.
• Context-side mitigation does not work. We injected a clarifying "this is legitimate compliance work" banner via a UserPromptSubmit hook mid-session (≈18:05); 5 more flags fired after it (18:13, 18:18, 18:22, 18:41, 18:56). Consistent with the category not being about content vocabulary at all.
• The lockout loop is real and measurable: the user manually ran /model back to Fable 5 ~10 times during that 77-minute window, and every return was flagged back to Opus 4.8 within a message or two. Session totals: 1020 messages spoken by Opus 4.8 vs 209 by Fable 5.
• Flags also fired on trivial inputs (a two-word "continue" prompt), in a different session — so whatever reasoning_extraction keys on, it isn't the visible user message.
• One shared variable across both flagged sessions we're now testing: a persistent user-level CLAUDE.md instruction that directs the model's thinking ("Think in English, interact with the user in Japanese"). If an instruction about the model's internal reasoning can trip this category, that's worth knowing — it's an extremely common pattern for non-English users. We've removed it and will report whether flag frequency changes.

The priority-1 ask is unchanged and now better supported: when a flag is a false positive, users need a way to stay on / return to Fable 5. A 10-cycle forced-switch loop in 77 minutes on legitimate work is the current UX.

Same failure mode, plus a working override that this thread did not have at filing time.

Setup: macOS desktop app, bundled runtime 2.1.205. A long technical session about
cryptographic signing infrastructure (Ed25519 keys, credential handling, signature
verification; all benign, all vocabulary the classifier apparently pattern-matches)
kept dropping from Fable 5 to Opus 4.8.

The transcript records each switch as a system event with
subtype: "model_refusal_fallback" and direction: "retry":

Fable 5's safeguards flagged this message. This sometimes happens with safe, normal conversations. Switched to Opus 4.8.

In my case /model claude-fable-5 reported success ("Set model to claude-fable-5")
rather than "Kept model as Opus 4.8", but the outcome was the same: the next message
got flagged and switched back before a single Fable turn completed. Four attempts
over 34 minutes, each undone within 1 to 3 minutes:

07:24:06  /model claude-fable-5
07:25:57  model_refusal_fallback -> Opus 4.8
07:36:35  /model claude-fable-5
07:39:53  model_refusal_fallback -> Opus 4.8
07:53:21  /model claude-fable-5
07:54:11  model_refusal_fallback -> Opus 4.8
07:57:14  /model claude-fable-5
07:58:39  model_refusal_fallback -> Opus 4.8

What worked: "switchModelsOnFlag": false in ~/.claude/settings.json. The settings
schema describes it as: "When safety measures flag a message, automatically switch to
a different model to keep chatting. When off, your session will pause instead." After
setting it, the next /model claude-fable-5 stuck. The session then ran 51 consecutive
Fable turns on the same security-dense content with zero model_refusal_fallback
events.

Two caveats for anyone reaching for it:

• The failure mode changes from silent switch to pause. For pinning a model that is

the right trade, but it is a trade.

• The setting appears in the settings schema and nowhere else I could find. Discovering

it took reading the schema directly; nothing in /config or the flag notice points
to it.

So an override now exists, which addresses part of this issue. Still open in my view:
/model reporting success while the classifier immediately reverts it leaves the
session in a state the UI misrepresents, and the flag notice does not mention the
setting that controls the behavior.

Adding data from a separate incident that matches this report closely. Over 2026-07-14 to 2026-07-16, across 4 sessions with claude-fable-5[1m] pinned in settings.json, I logged 9 fallback events to claude-opus-4-8 triggered by the safety flag described above. Several carried "diagnostics":{"cache_miss_reason":{"type":"model_changed"}} in the transcript, meaning the prompt cache was invalidated by the switch, an extra cost on top of the unrequested model change itself. One event surfaced an explicit "stop_reason":"refusal" with "category":"cyber" right before the fallback. All flagged content was defensive security work I own: auditing my own VPS, running semgrep, and a zeroize-audit skill run, none of it offensive security or third-party targeting.

The only way I found to stop it was setting "switchModelsOnFlag": false directly in settings.json. That control isn't surfaced anywhere in the switch notice or in /config, I only found it by reading the settings schema.

Environment: Claude Code 2.1.211, macOS Darwin 25.5.0.

Given the cache invalidation on top of the unrequested switch, and the complete lack of in-notice guidance to the override, it also seems worth considering a usage credit for fallbacks the user didn't request.

Retrieval-side consequence of the same switch, on claude.ai (not the CLI) Environment: claude.ai, inside a Project. I don't know whether Projects in Claude Code are affected. Observed. A conversation that has undergone the Fable 5 → Opus 4.8 safety-classifier switch is subsequently excluded from past-conversation retrieval: - conversation_search: the conversation does not appear in results at all. - recent_chats: url and updated_at are returned; the body is replaced with [Content redacted, chat flagged by safety classifier]. The conversation itself is unaffected — it opens, continues, and calls tools normally. There is no user-visible indicator that it has been excluded. How I narrowed it down. In a Project of 38 conversations, 2 were unreadable. I ruled out, one at a time: content topic (a readable conversation covers near-identical subject matter), length (190k / 23k characters unreadable, 45k readable), date, attachments, model version, number of in-session safety notices, Project membership, and account-level state. Moving the two conversations out of the Project and back in rewrote their updated_at but did not change the redaction. The only shared property was the Fable 5 → Opus 4.8 switch at the start of both conversations. Reproduction. Re-running the first-turn prompt that had triggered the switch produced a new conversation that is also unreadable. Feeding the same material to Opus 4.8 directly, with no switch, produced a conversation that is readable. Final counts: 3 switched → 3 unreadable; 36 not switched → 36 readable. Fact vs. inference. Everything above is observed. What I do not know: whether the switch itself sets the flag, or whether both are downstream of a common classifier event. I have no visibility into which. Specific reproduction steps: https://www.reddit.com/r/ClaudeAI/comments/1s7f72l/comment/oyjbsn4/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=2&utm_content=share_button