claude-fable-5-1 keeps Fable 5's headline price and adds a cache-read discount, a mid-conversation effort switch, and a watermark you cannot turn off — this is what Anthropic's own documentation says a builder needs to know before shipping against it.

Fable 5.1 keeps Fable 5's sticker price; everything that changes about what a build actually costs lives in the cache-read line, not the headline number. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
This is a practitioner's guide to Claude Fable 5.1 as Anthropic's own developer documentation specifies it on the day of release, not as the launch narrative, access-governance story, benchmark comparison, or safety-measures analysis that sit alongside it in this series. It works through the API model ID and its relationship to Fable 5, the pricing mechanics behind the 25%-typical and up-to-45%-agentic cost-reduction claims, the five effort levels and their per-surface defaults, the new beta mid-conversation effort switch and what it trades against prompt caching, the documented context window and output ceiling, availability across the Claude API and three cloud marketplaces, the phased rollout of Enterprise Frontier Safeguards and zero data retention, the EU AI Act watermark and its private-preview Detection API, and the breaking changes a team migrating from Fable 5 needs to handle before it ships. It closes with a worked cost example built entirely from the prices this article verifies.
Anthropic shipped Claude Fable 5.1 and Claude Mythos 5.1 today, and the announcement post leads with the same sentence every point release leads with: better results, similar price [1]. That sentence is true and also not the thing a builder needs to act on. What actually changes an integration is smaller and more mechanical than a launch post has room for: one price line moved, one parameter grew a mid-conversation mode, one header became mandatory to keep a cache warm, and three request shapes that worked against Fable 5 now return a 400. This is a guide to those mechanics, sourced from Anthropic’s own developer documentation as it reads today, 1 September 2026 — not from the launch narrative, not from how Fable 5.1 compares against competing benchmarks, not from the governance question of who gets access to Mythos, and not from an analysis of the safety architecture behind the refusal classifiers. Those are the other four pieces in this series. This one is about what changes in your code and your bill.
Claude Fable 5.1’s Claude API model ID is claude-fable-5-1, documented plainly as the successor to Claude Fable 5 (claude-fable-5) for “long-running agentic coding, knowledge work, and research” [4]. Claude Mythos 5.1 (claude-mythos-5-1) shares its capabilities, pricing, and API surface, restricted to Project Glasswing participants — the same access-governed pattern Fable 5 established with Mythos 5, and out of scope for this article beyond noting it exists [4] [2]. The documentation is explicit that Fable 5.1 is not the model most builders should reach for first: “start with Claude Opus 5 for most workloads… use Claude Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Claude Opus 5 at higher effort still fall short” [4]. That framing matters for anyone deciding whether this release is the one to integrate against, and it is worth taking at face value rather than reading as false modesty — Fable-class pricing is double Opus 5’s on every token category, and the models overview page lists Fable 5.1 with the slowest comparative latency in the current lineup [6].
Fable 5.1’s base rates are unchanged from Fable 5: $10 per million input tokens, $50 per million output tokens, documented identically on the models-overview comparison table and the dedicated pricing page [6] [3]. Five-minute cache writes are $12.50 per million tokens (1.25x base input) and one-hour cache writes are $20 per million tokens (2x base input), also unchanged [3]. The number that moved is cache reads. On every other current Claude model, a cache hit costs 0.1x the base input price. On Claude Fable 5.1 and Claude Mythos 5.1 specifically, it costs 0.025x — $0.25 per million tokens against Fable 5’s $1.00, a 75% cut documented as its own line in the pricing table with a footnote calling out the model-specific multiplier explicitly [3] [4].
That single multiplier is the entire mechanism behind the launch post’s headline cost claim: “around 25%” savings on typical workloads and “up to around 45%” on highly agentic ones, relative to Fable 5 [1]. Both figures are the same lever applied at different intensities, and the intensity depends on how much of a request’s input tokens are cache reads rather than fresh input. A one-shot request with no cached prefix sees none of this saving — its cost is identical to Fable 5’s, because base input and output prices didn’t change. A long agentic session that re-reads a large, mostly-static system prompt and tool-result history on every turn can push cache reads to a large share of total input tokens, and it is exactly that shape of workload — extensive context reuse, repeated tool operations — that the reporting on the announcement identifies as driving the top end of the range [9]. The practical implication: this is not a price cut you get by upgrading the model string. It is a price cut you get by having prompt caching correctly configured and by running workloads that actually hit the cache — the same operational discipline that mattered on Fable 5, now paying off at four times the rate on the read side.

