Fable 5 guardrails false-positive on routine sysadmin work → silent downgrade to Opus 5, with no indication of what was flagged

Summary

Fable 5's safety guardrails repeatedly flag routine systems-administration and desktop-automation work and silently switch the session to Opus 5. The dialog gives no indication of what was flagged, offers no path to review, and the model selection is changed without consent — repeatedly, within a single working session.

This is not a quota/limit issue (evidence below).

What the product shows

Fable 5's protections flagged this message Protections are intentionally broad right now and may flag safe, routine programming, cybersecurity, or biology work. These measures let us ship Mythos-level capabilities faster, and we're working to improve them. Switched to Opus 5.

The dialog itself acknowledges that safe, routine programming and security work gets flagged. The problem is what happens after that acknowledgement — nothing is offered to the user.

Evidence this is not a usage limit

Usage panel at the time of the downgrades (Max 20x plan):

| Meter | Value |
|---|---|
| 5-hour limit | 21% (resets in 1h53m) |
| Weekly · all models | 45% (resets in 15h13m) |
| Weekly · Fable | 58% (resets in 15h13m) |
| Usage credits | $0.00 spent |

Headroom on every meter. The downgrade came exclusively from the guardrail classifier.

Why this workload trips it (and why that's a calibration problem)

The session in question was legitimate engineering on the user's own machine and own LAN: debugging a closed-source audio application, building a replacement control panel, and planning a local control server. That discipline inherently produces operations that look like attack patterns when read out of context:

| Legitimate operation | Surface-level signature |
|---|---|
| PostMessage of synthetic clicks to another app's window (to prove its event queue was stalled) | input injection into a foreign process |
| EnumWindows / WindowFromPoint to determine which window received clicks | UI reconnaissance |
| A hidden background daemon in Startup draining a third-party app's API queue (workaround for a vendor bug) | persistence + hooking |
| FFI loading a native DLL by absolute path | non-standard library loading |
| SSH with root credentials to the user's own servers | credential access |
| Reading firewall state / blocking a client on the user's own router | network infrastructure control |
| Integrating a UPS that can power down machines (in order to protect them during outages) | physical kill switch |
| Force-terminating a hung local application | tampering |

Every left-column item is normal sysadmin work. Every right-column reading is a plausible trigger. The net effect is that competent infrastructure users get flagged far more often than casual users — i.e. the mechanism penalizes exactly the audience that pays for the capability.

Constructive note: Claude Code has context that a single-message classifier appears to discard — is the target localhost or the user's own LAN? is the process one the user started? does the repository carry a documented decision history? That context is what distinguishes administration from attack.

What's missing (the actual asks)

1. Tell the user what was flagged — at minimum a generic category. Without it there is nothing to reformulate, avoid, or dispute.
2. Provide a review path for false positives, which the dialog itself concedes exist.
3. State the consequence — is a flag recorded against the account? does it affect standing or future access?
4. Don't silently change the selected model — or restore the user's chosen model once a subsequent message isn't flagged. Currently the user must re-select manually, repeatedly.

Environment

• Claude Code, Windows 11 desktop app
• Plan: Max 20x
• Model selected: Fable 5 → auto-switched to Opus 5
• Frequency: multiple times per working session

Related

Same session also hit an auto-permission classifier that denied terminating a local application process — part of a documented deploy procedure on the user's own machine — with no in-flow approval path. Filing separately if preferred, but it points at the same root question: the default presumption of authority on a user's own machine.