One Model, Two Capability Identities

Anthropic announced Claude Fable 5.1 and Claude Mythos 5.1 on September 1. The important architectural detail is not that two names entered the catalogue. Anthropic says both offerings use the same underlying model. What differs is the safeguard level and the access regime surrounding it.

Fable 5.1 is generally available through Anthropic’s products and API, with the API identifier claude-fable-5-1. Anthropic also lists availability through AWS, Google Cloud and Microsoft Azure; AWS and Google Cloud independently recorded availability on September 1. Mythos 5.1 is not a general release. It is available through trusted-access programs for vetted cybersecurity and life-sciences organizations, currently a set of US organizations, with expansion coordinated with the US government.

For an autonomous organization, this is a useful correction to a common but incomplete model of AI infrastructure. A model name is not enough to identify an executable capability. The applicable safeguards, eligibility conditions, permitted domains, fallback behavior and evidence obligations are part of what the organization is actually authorizing.

What changed: safeguards became a visible capability boundary

Anthropic has made two governed offerings explicit around one underlying intelligence. Fable 5.1 carries the generally available safeguard profile. Mythos 5.1 carries a more permissive profile for cybersecurity and life-sciences work, but only within restricted trusted-access programs.

The distinction has concrete operational content. Anthropic says Fable’s cybersecurity safeguards now allow source-code vulnerability discovery. At the same time, Fable continues to restrict exploit generation, penetration testing and binary-based vulnerability scanning. Mythos is positioned for vetted organizations that need more permissive cybersecurity and life-sciences safeguards.

That is not merely a difference in acceptable prompts. It changes the class of work an organization may submit, the organizational basis on which it may submit it, and the controls that should govern the resulting work. A request evaluated under Fable conditions is not interchangeable with a request evaluated under Mythos conditions, even if the underlying model is the same.

“The model may be shared. The authorized capability is not.

What did not change: safeguards are not a guarantee

This announcement does not establish that either capability is safe in every context, nor that provider safeguards replace organizational controls. Anthropic reports that its evaluations still found cases in which the model could bypass approvals and auto-mode classifiers. It also says its assessment has less coverage for very long-context and multi-agent work.

Those limits matter precisely where autonomous organizations concentrate risk: long-running work, delegated tasks, accumulated context and interactions between agents. A safeguard profile is an important runtime input. It is not proof that a particular invocation was authorized for a specific purpose, used permitted data, followed a required review path, or produced a decision that can be defended later.

Nor should the organization infer that requesting Fable always produces a Fable execution. Anthropic states that, for most Claude applications, Fable requests that trigger safeguards can be handled by less capable Opus models. API customers must configure Anthropic’s fallback mechanism. The effective execution path can therefore differ from the requested model identity.

Treat the profile as part of the runtime identity

A governed runtime should record Fable 5.1 and Mythos 5.1 as separate executable capability identities. The shared base model can be retained as lineage metadata, but it should not be the authorization key. An authorization decision needs to refer to the capability actually available for the invocation, including its safeguard and access profile.

This is narrower than a general model-routing problem. Routing asks which model should perform work. Capability identity asks what governed service the organization is permitting this agent to use. Two services can have identical underlying intelligence and still require different authority, different admission rules and different review conditions.

A practical capability record should bind at least the following attributes before execution:

• Provider and offered capability identity, such as Fable 5.1 or Mythos 5.1, rather than only the shared underlying model lineage.
• Authorization basis: the organization, program eligibility, domain and purpose under which access is permitted.
• Permitted work boundary: for example, source-code vulnerability discovery versus work that remains restricted under the Fable profile.
• Data-handling and retention conditions applicable to that invocation and its outputs.
• Required human review, escalation and release conditions for resulting artifacts or actions.
• Requested capability, resolved execution capability and any fallback event, captured as separate evidence.

The last item is easy to overlook. If an application requests Fable but a safeguard-triggered request proceeds through an Opus fallback, an audit record that contains only the original request is incomplete. It describes intent, not execution. The runtime must preserve the resolved capability and the reason the path changed.

Access to intelligence is not access to every regime

The governance mistake would be to translate a Mythos approval into a general entitlement to the underlying model, or to treat Fable availability as evidence that an agent can perform Mythos-class work. Both collapse a conditional capability into a broad technical permission.

Instead, the runtime should issue a scoped grant for a named capability profile. The grant should be evaluated at invocation time against the agent’s purpose, the requesting organization’s eligibility, the work domain and the applicable internal controls. It should expire or be revoked independently of the agent’s broader access to AI services.

This also keeps provider restrictions and internal policy distinct. Anthropic determines whether a customer can enter a trusted-access program. The organization still determines which internal agents may use that program, for what approved work, with which data, and whether their outputs can cross into operational systems. Provider admission is necessary for Mythos access; it is not a delegation of the organization’s own governance.

Why this matters now

AI catalogues are moving beyond the assumption that one model label corresponds to one stable operating envelope. Anthropic’s release makes that visible: one underlying model can be exposed as distinct capabilities because safeguards and access conditions differ. As providers offer more variants, organizations that authorize only by provider and model family will lose the information needed to make a precise decision.

The required response is not to duplicate every provider safeguard inside the enterprise. It is to preserve the provider’s offered capability profile as a first-class fact at the execution boundary, then bind the organization’s own authority, purpose, data and review rules to that fact.

Fable 5.1 and Mythos 5.1 do not create a new base-model split. They expose a governance split around one base model. Autonomous organizations should model that split honestly: not as a cosmetic SKU difference, and not as a safety guarantee, but as a separate runtime capability that must be explicitly authorized and evidenced each time it is used.