Skip to content

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

Description

@AndrewTKent

Summary

Mid-session, the Fable 5 safety classifier flagged a normal engineering discussion as "cybersecurity or biology" and silently switched the active model to Opus 4.8. The notice itself acknowledges this is expected ("They may flag safe, normal content as well"), but there is no working way to switch back — /model reports Kept model as Opus 4.8, and /config does not surface an override. A feature that admits it produces false positives must give the user a way to override them; today it doesn't.

What I was actually doing

Editing a software design doc for an Amazon Bedrock provider-failover mechanism (retry a request on a fallback cloud provider during an outage). Dense with words like outage, AWS, InvokeModel, fallback, circuit breaker, provider failure. Pure resilience engineering — nothing remotely cyber/bio. The classifier appears to have pattern-matched that vocabulary as security-adjacent.

The 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:
https://support.claude.com/en/articles/15363606

Steps to reproduce

  1. Run a session on Fable 5.
  2. Hold a long, technical conversation that uses security-adjacent vocabulary in a benign context (e.g. cloud provider failover, outage handling, retry/circuit-breaker design).
  3. Observe the classifier flag a message and auto-switch to Opus 4.8.
  4. Run /model and try to select Fable 5 again → it reports Kept model as Opus 4.8.
  5. Run /config → no obvious control restores the model or disables the auto-switch.

Expected

  • The switch is, at minimum, overridable within the session. After seeing a false positive, /model (or some documented control) should restore the chosen model.
  • The auto-switch behavior is discoverable and configurable — if /config governs it, the relevant setting should be findable from the switch notice, not just referenced in passing.
  • Ideally the switch is ask-first (prompt before swapping) rather than silently re-routing subsequent turns.

Actual

  • /model does not restore the model — Kept model as Opus 4.8 on repeated attempts.
  • /config dismisses without an evident override.
  • Every subsequent turn in the flagged thread continues on Opus 4.8 with no user recourse.

Why this matters

The feature's own notice states it flags safe content. False positives are therefore a designed-in certainty, not an edge case — which makes a working user override mandatory, not optional. Without one, a single misfire downgrades the rest of a session (you're paying for / expecting Fable 5 and silently get Opus 4.8) with no way out short of starting a new conversation.

Two distinct layers here, only one of which is a Claude Code (CLI) bug:

  1. CLI/harness (this issue): the switch is silent, the /model override doesn't work, and /config doesn't clearly expose the toggle.
  2. Model layer (not this repo): the classifier false-positives on benign resilience-engineering vocabulary. Reported separately via the model-feedback channel (support.claude.com/en/articles/15363606).

Environment

Platform: darwin
Terminal: zed
Version:  2.1.170
Model:    claude-fable-5[1m] (switched to claude-opus-4-8 by the classifier)

Suggested fixes

  • Make /model authoritative — an explicit user model selection should override a classifier-induced switch for the rest of the session.
  • Add a visible /config control (and link it from the switch notice) to set the switch behavior: ask-first / notify-only / disabled.
  • When auto-switching, state it's reversible and how, inline in the notice.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:modelbugSomething isn't workingplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions