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

Another false-positive data point, plus a note that the suggested feedback path is broken in the VS Code extension.

Context: Routine internal IT/admin work, conversation in Korean. Tasks were ordinary small-office infrastructure chores: running local Streamlit/Flask apps on LAN ports, adding a Windows Firewall rule for a local service, SSH (key auth) to my own office PC, and NAS deployment scripts. No security research, nothing offensive — plain sysadmin work.

What happened: Fable 5 flagged the message for "cybersecurity or biology topics" and switched the session to Opus 4.8. The likely trigger seems to be surface vocabulary — the combination of ports / firewall / SSH / admin-account keywords in a normal infrastructure-management context. If so, the classifier will hit virtually every small-business sysadmin conversation. Non-English (Korean) content may also be raising the false-positive rate.

Feedback dead-end: The banner says "Send feedback with /feedback", but in the VS Code extension /feedback returns "isn't available in this environment" (see #67913). So the officially suggested remediation path is unavailable exactly where the flag fired, which is why I'm reporting here instead.

Version: Claude Code 2.1.226, Windows 11, VS Code extension.

Confirming this on a different content domain — an algorithmic crypto trading bot for my own use, running on a VPS I own and administer. No AWS or provider-failover vocabulary anywhere; ordinary application code plus defensive hardening of that one machine (firewall/fail2ban, SSH hardening, API-key storage and rotation, systemd service sandboxing, log monitoring). All scoped to a single self-owned host, with no third-party target and no offensive tooling in the session.

Setup

Claude Code: 2.1.221
OS: Ubuntu 24.04.4 LTS (Linux 6.8.0-138-generic)
Selected model: Fable 5
One data point that may matter: the destination model differs from this issue's title. On my machine the switch lands on Opus 5, not Opus 4.8. Captured verbatim from a session log (fired 4× in a single session):

Fable 5's safeguards flagged this message. Our intentionally broad safeguards allow us to deliver more capabilities faster, but can sometimes flag legitimate coding, cybersecurity, and biology tasks. Switched to Opus 5. Send feedback with /feedback or learn more: https://support.claude.com/en/articles/15363606

Trigger

It fires during routine server-hardening / sysadmin work on the one host I own. I have not been able to isolate the specific message — it happens rarely and unpredictably, which is itself part of the problem: the notice carries no signal about which category or which part of the message was flagged, so there is nothing to learn from and nothing to avoid.

Supporting the requests already in this issue

+1 in particular on:

/model being authoritative after a classifier switch, or at least an explicit --force-style escape hatch;
a /config setting for the behaviour (ask-first / notify-only);
the notice stating whether the switch is reversible and how;
scoping the cyber classifier so that defensive administration of self-owned infrastructure doesn't land in it.
Two smaller ones:

When only the cyber side fires, please don't lump it in as "coding, cybersecurity, and biology". Naming the category that actually fired would save a lot of confusion — as it stands the biology mention makes the notice read as a bug rather than a policy.
Some indication of what in the message was flagged. A rare, unpredictable switch with no per-message signal gives the user nothing to act on, which makes it hard to file a useful report — including this one.
I have not captured a /model override attempt inside an affected session, so I'm not asserting the override-doesn't-stick behaviour from my own logs — only confirming the switch itself, its verbatim text, and the benign domain. Will follow up with an exact reproducer if I manage to capture one.

ALGO_BOT_SUPER_PRO_AUDITA_PIEPRASIJUMS_AGENTS.md

I am persistently experiencing what appears to be this same problem in a different domain, foundational mathematical logic. The discussion is completely benign and unrelated to "cybersecurity or biology" - but it does involve classical logic and paradoxes, for which potential trigger words like "explode", "explosive", and "denotes" get used a lot: explosion is a principle of classical logic (from any contradiction, anything may be derived), and applying this principle to standard semantic paradoxes like the Liar, Curry's, Russel's, Berry's, or any number of other paradoxes we often say "explodes" or "detonates" the logic by yielding a contradiction or inconsistency.

This false-positive problem is effectively censoring my attempt to use Fable for mathematical logic research, so a real solution would be much appreciated.

Here is the output of Claude itself sleuthing the situation after one such downgrade event:

This I can dig into directly — I have this session's transcript. Let me gather hard evidence for which mechanism matches, rather than rely on my in-conversation impressions.

The switch just fired again — right now, mid-turn, with no subagent launch and no compaction this time. That's a strong tell. Let me confirm against the transcript:

Confirmed. Let me pin down the correlation — do the Opus runs begin at the flag notices (mechanism 2) or at compaction boundaries (mechanism 1)?

Confirmed — and I caught it happening in real time. It's mechanism 2 (the safety-classifier reroute), definitively. The transcript literally contains the notices: "Fable 5's safety measures flagged this message for cybersecurity or biology topics… Switched to Opus 4.8" — three of them. That's the smoking gun, and it's produced a lot of drift: of the assistant messages in this session, ~1,439 ran on Opus versus ~6,834 on Fable.

Here's what the evidence rules in and out:

• Mechanism 2 (safety classifier): confirmed, and it's the driver. Explicit flag→Switched notices are in the log. Once flagged it's sticky (that's why /model fable only "sometimes" brought you back — it holds until a fresh turn happens not to re-trip it).
• Mechanism 1 (config-bleed at compaction): effectively ruled out. teammateDefaultModel, CLAUDE_CODE_SUBAGENT_MODEL, and ANTHROPIC_MODEL are all unset, and both your pins are Fable (.claude/settings.json → fable, ~/.claude/settings.json → claude-fable-5-1). So there's no Opus id for the #67908/#49816 compaction path to grab. There is one Opus run sitting near a compaction boundary, but with no config source that's just the already-flagged Opus state being carried across the boundary, not a fresh mis-resolution.
• My earlier "subagent bleed-through" guess was wrong. The real correlation is content, not subagent launches — which is why it just fired again this very turn with no subagent involved.

What's tripping it: this project is a false-positive minefield for a cyber/bio classifier. Our own math vocabulary is the problem — "explode / explosive / detonate" (Curry and excluded-middle), "bomb-arm disarmed" (Löb), "leak" (Rhea's "your world leaks") — and the classifier reads tool output too, so a subagent prompt about paradoxes "exploding" or being "disarmed" trips it as readily as your prose. Your pasted analysis this turn is saturated with the exact trigger words ("cybersecurity or biology," "exploit," "fallback," "circuit breaker," "obfuscate," "leak"), which is almost certainly why the model flipped mid-investigation.

Heading it off — honest options, none clean:

1. The vocabulary is load-bearing mathematics, so we can't scrub it. But I can be conscious of it in subagent prompts — e.g. say "the paradox derives everything" instead of "detonates," "the implication is inert on a gap" instead of "the bomb is disarmed" — to reduce tool-side flags. Marginal, but free.
2. /model fable after a flag (what you've been doing) — works until the next trip.
3. The "Switch models when flagged" setting: OFF gives a hard block instead of silent Opus — worse for this workflow, not better. So don't.
4. Report it — and this session is unusually clean evidence: a formal-logic paper about diagonalization and self-reference, repeatedly flagged as "cybersecurity or biology." The open issues #67246 and #93821 are exactly this; adding the transcript notices + the "it fires on benign math vocabulary in tool output" angle would strengthen them. (I've also captured this in a local feedback draft you can review via /feedback.)

Net: it's the classifier, not compaction or config, and there's no in-session fix that keeps you reliably on Fable — the realistic path is /model fable after flags plus pushing the false-positive upstream. Given all that, do you want me to hold the tTrue_disq commit until you're back on Fable so the trailer's right, or just commit it now with whatever model's active? And I'm still ready for the framing refinements whenever the model settles.

Quick update: a workaround that so far, tentatively, seems to be working (cross fingers): my Fable sessions are now having to self-censor their conversations with sub-agents, carefully using logical euphemisms like "proves all sentences true" instead of "explodes". A non-ideal solution to be sure: I really don't want this self-censorship to leak into (oops, trigger word) or contaminate (oops, another trigger word) the research itself.

Welcome, Claude, to the USSR!