Claude Fable 5 and Claude Mythos 5, launched June 9, 2026, are the same underlying model. What separates them isn't training, capability, or weights. It's a classifier layer that sits in front of one of the two products and decides, per request, whether it runs at full capability or gets rerouted to a different model entirely.
That's a distinct engineering approach from how most labs handle model safety, and it's worth understanding at the mechanism level, because it changes how you build against the public version of this model.
The split
Fable 5 and Mythos 5 are the same model. Anthropic says this directly and repeatedly, down to the naming: fable comes from the Latin fabula, "that which is told," a deliberate cousin of the Greek mythos. The only thing that distinguishes them is what happens after you send a request.
Mythos 5 has no safety classifiers. It's restricted to Project Glasswing, a vetting program run in collaboration with the US government for cyber defenders and critical infrastructure providers, plus an incoming trusted-access track for biomedical researchers. If you're not in one of those programs, you don't get Mythos 5, full stop.
Fable 5 is generally available on the API, Claude Code, AWS, Google Cloud, and Microsoft Foundry, and it wraps the same model in a set of classifiers that watch every request for three categories of risk: cybersecurity, biology and chemistry, and distillation attempts (systematic efforts to extract Claude's capabilities to train a competing model). When one fires, the request doesn't get refused. It gets rerouted, live, to Claude Opus 4.8, and the user is told the handoff happened.
The gate isn't capability, it's who's asking and what they're asking for. Same weights on both sides.
What "classifier" actually means here
Anthropic's writeup for Fable 5 says the classifiers are "an extension" of prior published work, referring to a research line called Constitutional Classifiers. It's worth unpacking that lineage, because "classifier" undersells what's actually a fairly involved detection system, and the architecture explains several of the behaviors covered below.
The core idea, going back to the original Constitutional Classifiers work, is training a separate model to watch a conversation for harmful content, using training data generated from a "constitution": natural-language rules describing what's allowed and what isn't (help with college chemistry homework, don't help synthesize Schedule 1 chemicals). That first version cut jailbreak success rate from 86% down to 4.4% against an unguarded model, but at real cost: it added 23.7% compute overhead and pushed the refusal rate on harmless queries up by 0.38%, a meaningful hit to usability at scale.
The next-generation system Anthropic describes in a January 2026 paper, informally called Constitutional Classifiers++, is a genuinely different architecture, and it's almost certainly the one running in front of Fable 5:
It evaluates the exchange, not the input or output in isolation. The original system scored inputs and outputs separately, which turned out to be a real weakness. An attacker could get a harmful output to look benign by encoding it: instructing the model to substitute chemical reagent names with something like "food flavorings," so the output classifier sees nothing alarming on its own. The exchange classifier instead evaluates the output in the context of the input that produced it, which cut successful jailbreaks by more than half in human red-teaming, at the cost of a 50% increase in compute versus the input/output split.
It runs as a cascade, not a single pass. To recover the compute cost of the exchange classifier, Anthropic added a cheap first-stage screen that looks at all traffic, and only escalates flagged exchanges to the expensive, more accurate second-stage classifier. This is the direct explanation for why Fable 5's fallback rate can sit under 5% of sessions without adding meaningful latency to the other 95%: most traffic never reaches the expensive stage.
Two things worth noticing in this flow. First, the expensive stage only runs on a minority of traffic, which is what keeps the system affordable at scale (roughly 1% compute overhead in Anthropic's reported deployment). Second, escalation isn't the same as refusal: a flagged exchange gets a second opinion before anything is blocked or rerouted, which is why the first-stage probe can afford to be trigger-happy without translating into a high refusal rate.
Part of the detection happens inside the model's own activations, not on its text output. This is the most interesting piece and the easiest to miss if you only read the Fable 5 launch post. Anthropic built probe classifiers that read the model's internal activations directly, the same intermediate computations the model produces while generating a response, before any output token exists to classify. The premise is that something like a "this seems harmful" signal fires internally before the model has even settled on how to respond. These probes are cheap (they reuse computation the model was doing anyway), harder to fool than output-based classifiers (you can manipulate a model's output much more easily than its internal representations), and Anthropic found them to be complementary to the external classifiers, catching some things the exchange classifier misses and vice versa.
Put together, the production system Anthropic describes is: a linear probe on internal activations screening all traffic, escalating to a probe-classifier ensemble for exchange-level judgment when something looks suspicious. In one month of deployment on Claude Sonnet 4.5 traffic, this cut the harmless-query refusal rate to 0.05%, an 87% drop from the original system, while adding roughly 1% compute overhead.
This matters for reading the Fable 5 numbers correctly. When Anthropic says its cybersecurity classifiers "prevent Fable from making any progress" on offensive cyber evals, or reports zero compliance across 30 jailbreak techniques, that's not a single filter catching keyword matches. It's a multi-stage system checking activations before generation, then checking the full exchange after, with two independent detection surfaces that have to both be evaded for an attack to get through undetected.
Where it still breaks. Anthropic is explicit that this generation is not attack-proof, and names two specific failure classes from its own adversarial testing. Reconstruction attacks split a harmful request into pieces that look benign individually, then have the model reassemble them, for instance hiding a harmful query as fragments scattered through unrelated code. Output obfuscation attacks get the model to disguise its own output, using substituted terminology or metaphor so a harmful response reads as harmless on its face. Anthropic's own data shows these attacks don't just evade detection cheaply, they also degrade the model's actual capability, sometimes sharply: performance on a PhD-level science benchmark dropped from 74% to as low as 32% under some jailbreaking approaches, though the drop varied a lot by attack type. That variability is itself a flag, since it implies unseen attack strategies could preserve more capability while still evading detection.
What actually happens at the API level
This isn't just a product-positioning distinction, it changes how you build against it. A few mechanics worth knowing if you're integrating:
Refusals return HTTP 200, not an error. When Fable 5's classifiers decline a request, the Messages API returns stop_reason: "refusal" as a successful response. It also reports which classifier fired. If your error handling assumes a refusal looks like a failed request, it won't.
There are three ways to retry on Opus 4.8. Server-side, via a fallbacks parameter (beta). Client-side, via SDK middleware. Or manually, built yourself. Anthropic ships a fallback-credit mechanism specifically so you're not charged twice for the prompt cache when a request bounces from Fable to Opus.
Adaptive thinking is the only thinking mode, and raw chain-of-thought is never returned. You get either a summarized version of the reasoning or nothing, controlled by thinking.display. This is true for both Fable 5 and Mythos 5, independent of the classifier question, but it's a Fable-specific change from earlier models worth knowing about if you're piping thinking output anywhere.
Both models are Covered Models with mandatory 30-day retention. Neither is available under zero data retention. Anthropic frames this as needed to catch attacks that operate across many requests, not single exchanges, and says the data won't be used for training and will be deleted after 30 days with logged human access in almost all cases.
Worth noting for anyone architecting around this model: access to both Fable 5 and Mythos 5 was briefly suspended in June 2026 under a US export-control directive, unrelated to the classifier architecture above, before being restored. It's a separate mechanism from the safety classifiers, but it's relevant to the same underlying question, since a model whose dual-use profile is significant enough to need a classifier layer is also a model whose dual-use profile puts it within scope of export controls in the first place.
Classifier coverage and what's still self-reported
The classifiers are tuned conservatively by design. Anthropic states directly that coverage on biology and chemistry is narrower than the company considers ideal, a deliberate tradeoff of shipping speed for precision. The reasoning given: a well-resourced actor seeking biological uplift is a bigger risk than a review process that occasionally blocks a legitimate researcher, so the safeguards over-block at launch and narrow from there.
Worth flagging for anyone citing the launch numbers: the under-5%-of-sessions fallback rate, the zero-compliance result across 30 jailbreak techniques in one partner's testing, and the 1,000+ hours of bug-bounty testing with no universal jailbreak found are all Anthropic-reported figures. They're specific and falsifiable, which is a meaningfully higher bar than most safety marketing clears, but they haven't yet been reproduced by an independent third party as far as I could find. That's a distinction worth carrying into how you weight the claim, not a reason to discount it.
What this architecture actually decomposes
Strip away the launch framing and the classifier system is answering a specific engineering question: instead of training one model to refuse a class of requests outright, split "what can this model do" from "who is asking and why," and build separate machinery for each. The model stays at full capability. The access layer carries the risk decision.
Anthropic's own testing gives some texture on where that layer currently sits: no universal jailbreak in over 1,000 hours of external bug bounty testing, no universal jailbreak found by independent red-teaming orgs on long-form agentic tasks, and one partner (the UK AISI) reporting partial progress toward one within a short initial testing window. That's the kind of detail worth tracking as the classifiers get updated post-launch, since Anthropic has said explicitly that narrowing the biology and chemistry coverage is an active work item, not a finished one.
For anyone integrating against claude-fable-5, the practical takeaway is that the classifier layer is a live, versioned system, not a static gate. Refusal rates, fallback behavior, and coverage boundaries are things to monitor over time rather than assume are fixed at today's numbers.
Sources: Anthropic's Fable 5 and Mythos 5 launch announcement, the Claude Platform documentation for API mechanics, Anthropic's next-generation Constitutional Classifiers research post for the classifier architecture, and Anthropic's suspension and restoration statements.