Figure 5. Cache reads at a quarter of Fable 5's rate change the arithmetic on any workload that re-reads a long prefix — the saving shows up in the total, not in either headline number. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
Batch processing is $5 per million input tokens and $25 per million output tokens, the standard 50% discount applied to Fable 5.1’s base rates, and it stacks with the cache-read multiplier the same way it does on every other model [3].
Fable 5.1 supports all five documented effort levels — low, medium, high, xhigh, max — set through output_config.effort on the Messages API, with no beta header required for the top-level parameter [5]. The API default across the board is high, and the documentation states plainly that “setting effort to high produces exactly the same behavior as omitting the parameter entirely” [5]. Where the defaults actually diverge is by product surface rather than by API default: Claude Code holds high as its baseline, while Claude Cowork and claude.ai default to medium [1]. A team that only ever calls the raw Messages API sees one default; a team building on top of Claude Cowork inherits a different, cheaper one without changing a line of integration code.
The per-model guidance for Fable 5.1 is direct about which direction to move from that default: “start with high… step up to xhigh or max for the most capability-sensitive agentic and coding work, and step down to medium or low for routine or latency-sensitive work once your evals show quality holds” [5]. That last clause is doing real work — Anthropic’s own recommendation for Fable 5 already stated that “lower effort settings… still perform well and often exceed xhigh performance on prior models” [5], and the announcement’s specific claim for the point release is narrower and testable: at low or medium effort, Fable 5.1 “achieves similar or better results than Fable 5 at a much lower cost,” with “much higher performance at higher effort tiers” for workloads that need it [1] [10]. Practically, that is an argument for running an effort sweep against your own evals before assuming high is buying you anything medium doesn’t, precisely because effort is priced through total token spend — thinking, tool-call arguments, and response text all inflate together at higher effort — not through a separate line item [5].

