·5 min read·ai-operations · methodology

Claude Fable 5 Moves to Usage Credits Tomorrow. Here Is the Part That Actually Matters to Builders.

The internet is full of leaked-prompt threads and architecture guesses about Anthropic's most capable model. Almost none of it is verifiable. The part a builder can actually use is four small API changes and one behavior worth watching, plus a working skill that handles all of them.

Contents

Claude Fable 5, Anthropic's most capable widely released model, launched on June 9, 2026 and moves off subscription plans to usage credits on July 7. In the weeks in between it has attracted the thing every frontier model attracts now: a wave of "reverse engineering." Leaked-system-prompt threads. Screenshots claiming to reveal its parameter count. Confident posts about how it was trained.

We spent a day running that claim set to ground against Anthropic's own documentation. The finding is worth stating plainly, because it saves you the same day: almost none of the reverse-engineering is verifiable, and the parts that are genuinely useful to a builder are small, boring, and documented in public. This is the signal.

#What Fable 5 actually is

Fable 5 (claude-fable-5) is positioned above Claude Opus 4.8 for the most demanding reasoning and long-horizon agentic work. It carries a 1M-token context window, is priced at $10 per million input tokens and $50 per million output tokens (roughly twice the Opus tier), and is documented as "slower." Anthropic frames it as "a Mythos-class model that we've made safe for general use."

$10 / $50
Claude Fable 5 price per million input / output tokens, about 2x the Opus 4.8 tier (Anthropic models overview, accessed 2026-07-06)

Its sibling, Claude Mythos 5, is "the same underlying model as Fable 5, but with the safeguards lifted in some areas," available only through Anthropic's invitation-only Project Glasswing. That single sentence is, as it happens, the only thing Anthropic has confirmed about the model's internals.

#The reverse-engineering, in one honest paragraph

Everything circulating about Fable 5's architecture (parameter count, dense versus mixture-of-experts, training data, whether it is a distillation of something larger) is undisclosed by Anthropic and unestablished by anyone else. The most-shared artifact, a very long "leaked system prompt" posted to GitHub, has never been diffed against Anthropic's actual prompt and is best treated as unverified. The one firmly established internals fact is Anthropic's own disclosure above: Fable and Mythos are one model in two configurations, one with a safety-classifier layer and one without. If you are making engineering decisions, treat the rest as rumor.

#The four API changes that will actually bite you

Here is the part worth your attention. Fable 5's request surface differs from the Opus tier in four ways, and each one silently breaks code written for older models. All four are documented; none are obvious; every one of them has cost a team an afternoon.

1. Thinking is always on. You omit the thinking parameter entirely. Sending an explicit {"type": "disabled"} returns a 400. You control reasoning depth with output_config.effort (low through max), not a thinking budget.

2. Sampling parameters are gone. temperature, top_p, and top_k all return a 400 on Fable 5. If your prompt builder sets temperature=0 for determinism, it now fails outright. Steer with the prompt instead.

3. A refusal is a 200, not an exception. Fable 5's safety classifiers can decline a request and return HTTP 200 with stop_reason: "refusal" and an empty content array. Code that reads content[0] unconditionally does not throw a clean error; it throws an index error on an empty list, deep in your pipeline. You check stop_reason first.

4. Recovery is opt-in. Without a fallback configured, a refused request simply stops. And these refusals are not only for genuinely disallowed work; benign but adjacent tasks (security tooling, life-sciences questions) can trip the classifiers. Anthropic's own answer is to configure a server-side fallback so a declined request is transparently re-served by Claude Opus 4.8.

#The one behavior worth watching

Fable's classifiers route a triggered request to Opus 4.8 in, by Anthropic's account, "less than 5% of sessions." That is a sensible safety design. It also means that on a small slice of requests you are paying Fable's price and getting an Opus answer, with no notification by default.

<5%
of sessions where Fable 5's classifiers route the request to Claude Opus 4.8 instead (Anthropic launch announcement, accessed 2026-07-06)

This is not a problem to be alarmed about. It is a fact to be observed. The response tells you which model produced it; a disciplined integration reads that and records it, so you always know what you actually paid for and got.

#The design move: an escalation boundary

Put those pieces together and the right way to use Fable 5 falls out. It is the most capable model, it is roughly twice the price, it is slower, and it occasionally hands your request to a cheaper model anyway. You do not want it as your default. You want it as an escalation boundary: your normal model handles the bulk of a job, and you hand the hardest slice to Fable, with a safe, automatic path back to Opus 4.8 for anything it declines.

That is a small, well-defined piece of code, and it is exactly the kind of thing that is easy to get subtly wrong given the four changes above. So we built it and are giving it away.

fable5_delegate.pyResource
fable5-delegate: escalate to Fable 5, fall back to Opus 4.8

A small escalation boundary for Claude Fable 5. Sends the hardest slice of a job to the most capable model, handles the four API changes that break older code, and falls back to Opus 4.8 on a refusal.

Open the resource, copy-ready

It handles all four corrections, makes the silent fallback observable, and, because the server-side fallback beta is very new, it degrades automatically to a client-side refusal-retry that uses only stable API. The full implementation, with streaming, a cost readout, and an offline self-test, is downloadable here.

#What we are not claiming

We verified every fact above against Anthropic's published documentation on July 6, 2026, and we validated the skill against a local model of the documented API. We did not run it against Anthropic's production endpoint, which is why the fallback degrades gracefully rather than assuming the newest beta always holds. If Anthropic changes the fallback header or the pricing, the constants at the top of the file are the single place to update.

The credits change tomorrow. The discipline it rewards is the same one good engineering always rewards: spend the expensive, most-capable tool exactly where it earns its cost, and nowhere else.