Claude Fable 5 vs Mythos 5: API Routing

Status update (June 13, 2026): As of this update, Anthropic has suspended access to both Claude Fable 5 and Claude Mythos 5, and GitHub Copilot has pulled Fable 5 from all of its surfaces too (other Claude models are unaffected). Everything below that says “you can call Fable 5 today” reflects the June 9 launch-day state and is not currently true. Until access is restored, treat this piece as a reference for how the two models differ by design, not as a guide for which one to route to right now. The reason for the suspension is so far mostly from press reporting, with no full official explanation yet — wait for Anthropic’s restoration notice before making production decisions.

A work note on two models that share a brain but not a rulebook — and what that means before you wire either into a pipeline.

Hello, guys. I’m Dora. I spent the better part of a week trying to figure out which of these two I should plan my routing around. The short version of Claude Fable 5 vs Mythos 5: same underlying model, two different deals on safety and access. That single difference decides almost everything downstream — who can call it, what comes back when a request gets blocked, and how your fallback logic has to behave. This piece documents what I sorted out, what’s still fuzzy, and where you should go read the spec yourself instead of trusting me.

One thing up front. I haven’t run Mythos 5 in production — almost nobody outside Project Glasswing has. So a chunk of this is comparing what’s documented, not what I’ve personally stress-tested. I’ll flag where that line is. And a second thing, added after the fact: the access situation around both models moved fast in the days after launch (see the status note up top), so treat every “you can call it today” below as describing the launch-day picture, not necessarily this morning’s.

Fable 5 vs Mythos 5 in one sentence

Same capability class. Different safety model, different access model. That’s the whole comparison, and everything below is just the consequences.

Same capability class, different safety/access model

Both models come out of the same base. Anthropic’s own docs say Claude Mythos 5 shares Claude Fable 5’s capabilities — the split isn’t about raw intelligence. Fable 5 ships with safety classifiers that can decline a request. Mythos 5 doesn’t carry those classifiers, and it’s only handed out through a vetted program.

So when you see a benchmark chart where Mythos 5 edges out Fable 5 by a hair, that’s not a smarter model. It’s the same model without the guardrails occasionally routing a query elsewhere. The decoder noted the asterisked benchmark gaps come from safeguard fallbacks to Opus 4.8, not from a capability difference. Worth keeping straight, because the marketing-adjacent framing makes it sound like Mythos 5 is the “pro” tier. It isn’t. It’s the unguarded tier.

Why this difference matters for API builders

If you’re building, the access split is the part that bites first. You can call Fable 5 today. You probably can’t call Mythos 5 at all. So most of your design work is really “how do I build around Fable 5’s refusal behavior,” and Mythos 5 is a footnote unless you’re in critical infrastructure.

Here’s a quick orientation table before the details:

Dimension	Claude Fable 5	Claude Mythos 5
Capability class	Mythos-class (same base)	Mythos-class (same base)
Safety classifiers	Yes — can decline requests	No classifiers
Access	Generally available	Limited, Project Glasswing only
API model ID	claude-fable-5	claude-mythos-5 (unconfirmed)
Pricing	$10 / $50 per M tokens (in/out)	$10 / $50 per M tokens (in/out)
Context / output	1M context, 128k output	1M context, 128k output
Data retention	30 days (not ZDR)	30 days (not ZDR)
Who it’s for	General production use	Vetted cybersecurity/biology research

A note on the API model IDs: claude-fable-5 is confirmed by Anthropic’s docs and multiple sources. claude-mythos-5 is a reasonable guess from the naming pattern — since Mythos 5 isn’t sold publicly, there’s no public doc backing that exact string. If you actually need to call it, use whatever your account team gives you, not what I’ve put here.

Access and availability

This is where the two models stop being interchangeable.

Fable 5 general availability

Fable 5 is the one you actually get. Per Anthropic’s Fable 5 product page, it’s available on the Claude Platform natively, through marketplaces, and on AWS, Google Cloud, and Microsoft Foundry. For developers, you call it with the model string claude-fable-5. No application, no account-team gating. You sign up and go.

VentureBeat confirmed the rollout shape: Fable 5 is available to the general public today through its website, apps, and API. That’s the model 99% of builders will route around. Caveat I have to add now: that “available today” was true on June 9. As of June 12, Anthropic suspended access to both Fable 5 and Mythos 5, and GitHub pulled Fable 5 from all Copilot surfaces the same day — every other Claude model stayed up. Separately, two days after launch Microsoft had already blocked Fable 5 for its own employees inside GitHub Copilot, citing the 30-day retention requirement against its internal compliance rules (that block was internal-only; external customers kept access until the broader suspension). Point being: “self-serve and always on” is not a safe assumption for this model right now.