Figure 1. Five effort levels, one parameter — the documented default is high everywhere except Claude Cowork and claude.ai, and Fable 5.1 is the first model that lets a session change level without losing its cache. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
What’s genuinely new on this model, not carried over from Fable 5, is per-message effort: a beta feature that lets a conversation change effort level mid-session without invalidating the prompt cache. It requires the beta header mid-conversation-output-config-2026-07-01 and works by appending a role: "system" message with empty content and a new output_config.effort value; the change takes effect from the next user turn and holds until altered again [4] [5]. This solves a real friction point: on every model without per-message effort — including Fable 5 itself — changing the top-level effort value between requests restarts the cache, because effort shapes the rendered prompt [5]. A long Fable 5 session that wanted to spend high effort on a hard step and low on routine follow-ups had to choose between holding one level for the whole conversation or eating a full cache-cold request every time it switched. On Fable 5.1, Claude Mythos 5.1, and Claude Opus 5, that trade-off is gone for the beta path, and the documentation recommends it explicitly over toggling the top-level parameter: “its earlier replies were written at the previous level, and it tends to stay consistent with them” [5]. Two things to build against carefully: it is beta-gated, so a production integration needs the header on every request that intends to use it, and models that lack support — Fable 5 included — return a 400 reading output_config.effort requires a model that supports per-turn effort; this model does not if the header is sent anyway [5].
Inside Claude Code specifically, effort is configurable through the /effort command, the --effort flag, the CLAUDE_CODE_EFFORT_LEVEL environment variable, or a per-model entry in the settings file, and Fable 5.1 is documented as the first Fable-tier model with no session-level effort “hold” — earlier models including Fable 5 and Opus 4.7 lock in whichever effort level a session first uses and keep it across later sessions until explicitly changed, while Opus 5 and Fable 5.1 carry no such hold [8]. Fable 5.1 is also not selected by default on any plan or provider inside Claude Code; it has to be named explicitly through /model fable, --model fable, or the ANTHROPIC_DEFAULT_FABLE_MODEL environment variable [8].
Fable 5.1 carries a 1,000,000-token context window — both the default and the maximum, priced at the standard per-token rate across the full window rather than stepping up past a threshold — and a 128,000-token ceiling on output per request, identical to Fable 5’s documented specs [4] [6]. Both figures come directly from Anthropic’s models-overview comparison table and the dedicated Fable 5.1 release notes; press coverage of the launch repeats the same 1M/128K figures, so there is no divergence to flag between primary and secondary sourcing here [6] [9]. One documentation detail worth carrying into a token budget: the tokenizer introduced with Opus 4.7 and carried into Fable 5 and Fable 5.1 produces roughly 30% more tokens for the same text than the tokenizer used by Sonnet 4.6 and earlier models, which changes both the effective context window in words (roughly 555,000 words per million tokens on the current tokenizer, against roughly 750,000 on the previous one) and the token count a migrating integration should expect for identical prompts [6] [3].
Claude Fable 5.1 is available to all customers on the Claude API as claude-fable-5-1, on Amazon Bedrock as anthropic.claude-fable-5-1, on Google Cloud as claude-fable-5-1, on Claude Platform on AWS as claude-fable-5-1, and on Microsoft Foundry running on Anthropic’s own infrastructure [4]. That is a same-day four-surface release with no staggered rollout documented for the base model — a contrast worth noting against Mythos 5.1, which remains gated to Project Glasswing participants and requires going through an Anthropic, AWS, or Google Cloud account team for access [4]. Pricing on the Claude API and Microsoft Foundry follows the standard per-token rates above; Bedrock and Google Cloud are partner-operated and billed independently through their own marketplace pricing pages, and Claude Platform on AWS and Foundry both convert standard token pricing into Claude Consumption Units for marketplace billing rather than a flat per-token invoice [3].
Fable 5.1, like Fable 5, is a Covered Model carrying 30-day data retention by default and is not available under zero data retention “unless expressly authorized by Anthropic” [4]. What changed today is the path toward broader ZDR eligibility: Anthropic’s Enterprise Frontier Safeguards (EFS) combines zero-data-retention privacy with misuse-detection monitoring that runs on data stored in the customer’s own cloud infrastructure rather than Anthropic’s, so an organization keeps its own encryption keys, access policies, and audit logs while automated safety flags route directly to the customer rather than to an Anthropic reviewer [7]. EFS is documented as rolling out in phases starting “later this fall,” across Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry, and Anthropic states it will not separately charge for the feature — customers pay only their own cloud provider’s standard storage and egress costs [7]. As an interim bridge before EFS is generally available, eligible customers get zero data retention on both Fable 5 and Fable 5.1 now [7] [9]. For a builder evaluating Fable 5.1 for a workload with hard data-retention requirements, the practical read is: this is a near-term “ask your account team” situation, not a self-service toggle in the Console, and the 30-day-retention default remains the documented baseline until an organization is enrolled.

Figure 4. The watermark ships on by default and cannot be switched off; the Detection API that reads it back is still a private preview, not a general-purpose endpoint. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
Text generated by Claude Fable 5.1 and Claude Mythos 5.1 carries Anthropic’s statistical text watermark on every platform where the model runs, and the documentation is specific about what that does and doesn’t touch: “it doesn’t change the meaning, quality, or readability of the output. It adds no tokens or hidden characters, carries no information about you or your organization, and needs no changes to your requests or responses” [4]. It is on by default and not something a request can opt out of. Alongside it, Anthropic is rolling out a Detection API in private preview, scoped at launch to “regulators, law enforcement, media, researchers, educational organizations, and compliance-obligated enterprises,” with broader access planned but not yet available [1] [10]. Separately, images and video Claude produces through the code execution tool carry signed C2PA Content Credentials when retrieved through the Files API on the Claude API [4]. For a developer building anything that needs to prove or disprove Fable 5.1 authorship of a piece of text — content-moderation tooling, an academic-integrity workflow, downstream compliance under the EU AI Act’s transparency obligations — the state today is: the watermark exists and is universal, but the tool to read it back is not yet a general-purpose endpoint you can integrate against; it’s an access-request process.

