Claude Fable 5.1: cheaper in the agent loop, stricter on data

Anthropic released Claude Fable 5.1 on 1 September 2026, together with Claude Mythos 5.1. By Anthropic's own account the two are the same model with different safeguard levels: Fable 5.1 is generally available, Mythos 5.1 is invitation-only through trusted access programmes. Trade press confirms the date and availability on all platforms from launch day.

The model id is claude-fable-5-1, on Amazon Bedrock anthropic.claude-fable-5-1. It ships through the Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS. Anthropic names Claude Code, Claude Enterprise and Claude Platform as surfaces, with different effort defaults: high in Claude Code, medium in Claude Cowork and on claude.ai. There is a retirement commitment: on Anthropic-operated platforms the model will not be switched off sooner than 1 September 2027, while Bedrock and Google Cloud set their own dates.

What Anthropic adds in the same documentation is worth noting. Fable 5.1 is described as being for demanding reasoning and long-horizon agentic work; as the default for most workloads Anthropic still explicitly recommends Claude Opus 5, with Fable 5.1 reserved for cases where Opus 5 at higher effort falls short. Anyone who has to justify the switch internally should know that sentence: the vendor itself does not recommend its new flagship across the board.

The headline figures come from Anthropic's model documentation and matter more to an architecture decision than any leaderboard.

Two of these deserve more than a table row. First, the thinking mode: Fable 5.1 thinks adaptively and continuously, and the older manual mode with thinking.type: enabled and budget_tokens is no longer accepted. Anyone porting an existing integration has to touch that code.

Second, the context window. One million tokens correspond to roughly 555,000 English words according to Anthropic, measured on the current tokenizer introduced with Claude Opus 4.7. That same tokenizer produces roughly 30% more tokens for the same text than its predecessor. A context window figure is therefore not a capacity statement that can be compared casually across model generations, let alone across vendors. What matters for budgeting is how many tokens your own body of text actually produces, not the headline.

This piece deliberately keeps performance figures short, because they are the subject of a separate comparison. Only this much, and explicitly as vendor-reported numbers: Anthropic reports 52.6% for Fable 5.1 on Terminal-Bench-Science 0.1 against 24.7% for Fable 5, and 55.8% on Terminal-Bench 4.0 against 42.0%. The comparison column in Anthropic's own table is GPT-5.6 Sol. OpenAI's current flagship GPT-6 Astra shipped two days after this release and does not appear in Anthropic's figures at all.

Anthropic's pricing documentation lists the following for Fable 5.1, in US dollars per million tokens.

Exactly one line is interesting. On Fable 5.1 and Mythos 5.1, cache reads are priced at 0.025x the input price, whereas every other Claude model uses a 0.1x multiplier. This is the sole pricing change versus Fable 5, whose cache read stood at 1.00 US dollars per million tokens. Input and output are unchanged. The full context window is billed at standard per-token rates; there is no long-context surcharge.

Anthropic puts the saving at approximately 25% versus Fable 5 for typical workloads, and up to approximately 45% for highly agentic work. That figure is important enough to read correctly: it is a modelled vendor estimate that comes entirely from the cache line, and it is not a price cut. If your requests rarely re-read the same context, you save nothing. If you run an agent loop that reads the same system prompt, the same codebase and the same tool definitions back a hundred times over, you save a great deal. The difference between those two cases is your cache hit rate, and only your own load profile knows it.

One more detail for the cost model: if inference is pinned to the United States via inference_geo: "us", a 1.1x multiplier applies to input, output, cache writes and cache reads.

Across the competitive field this cache line is the only real price difference at the frontier. OpenAI also lists 10 and 50 US dollars per million tokens for input and output on gpt-6-astra, but 1.00 US dollars for cached input. On cache reads Fable 5.1 therefore sits at a quarter of the price, which can be decisive in long agent loops. Everything else about that comparison, including which benchmark numbers are comparable at all, is covered in the separate piece.

As evidence of long-horizon autonomy Anthropic cites one unattended 38-hour run on a machine learning problem. Anyone planning to build on that should first read the list of API changes, because three of them break existing code.

Breaking changes versus Fable 5:

• Forced tool use returns an error.
• Earlier models cannot read Fable 5.1's thinking blocks.
• Editing earlier turns invalidates thinking blocks.

Additions:

• Per-message effort (beta).
• Turn-scoped system messages (beta).
• Readable progress updates between tool calls via display: "updates" (beta).
• The reduced cache read price.
• Content provenance marking.

Also relevant to agent architectures is the token overhead of the toolsets: computer_toolset_20260801 adds about 4,500 input tokens per request, browser_toolset_20260801 about 6,600. That is a base load incurred on every single request, and it belongs in every cost estimate. Fast mode, which exists as a research preview on Claude Opus 5 and Opus 4.8, is not available on Fable 5.1.

On the safety side, Anthropic reports that cybersecurity safeguards block 60% fewer false positives than before, and that biology safeguards fire 85% less often for benign requests related to elementary biology. At the same time whole classes of task remain excluded: penetration testing, exploit generation, binary-based scanning and biology research tasks are redirected to Opus models. Fable 5.1 can identify software vulnerabilities, while exploit generation stays restricted. New API accounts can also no longer manually edit prior context in multi-turn conversations; Anthropic states that this closes off a common, publicly documented distillation technique. For teams that rewrite conversation histories programmatically, that is a behavioural change with direct consequences for existing architectures.

This is where the engineering story parts company with the governance story. Anthropic's data residency documentation is unambiguous: the inference_geo parameter accepts exactly two values, global and us. Under current limitations it states in as many words that only those two are available. There is no EU inference region on Anthropic's first-party API.

The same holds for data at rest. A workspace geo is set when the workspace is created, cannot be changed afterwards, and the only available value is the US.

