Fable 5 unreachable on Max 20x: new sessions always refused, only pre-existing sessions get it, and the switch back is silent
Bug Description
The part I most want looked at
On 1 August, while Fable was billed against a NZ$170 credit balance that had appeared on my account, it worked — 1,170 requests served, 4 refused. Nobody had told me anything was fixed, but the product itself appeared to be working again, so on 2 August I paid NZ$360.24 to restore Max 20x specifically to keep using it.
Within two hours of that payment it was dead. My weekly Fable meter did not start at zero — it was already sitting at about 7%. At about 10% the system reported my weekly Fable allowance exhausted and dropped me to Opus 5, and from 17:00 that day Fable served me nothing at all, with 13 consecutive safeguards refusals. It is still refusing today: req_011CdemktaTfCy71K62cZoX9 and req_011CdenY6Ku6Ww9QijECMMjh, both raised while reading my own status files.
So I paid on the strength of it working, and it stopped working within two hours of the payment, having consumed a weekly allowance I had barely touched.
No other model on this account is affected. Opus, Sonnet and Haiku have zero safeguards refusals over the same period.
To make it even worse, I cannot start a working Fable 5 session on my Max 20x account. Sessions I start are refused by the safeguards layer and fall back to Opus 5. The only Fable I get comes from long-running sessions started earlier — and those flip between Opus and Fable on their own, at moments I do not choose and am not told about.
Claude Code announces the demotion ("Switched to Opus 5"). It does not announce the restoration. So I work for hours believing I am on Opus when I am not, or the reverse. I am paying for a model I cannot deliberately reach and cannot reliably tell when I am using.
From my transcripts, since 1 August only three sessions have had Fable served at all, and every one of them was started on an earlier day. One ran on Opus from 21:28 on 2 August and then began serving Fable at 08:16:40 the next morning with nothing on screen to indicate it. Another switched between the two models six times in a single day.
What I am asking for
- Someone from Anthropic to contact me directly at zhekou@gmail.com, and a ticket reference I can quote back. Since 26 July I have written six times across three addresses and opened three support conversations. Every reply has been automated; the fastest arrived in 14 seconds. No person has ever contacted me, and I have never been given a ticket number.
- An explanation of why Fable 5 specifically is refused when no other model is, and why the refusals track sessions rather than messages — and a fix, or a clear statement that there is no fix.
- An account of what was actually debited: what the NZ$170 credit was, and whether usage paid out of it was also debited against the weekly Fable allowance I bought on 2 August. From my side I can only watch a meter move; I have never been sent a statement.
- Make the model switch visible in both directions. Falling back to Opus is announced; switching back to Fable is not, and there is no persistent indicator of which model is actually serving. That alone is a bug worth fixing independently of everything above.
- Confirmation of whether the request IDs below are sufficient to pull the server-side decisions.
Everything below is supporting evidence. The complete per-request list is attached as a CSV at the end.
---
Reference
1. Which sessions get Fable at all
All Fable 5 activity on this account since 1 August 12:00 NZST, grouped by session:
session | started NZST | fable served | opus served
29261143 | 08-01 10:02 | 622 | 831
f2bfd17a | 08-02 16:31 | 1 | 6
75f56c7a | 08-02 21:27 | 149 | 470No session started on 3 August has been served Fable at all. The 149 requests attributed to today all belong to 75f56c7a, which was started the previous evening.
Model timeline inside those sessions, from the model field on each response:
29261143 08-02 00:00:03 Fable
08-02 10:53:23 Opus
08-02 11:53:37 Fable
08-02 12:55:45 Opus
08-02 15:41:48 Fable <- 46 seconds after the Max 20x payment
08-02 16:17:30 Opus <- never returns to Fable
75f56c7a 08-02 21:28:15 Opus
08-03 08:16:40 Fable <- no announcement on screenIn 75f56c7a the transcript contains exactly one model_refusal_fallback system record — the demotion — and no record of any kind for the promotion back to Fable at 08:16:40. That is why I had no idea which model I was on.
2. Transcript counts by day
Deduplicated by requestId. Fable 5 requests served versus safeguards refusals, NZST:
NZST day | served | refused
07-24 | 13 | 2
07-26 | 406 | 37
07-27 | 62 | 24
07-28 | 0 | 5
07-29 | 0 | 1
07-30 | 0 | 3
07-31 | 0 | 22
08-01 | 1170 | 4 <- billed to the NZ$170 credit
08-02 | 623 | 19 <- Max 20x purchased 15:41:02 NZST
08-03 | 149 | 2 <- all inside one pre-existing session28–31 July are four consecutive days on which Fable served nothing at all. That dead week is what I assume the NZ$170 credit was compensation for, though nobody ever told me — no email, no receipt, no explanation. I found it by looking at my own account page.
One caveat I would rather state myself than have you find: the refusal column includes my own deliberate availability probes, because I had been testing with 2+2 to find out whether Fable was up. It overstates how much real work was hit.
The percentages in the summary above (7%, 10%) are figures I read off your interface, not instrument readings I can reproduce. Everything in these tables comes from my own transcript files.
3. The 2 August collapse, by hour (NZST)
15:00 | 56 served | 0 refused
15:41 | Max 20x purchased, NZ$360.24
16:00 | 58 served | 4 refused
17:00 | 0 served | 4 refused
19:00 | 0 served | 1 refused
20:00 | 0 served | 1 refused
21:00 | 0 served | 7 refused4. Today's refusals (3 August 2026)
| Time NZST | UTC | Request ID |
|---|---|---|
| 11:16:01 | 2026-08-02T23:16:01Z | req_011CdemktaTfCy71K62cZoX9 |
| 11:25:46 | 2026-08-02T23:25:46Z | req_011CdenY6Ku6Ww9QijECMMjh |
Both occurred during session startup: reading three Markdown status files in my own ~/.claude directory and summarising them. The visible user prompt was a routine startup instruction. Nothing was executed and no external data was involved; I can supply the exact inputs on request.
5. Control condition
Across 24 July – 2 August, in the same transcripts, on the same machine, in the same working directories, often in the same minute:
Fable 5 105 safeguards refusals
Opus 5 0
Sonnet 0
Haiku 0Refusal categories seen include reasoning_extraction and cyber. I do defensive security work on my own local tooling and I am not disputing every refusal in that count. I am disputing that 2+2 is a Usage Policy violation, and that reading my own status files is cyber.
6. Minimal reproducer, already filed
#81285 is the smallest case: a fresh headless session whose entire user-supplied prompt is the string 2+2, hard-refused, with a self-contradictory response (is_error: true alongside subtype: "success"). It has had no reply in over a week. The same prompt was refused again on 2 August at 16:29:17 NZST — req_011CddHsxWnJzWEBjSUMWhHb, category reasoning_extraction — 48 minutes after I paid.
7. Support history
Six emails since 26 July across support@, usersafety@ and feedback@, and three support conversations: 215475234830825, 215475235871358, 215475310826691. Two were closed by the AI agent without resolution. On 26 July an agent told me "I'll connect you with someone now"; no person ever did. My most recent email, to support@ on 2 August, has had no reply at all. My account has never been warned, suspended or banned, so the appeals form does not apply to me.
8. Attached: the complete per-request list
2026-08-03_fable-safeguards-refusals.csv
729 rows, every safeguards refusal my client recorded between 5 July and 3 August, deduplicated by requestId. Columns: UTC timestamp, NZST timestamp, request ID, whether the session fell back to Opus or failed outright (fallback_to_opus 633, hard_error 96), refusal category where the record carries one (reasoning_extraction 92, cyber 2, bio 2), and an eight-character session prefix so you can see which refusals cluster in the same session.
It is unfiltered on purpose. It includes my own deliberate 2+2 availability probes and a few red-team fixtures from my own local security tooling, so it overstates how much real work was blocked — the 105 figure in section 5 is the filtered count. I would rather hand you the raw index and let you cut it your own way than ask you to trust my cut. No prompt text is included; I can supply any specific request's input on request.
Environment Info
- Platform: darwin
- Terminal: ghostty
- Version: 2.1.220
- Feedback ID: 8c1b9de6-a9c8-400a-99b5-ce645e807672
Errors
[]