Figure 2. The 75% cache-read cut, not the unchanged headline price, is what produces the documented 25%-typical and up-to-45%-agentic savings — and it only pays off on requests that actually re-read a cached prefix. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
Anthropic’s own migration notes for this release are unusually specific about what is and isn’t safe to assume carries over, and they split cleanly into two categories [4].
Breaking. First, forced tool use is gone: tool_choice of type "any" or a named "tool" now returns a 400 invalid_request_error, because Fable 5.1’s thinking is always on and a forced tool call would skip it, pushing the model’s working-out into the tool arguments instead and degrading argument quality. The documented fix is to keep tool_choice: {"type": "auto"} and enforce schema validity with strict: true or structured outputs, and to steer tool use through prompt instructions rather than the parameter [4]. Second, thinking blocks are now bound to the model that produced them: Fable 5.1 can read thinking blocks from earlier models, but no earlier model — including Fable 5 — can read blocks Fable 5.1 produced, so a router or fallback path that moves a conversation off Fable 5.1 silently drops those blocks unless a beta header is set to report the drop explicitly [4]. Third, and the one most likely to bite an integration that builds its own messages array: editing anything before a Fable 5.1 thinking block — reordering an earlier turn, rebuilding the system prompt, injecting and later removing a status-line reminder — now invalidates every later thinking block in that conversation, enforced as a hard error for accounts created on or after 31 August 2026, and recorded-but-not-yet-enforced for older accounts [4]. The documented mitigation is to treat history as strictly append-only: move per-turn reminders to the new turn-scoped system messages, route system and tools changes through mid-conversation system messages instead of rewriting the arrays, and let server-side compaction or context editing do trimming instead of manual edits [4].
Additive and behavioral. Beyond per-message effort, two more beta features ship alongside: turn-scoped system messages, which clear themselves after one turn without touching earlier cached content, and a display: "updates" thinking setting that surfaces the model’s between-tool-call progress notes as visible text instead of the empty string produced by the default "omitted" setting [4]. On plain behavior, the release notes flag that Fable 5.1 tends to issue one tool call per turn in places Fable 5 batched several, writes fewer unprompted progress updates during long tool runs, answers from memory more readily at low effort instead of reaching for a retrieval tool, and is more likely to rewrite an entire file for a small edit rather than making a targeted change — each with a specific one-line prompting fix documented on the model’s prompting-guidance page [4]. None of these degrade output quality on their own; they change token spend and wall-clock time in an agent loop that was tuned against Fable 5’s habits, which is exactly the kind of regression a migration eval run catches and a spot-check does not.

Figure 3. Per-message effort is still a beta header, not a stable default — set it wrong and Fable 5.1 does what every other current Claude model does: it restarts the prompt cache on the next request. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.
Take a long-running coding session against Fable 5.1: a 400,000-token system-and-history prefix re-read via cache hit on each of 20 turns, plus 5,000 fresh input tokens and 3,000 output tokens per turn.
Per turn: cache reads cost 400,000 × $0.25 / 1,000,000 = $0.10; fresh input costs 5,000 × $10 / 1,000,000 = $0.05; output costs 3,000 × $50 / 1,000,000 = $0.15. Total per turn: $0.30, and $6.00 across the 20-turn session [3].
Run the identical session on Fable 5, where the only different number is the cache-read multiplier (0.1x instead of 0.025x): cache reads cost 400,000 × $1.00 / 1,000,000 = $0.40 per turn, pushing the per-turn total to $0.60 and the session to $12.00 [3]. That’s a 50% reduction on this specific cache-heavy shape — above the “up to 45%” ceiling the announcement quotes for agentic work, which is the expected direction given the example was built to isolate the cache-read line specifically rather than represent a blended real-world mix [1]. Drop the cached-prefix share to something closer to a typical one-shot-heavy workload — say 20,000 cached tokens and 20,000 fresh input tokens per turn instead of 400,000 cached — and the saving compresses toward single digits, because fresh input and output, which are unchanged from Fable 5, now dominate the bill. The 25%-to-45% range in the announcement is real, and this arithmetic is exactly why it’s a range rather than a single number: it tracks how much of a workload’s input tokens are cache reads, not anything about the workload’s difficulty or effort level [3] [9].
Four things from the above are worth treating as a pre-launch list. Point at claude-fable-5-1 explicitly rather than assuming an alias resolves to it — Fable 5.1 is not an account-type default on any surface, including Claude Code [8]. Audit tool_choice usage for "any" or named-"tool" values before switching models; they now fail closed rather than degrading silently [4]. If your integration builds the messages array by hand, run the documented history-editing check before relying on multi-turn thinking blocks, since the failure mode is a 400 that references a conversation-binding mismatch rather than anything obviously about your own code [4]. And before quoting the 25%-to-45% savings figure internally, measure what share of your own workload’s input tokens are cache reads — that ratio, not the model name, is what determines where in the range a given deployment actually lands [3] [1].
Originally published at https://absolutedigitalpublishers.com/articles/building-with-claude-fable-5-1-a-practitioners-guide.