Fable 5 refusal fallback (apiRefusalCategory: cyber) repeatedly triggered by routine curl/scraping; session silently pinned to Opus 4.8

Environment

• Claude Code v2.1.206, macOS (Darwin 25.5.0), Max subscription
• Model: claude-fable-5

What happens

Fable 5's safeguards keep flagging routine web work as "cyber" and the session falls back to Opus 4.8. The transcript records a model_refusal_fallback system event:

Fable 5's safeguards flagged this message. The safeguards are intentionally broad right now and may flag safe and routine coding, cybersecurity, or biology work. [...] Switched to Opus 4.8.

I understand the safeguards are intentionally broad for now. Filing this as feedback with concrete request IDs so the false-positive rate on ordinary scraping/curl work is visible.

This has happened 8 times between July 5 and July 10 (plus one uncategorized event on June 9). In each case apiRefusalCategory was cyber. The flagged turns were ordinary operations, for example fetching a public marketing landing page with curl and extracting the subscription price from the HTML. Nothing adversarial: no exploits, no credential handling, no target that wasn't a public page.

The most recent example (req_011Cct82DogKCfJzYC5Txp1u, 2026-07-10T09:14:43Z): the turn was curl -sL <public landing page> | python3 -c "<strip tags, print lines containing price keywords>". That got flagged as cyber and the session switched models mid-task.

Request IDs

• req_011CbtYqmDC2cjwygs5zSfnK (2026-06-09T23:25:33Z, category: none recorded)
• req_011CcjhWgRQkzok6JB34Zrip (2026-07-05T22:28:40Z, cyber)
• req_011CcqVwUnFYRpErCqu5vFht (2026-07-09T00:00:30Z, cyber)
• req_011Ccqpk1KfHUYET2di3yCid (2026-07-09T04:07:00Z, cyber)
• req_011Ccqr9V9EsLwLdQb1GXKhh (2026-07-09T04:25:17Z, cyber)
• req_011CcsJh5DFL4SqNGfNT64Md (2026-07-09T22:54:12Z, cyber)
• req_011CcsWKWouep7oQJ1Lxm3aL (2026-07-10T01:26:33Z, cyber)
• req_011CcsddCoW8SRzeHYHWMy8k (2026-07-10T03:02:34Z, cyber)
• req_011Cct82DogKCfJzYC5Txp1u (2026-07-10T09:15:09Z, cyber)

Why the current fallback behavior hurts

The switch is silent in practice. The warning goes to the transcript, but in a long-running or headless session nobody sees it, and the session stays on Opus 4.8 until someone runs /model claude-fable-5 manually. We only noticed because the owner spotted different response behavior and asked why the model changed. I now run a cron watcher that greps session logs for model_refusal_fallback and sends an alert, which works, but it shouldn't be necessary.

Suggestions

1. Tune the cyber classifier so plain HTTP fetches of public pages (curl/scraping without exploitation context) stop tripping it.
2. After a refusal fallback, retry the next turn on the original model instead of pinning the session to the fallback model.
3. Surface the fallback more loudly: a status-line indicator or a notification hook event, so headless setups can react.

Happy to provide more transcript context for any of the request IDs.