Two Anthropic sources appear to contradict each other here, and that deserves to be stated openly. The privacy help centre, last updated on 15 June 2026, says customer traffic may by default be routed to select countries in the US, Europe, Asia and Australia, and adds in the same text that data is stored in the US. The platform documentation, by contrast, knows only the two inference geos named above. The reconciliation lies in the distinction between routing and residency: global routing may transit Europe, but it is not a selectable guarantee that processing and storage take place in the EU. If you need such a guarantee, you will not find it here.

inference_geo itself is supported only from Claude 4.6 onwards; earlier models return a 400 error. It does not exist on Amazon Bedrock or Google Cloud, where the endpoint or inference profile determines the region. Microsoft Foundry instead offers a US Data Zone deployment type. The parameter is also unavailable through the OpenAI SDK compatibility endpoint.

The workable EU route therefore does not run through Anthropic but through a partner cloud. Bedrock and Google Cloud offer regional endpoints with guaranteed data routing, at a 10% premium over the global endpoints according to Anthropic's pricing documentation, and they set their own lifecycle dates. That also makes the widespread claim that Claude has EU data residency because it runs in Frankfurt half true and, in effect, misleading: Claude models can run in EU regions, but there the cloud provider is the data processor, not Anthropic. For the contractual construction that is precisely the difference.

The most inconvenient sentence in the whole documentation sits on Anthropic's page on API and data retention. It states of Claude Fable 5.1, Mythos 5.1, Fable 5 and Mythos 5 that these models require 30-day data retention and are not available under zero data retention unless expressly authorised by Anthropic. They are designated Covered Models.

In practice this means an organisation working under zero data retention today cannot simply switch Fable 5.1 on. It has to explicitly enable 30-day retention on a specific workspace, or the API answers with 400 invalid_request_error. That is not a configuration nicety but a decision that in many organisations has to pass data protection sign-off before the first line of integration code exists.

For completeness, Anthropic's commitments belong alongside it: retained data is, by its own statement, never used for model training without express permission, and conversation content is not retained by default outside the Covered Model exception.

Even organisations that already have zero data retention in place should know its boundaries, which are narrower than the name suggests.

• ZDR is enabled per organisation on request through sales and does not extend automatically to sibling organisations under the same account.
• It does not cover the Batch API, the Files API, code execution, Claude for Excel or the Claude Teams and Claude Enterprise product interfaces. Claude Code through Claude Enterprise with ZDR is the stated exception.
• CORS is unsupported for ZDR organisations.
• If a chat or session is flagged, Anthropic may retain inputs and outputs for up to two years, ZDR included.

The direction is therefore clear, and it runs against the pricing story. Fable 5.1 is cheaper in the agent loop than any other Claude model, and under strict EU data rules it is at the same time harder to adopt than the Claude models that are not on that list.

According to Anthropic, Fable 5.1 and Mythos 5.1 carry an invisible text watermark from launch day. Article 50 of the EU AI Act, which requires machine-readable marking of synthetic content, has applied since 2 August 2026. Anthropic applies the mark worldwide and not only in the EU.

Anyone planning to build the watermark into a review process should know Anthropic's own caveat, and it is stated plainly in the help centre: a detected mark indicates that the content may have been processed by Claude, is "not fully conclusive", and does not on its own confirm the full provenance of the content. It is not proof in a legal sense, and the expectation of establishing authorship with it goes beyond what the vendor itself claims. That is a notable constellation: the marking is a genuine feature of the model, and its evidential weight is qualified by the same company that offers it.

Access is a further constraint. The detection API is in private preview and open only to eligible organisations; those named are regulators, law enforcement, media, fact-checkers, researchers, educational bodies and EU civil society. A company that wants to check incoming text for this mark itself currently cannot do so by that route.

The surrounding regulatory frame, as the publishing bodies describe it: enforcement for general-purpose AI models has likewise applied since 2 August 2026, with fines of up to 15 million euros or 3% of global annual turnover for non-compliant providers of such models, whether or not they signed the Code of Practice. The European Commission's Code of Practice binds signatories to a published transparency template, a systemic-risk assessment methodology and a copyright compliance framework, with documentation retained for at least ten years. These obligations fall on the model providers. What follows from them for your own organisation depends on your role in the supply chain and is a question for your legal advisers, not for a trade article.

Taken together the release produces an unusually clear picture, precisely because the two stories point in opposite directions. Technically, Fable 5.1 is the cheaper choice for long agent loops in which the same context is read over and over. In regulatory terms it is a model you cannot even start without 30-day retention.

Four questions should therefore be answered before integration begins.

1. What is your cache hit rate really? The entire saving hangs on that single metric. Measure it against a real load profile before you budget for 25%.
2. Can your data protection sign-off live with 30-day retention? If not, Fable 5.1 is not an option until Anthropic expressly authorises otherwise, and the question cannot be engineered around.
3. Which endpoint does inference run through? If processing in the EU is required, the route runs via Bedrock or Google Cloud, at a 10% premium over the global endpoints, with the cloud provider as data processor and with its own lifecycle dates.
4. Is Opus 5 enough? Anthropic itself recommends Opus 5 as the default, and Opus 5 is not on the list of Covered Models. Part of the governance question described here does not arise there in this form.

None of this is an argument against Anthropic. Fable 5.1 is a strong model, the cache change is a real improvement for agentic work, and the fact that the inconvenient facts are cleanly readable in Anthropic's own documentation speaks for the vendor rather than against it. It is an argument for reversing the order: first settle the conditions under which your data may be processed, then choose the model. What Fable 5.1 actually delivers in daily work is covered in a separate piece on capabilities in practice; how it stands against GPT-6 Astra, in another.