Fable 5.2 is 20% cheaper, but check three things before you switch your agents to it
The price cut is the headline. The data retention policy, the cyber fallback and a stricter thinking-block check are what can break a pipeline.

Anthropic released Claude Fable 5.2 on 9 November, and it costs less than Fable 5.1: $8 per million input tokens and $40 per million output tokens, against $10 and $50. The API id is claude-fable-5-2, and it’s on every major platform. That’s the news. The part that decides whether you can use it on Monday is in the small print.
Three things can bite: a data retention requirement, a safety classifier that reroutes some requests to an older model, and a thinking-block check that now returns an error where Fable 5.1 let old accounts through. Each has a concrete test, and none takes long.
The price and the speed
The pricing page lists Fable 5.2 at $8 input, $10 for a five-minute cache write, $16 for a one-hour write, $0.20 for a cache hit and $40 output. Fable 5.1 is $10, $12.50, $20, $0.25 and $50. Every line is 20% lower. Fast mode, which Anthropic says generates tokens up to 2.5 times faster, is $16 and $80.
Anthropic also claims output is up to 30% faster than Fable 5.1 and that, at Medium effort, tasks finish in fewer tokens. Both are company claims from the announcement , and neither has an independent measurement yet. If you run long agent sessions, token counts per task are the number to compare, and your own task set is the only fair test.
The reported coding benchmarks are large jumps: 49.1% on FrontierCode 2.0 against 32.4% for Fable 5.1, and 69.9% on FrontierSWE v2 against 56.3%. Treat them as Anthropic’s figures. Anthropic’s own advice is more modest: start with Opus 5.5 for most coding and knowledge work, and move up to Fable only when a task needs it.
Claude Code moved your model for you
Claude Code 2.1.321, released the same day, makes claude-fable-5-2 the default Fable model with a 1M context window and $0.20 per million tokens for cache reads. Saved Fable 5.1 picks move to fable: straight away on Pro and Max, and on Team and Enterprise once your organisation allows it. The changelog gives the way back: /model claude-fable-5-1.
If a script or a CI job pins an alias, check what the alias resolves to now. A pinned id doesn’t move.
Check one: data retention
Fable models require data retention. In the Copilot changelog , GitHub says Anthropic keeps prompts and outputs to run safety classifiers, and that the data isn’t used for training. Copilot Business and Enterprise administrators must switch on a Fable 5.2 policy, which is off by default, and switching it on counts as acknowledging the retention.
Some enterprises have zero data retention for Fable through the end of the calendar year under a time-limited exemption. After that, continued use needs Anthropic’s Enterprise Frontier Safeguards, which runs the safety monitoring in the customer’s own infrastructure and is in private beta. Approval doesn’t turn the model on by itself.
If your code is under a no-retention contract, this is the first thing to settle, before anyone changes a model picker. Everything else in this article is secondary to it.
Check two: the cyber fallback
Fable 5.2 ships with classifiers for cyber and biology. Anthropic says they block about 55% fewer requests than Fable 5.1’s, around 60% fewer in cyber. Blocked cyber requests fall back to Opus 4.8, and blocked biology requests to Opus 5.
That fallback matters if your agent does security work: writing exploit proofs for your own services, fuzzing harnesses, binary analysis, penetration-test scripts. The announcement names penetration testing, exploit generation and binary-based vulnerability work as blocked categories. The announcement doesn’t say how a fallback shows up in the response, so a benchmark of “Fable 5.2 on our security tasks” may be measuring Opus 4.8 on some of them without telling you.
The unrestricted variant, Mythos 5.2, is limited to vetted organisations through the Cyber Verification Program. If you review code for vulnerabilities as part of normal work, that’s an application to make, not a setting to flip.
A practical test: take ten of your real security-flavoured prompts, run them on claude-fable-5-2, and read the API response and the usage docs for what marks a fallback before you promise anyone a result.
Check three: preserved thinking now bites everyone
Anthropic’s preserved thinking
rule is that a thinking block stays valid only while the system prompt, the tools list and every earlier message are unchanged on later requests. On Fable 5.1, accounts created before 31 August 2026 got no error when the check failed: the failing blocks just reached the model. On Fable 5.2 the docs table shows a 400 for every account.
So an integration that worked on 5.1 can fail on 5.2 with an invalid_request_error. The patterns the docs list as breaking are common in homemade agents:
- Rebuilding the system prompt on each request with the date or a mode flag in it.
- Editing or clearing old
tool_resultblocks in place. - Summarising or dropping old turns client-side.
- Changing the tool list mid-session.
- A serialiser that skips empty
thinkingblocks. The signature carries the reasoning, so an empty block must be sent back as returned.
The docs describe a per-request control. Set thinking.block_binding.prefix_mismatch_behavior to "drop_block", with the beta header thinking-binding-controls-2026-08-01, and the API drops the failing blocks and succeeds. It’s a stopgap: dropped reasoning can raise output tokens and change quality on tasks that build on earlier thinking. Responses list what was dropped in input_transformations.
A drift check you can run today
The first verification step in the docs is to diff consecutive request bodies. This script does it for saved JSON bodies: it compares system, tools and the shared message prefix between each pair of requests.
import json, sys
def drift(prev, cur):
problems = []
if prev.get("system") != cur.get("system"):
problems.append("system changed")
if prev.get("tools") != cur.get("tools"):
problems.append("tools changed")
old, new = prev["messages"], cur["messages"]
for i, msg in enumerate(old):
if i >= len(new) or new[i] != msg:
problems.append(f"messages[{i}] changed or removed")
break
return problems
bodies = [json.load(open(p)) for p in sys.argv[1:]]
for n, (a, b) in enumerate(zip(bodies, bodies[1:]), start=2):
found = drift(a, b)
print(f"request {n}: " + ("; ".join(found) if found else "prefix intact"))
Save three consecutive request bodies as r1.json, r2.json and r3.json, then run python3 prefix_drift.py r1.json r2.json r3.json. With a system prompt that embeds the date and changes between the second and third requests, it prints:
request 2: prefix intact
request 3: system changed
That second line is the bug that returns a 400 on 5.2. The fix is to freeze system and add changes as a later message, which the docs cover with mid-conversation role: "system" messages.
The docs add a second step worth copying into CI: run a multi-turn session with "error" as the behaviour, so a regression fails the build, and with "drop_block" in staging while logging input_transformations. An empty array on every turn means the prefix is intact. A clean run on your own key doesn’t prove it, because accounts differ in what they tolerate.
What to do this week
Don’t switch a fleet on the headline. Pick one real task, run it on Fable 5.2 and on whatever you use now, and compare the cost per finished task and the number of blocked requests. Then run the drift script over a recorded session. If you’re on Copilot, ask your administrator whether the policy is on and who agreed to the retention terms.