The difference between Fable 5 and Mythos 5

A question worth answering plainly, because the setup invites suspicion

Two model ids, identical pricing, identical context window, identical everything on a spec sheet, and a name that sounds like it should mean something different — it's a completely reasonable reaction to assume one of them is a mistake, a legacy alias, or a downgrade dressed up as a separate product. None of that is true here, and it's worth saying plainly rather than letting the question linger unanswered: these are the same model, in every respect that shows up on a comparison table, reachable through two different doors.

What actually differs, and it isn't capability

The entire distinction between these two ids is the path you take to reach them. One is available through ordinary API access, open to any account with standard access. The other is gated behind a specific participant access programme and unavailable outside it. Neither carries different pricing, different limits, or different behaviour once you're actually sending requests — the difference lives entirely in eligibility, not in anything the model itself does differently.

Why a separate id exists at all, rather than one shared name

It would be simpler, on the surface, to have a single model id and just vary who's allowed to call it. That's not how this was built, and the practical reason is worth understanding if you're writing code that might route to either: a distinct id makes each one independently addressable and independently trackable in logs, billing, and access control, without requiring every system that touches model selection to also understand a separate, invisible access-tier flag layered on top of a shared id. Two ids is more explicit, even though it looks redundant from a pure capability standpoint.

The mistake this setup invites, and how to avoid it

The natural assumption, seeing two ids with this kind of relationship, is that one must be a fallback or a lesser option — and building routing logic on that assumption produces code that either wastes effort trying to prefer one over the other for no real reason, or worse, treats a failed request to one as a signal to silently degrade to some assumed-lesser alternative it doesn't actually need to degrade to at all. Code that might route to either of these ids should treat them as fully interchangeable for anything except the initial access decision.

What to actually do if you're choosing between them

If your organisation has access to the gated programme, either id works identically for planning and budgeting purposes — there's no capability reason to prefer one. If you don't have that access, the choice isn't really a choice: the standard, openly available id is simply the one you can use, and there's nothing being missed by not having the other available.

Why this is worth a whole post rather than a footnote

We considered folding this into a single line on each model's reference page and decided it deserved more room, because the confusion this setup causes isn't really about these two models specifically — it's a pattern worth recognising anywhere a product ships the same underlying capability through more than one access path. Assuming a difference in capability because there's a difference in access is a mistake that generalises well beyond this one pair of model ids.

What this pattern means if you're evaluating a fallback chain

If your systems build any kind of fallback logic across models, it's worth explicitly checking whether a candidate fallback is a genuinely different, lesser model or simply a differently-gated door to the exact same one — treating the two cases identically in your fallback design wastes an opportunity in the second case, where falling back doesn't actually cost you anything in capability terms at all, only in the access decision that got you there in the first place.

Why we're flagging this pattern rather than assuming it's obvious

It would be easy to assume anyone reading a model comparison table would immediately notice two rows with identical specs and draw the right conclusion unprompted. In practice, a spec table answers "what" without answering "why," and the why here — an access-tier distinction rather than a capability one — is exactly the kind of context a bare table can't convey on its own, which is the whole reason this got a dedicated explanation rather than being left to infer from the numbers alone.

See claude-fable-5 and claude-mythos-5 for both models' full specifications side by side.