Mythos 5 restricted access

Mythos 5 is a different story. It’s not generally available: it is offered in limited availability to approved customers in Project Glasswing. If you want it, the docs say to contact your Anthropic, AWS, or Google Cloud account team — meaning if you don’t already have one, that’s your answer. The decoder put it plainly: Mythos 5 is reserved for a small group of partners and drops restrictions in areas like cybersecurity.

I’ll be honest — I read three articles before I accepted that “restricted” really means restricted. It’s not a higher pricing tier you can buy into. It’s an approval process tied to a security program. If that’s not you, plan around Fable 5 and move on.

Platform availability and account-team requirements

The practical filter: Fable 5 is self-serve across the major clouds. Mythos 5 requires going through an account team and getting approved into Project Glasswing, Anthropic’s restricted cybersecurity initiative. The two models having the same API-ID pattern (claude-fable-5 / claude-mythos-5) makes them look like a dropdown swap. They’re not. One’s a public endpoint, the other’s a permission.

Safeguards and fallback behavior

Now the part that actually changes your code.

Classifiers for sensitive domains

Fable 5’s headline integration change is that it can say no. From the API docs: Claude Fable 5 includes safety classifiers that can decline requests. Claude Mythos 5 does not include these classifiers. The blocked domains are the heavy ones — TechCrunch listed cybersecurity, biology, chemistry, and distillation as areas where the model blocks responses.

When a refusal happens, you don’t get an error. You get a normal HTTP 200 with stop_reason: "refusal", and the response tells you which classifier fired. That’s a deliberate design choice and it matters for how you handle it — a refusal is a successful response that happens to contain no useful output.

Fallback to Opus 4.8 as a routing concept

Here’s the elegant bit. When Fable 5 declines, the blocked query doesn’t just die — many of them get served by Opus 4.8 instead. Anthropic’s docs describe it this way: many queries on sensitive topics will instead receive a response from our next-most-capable generally available model, Claude Opus 4.8.

Conceptually, think of it as a two-layer system: Fable 5 for the frontier work, Opus 4.8 as the safe catch for anything Fable 5 won’t touch. The benchmark asterisks I mentioned earlier? That’s this exact mechanism showing up in the numbers.

Keep implementation details for the fallback guide

I’m deliberately not going deep on the how here, because there’s a dedicated guide for it and cramming SDK middleware and the fallbacks parameter into a comparison post would be doing both topics badly. At a concept level: you can let the server retry for you, retry from the client, or build it manually. The exact stop_reason handling, the beta fallbacks parameter, the SDK middleware setup — that’s all in Anthropic’s refusals and fallback documentation, and you should read it there rather than from my paraphrase.

Production routing design

If you’re designing a real pipeline, three things deserve thought.

Policy-aware model selection

Pick your model based on what the workload actually does, not on the benchmark leaderboard. General production traffic → Fable 5. Cybersecurity or biology research with proper approval → Mythos 5, if you have access. Lower-cost or fallback path → Opus 4.8. The decision is about policy and access, not “which scored higher on SWE-Bench.”

Fallback API design at a high level

Design for refusals as a normal branch, not an exception. Since a refusal returns 200, your error handling won’t catch it — you have to check stop_reason explicitly and route accordingly. Decide up front whether you want server-side retry (less code, currently in beta) or client-side control (more flexibility, works anywhere). One judgment I landed on: if you care about which model answered for audit reasons, client-side gives you cleaner control. If you just want an answer, server-side is fewer moving parts.

Audit logs and data retention

This one surprised me. Both Fable 5 and Mythos 5 carry 30-day data retention and are not available under zero data retention — they’re designated Covered Models. The GitHub changelog spelled out the reasoning during its (now-suspended) Copilot rollout: Anthropic retains prompts and outputs for up to 30 days to operate safety classifiers that detect harmful or abusive use, after which it deletes them, and the retained data isn’t used for training. This is not a hypothetical compliance worry, either: it’s exactly the clause that made Microsoft block the model for its own staff. If your compliance posture assumes ZDR across all models, this breaks that assumption. Check it before you ship. Anthropic’s data retention documentation is the source of truth here, and you should confirm against it rather than my summary — retention rules are exactly the kind of thing that gets updated quietly.

Which model should builders plan around?

Short answer: Fable 5, for almost everyone— with the loud asterisk that “plan around” assumes access comes back; right now nobody’s routing live traffic to either model.

Default to Fable 5 for general production use

It’s generally available, it’s the most capable model Anthropic has put in front of the public, and the safeguards mostly affect domains general products don’t touch anyway. For software engineering and knowledge work — Anthropic’s own framing of Fable 5’s strengths — the classifiers rarely get in your way. The performance is real, too: Stripe reportedly had Fable 5 do a codebase-wide migration in a day that would otherwise have taken a whole team over two months on a 50-million-line Ruby codebase. That’s the kind of number I’d normally be skeptical of, but it’s coming through Anthropic’s launch material with a named customer, so take it as a vendor-reported data point.

Treat Mythos 5 as restricted-access specialized capacity

Don’t architect around Mythos 5 unless you’re already in Project Glasswing. It’s not a model you “upgrade to.” It’s specialized, unguarded capacity for vetted cybersecurity and biology research, and the access path runs through an account team and an approval process. For most builders it should be invisible.

Keep Opus 4.8 as a fallback or lower-cost route

Opus 4.8 has two jobs in this world: it’s the safe catch when Fable 5 refuses, and it’s a cheaper, still-very-capable option when you don’t need the frontier. Per Anthropic’s models overview, it remains a current production model. Keeping it in your routing isn’t a downgrade — it’s the backstop the whole fallback design leans on. And during the current Fable/Mythos suspension, it’s not just the backstop — it’s the only one of the three still answering, which is its own argument for never building a pipeline that only knows how to talk to Fable 5.

FAQ

What is the difference between Claude Fable 5 and Mythos 5?

They share the same base model and capabilities. Fable 5 includes safety classifiers that can decline requests in high-risk domains and is generally available. Mythos 5 has those classifiers removed and is restricted to approved Project Glasswing partners. Access and safeguards differ; raw capability doesn’t. For the authoritative, current definition, check Anthropic’s official model documentation — this is a fast-moving area. (As of mid-June 2026, both models are temporarily suspended — verify current availability before you rely on either.)

Does Fable 5 automatically fall back to Opus 4.8?

It can, but “automatically” depends on how you build it. When Fable 5 refuses, the request can be served by Opus 4.8, and Anthropic offers server-side, client-side, and manual ways to handle that retry. The server-side fallbacks parameter is in beta. The implementation specifics live in the official fallback guide, and you should follow that rather than wiring it from memory — please confirm against the latest official documentation.

Can developers disable Fable 5 safeguards?

No. The safeguards are not a toggle you can turn off. Mythos 5 — the version without classifiers — is a separately gated model available only to vetted partners through Project Glasswing, not a setting inside Fable 5. There is no supported way to remove or bypass Fable 5’s classifiers, and you shouldn’t try. For the current policy, defer to Anthropic’s official documentation.

Which model should API builders use by default?

Claude Fable 5. It’s generally available, it’s the most capable widely released Claude model, and its safeguards rarely interfere with general software and knowledge work. Keep Opus 4.8 in your routing as a fallback and lower-cost path. Treat Mythos 5 as out of scope unless you’re approved for Project Glasswing. As always, verify availability and pricing against the official docs before you commit. And right now, “by default” is academic: with Fable 5 suspended, Opus 4.8 is what’s actually serving traffic.

Conclusion

The whole Claude Fable 5 vs Mythos 5 question collapses into one fact: same model, different rulebook. Fable 5 is the one you’ll actually build on — public, capable, guard-railed in the places that matter. Mythos 5 is restricted capacity for a specific kind of approved work most of us will never touch. And Opus 4.8 quietly holds the whole thing together as the fallback.

So here’s what I’d do next if I were you: pull up the official model and refusals docs, decide whether server-side or client-side fallback fits your stack, and check whether the 30-day retention changes anything in your compliance story. That last one is the trap most people will miss. And before any of that: check whether Fable 5 is even back online yet, because as of this writing it isn’t. The fastest-moving variable in this whole comparison turned out to be the one I least expected — not the safeguards, not the fallback logic, but whether you can reach the model at all.

That’s where my notes end. I haven’t run the fallback path under real load yet — that’s next week’s problem. To be verified.

Previous posts: