Claude Fable 5.2 for builders: when to route past Opus 5.5, and what it costs

Claude Fable 5.2 is the model to route to when a task is in the hard tail of your workload and Claude Opus 5.5 at higher effort has already failed it, not the new default. That is Anthropic’s own instruction, repeated in its launch post, its models overview and its cost guide, and Anthropic’s published cost-per-task data supports it. The price cut makes the escalation cheaper. It does not make Fable the cheaper model.

Anthropic released Fable 5.2 and its restricted twin, Claude Mythos 5.2, on 9 November 2026, and amended one passage of the announcement on 11 November to describe more exactly what it gave the model in its Fermat’s Last Theorem formalisation run. The list price fell to $8 per million input tokens and $40 per million output tokens, from $10 and $50 on Fable 5.1. Opus 5.5 costs $4 and $20. Fast mode, which Anthropic says raises output speed by up to 2.5 times, costs $16 and $80. The API identifier is claude-fable-5-2. Everything below was checked against Anthropic’s documentation on 12 November 2026; GenAI Brief has not run the model.

For builders, four details decide whether the escalation pays: cache reads cost the same on Fable and Opus, fast mode on Opus 5.5 now lists at exactly Fable’s standard price, the Advisor and Orchestrator roles come with hard pairing rules and thin evidence, and preserved thinking turns any non-append-only integration into a source of 400 errors. This piece works through each, then gives a routing worksheet and a worked cost example.

What actually launched on 9 November

Fable 5.2 and Mythos 5.2 are, in Anthropic’s words, “the same underlying model”. Fable carries cybersecurity and biology safeguards that let Anthropic offer it to everyone; Mythos has more permissive safeguards and is available only to organisations accepted into the Cyber Verification Program or the Life Sciences Verification Program. The Fable 5.2 model page gives the specifications, which match Opus 5.5 on context window, output limit and thinking mode but differ on price, default effort, data retention and retirement date.

Sources: models overview, pricing, fast mode and the migration guide, read 12 November 2026.

Anthropic’s launch claims for builders are narrower than the headline benchmarks. It says Fable 5.2 generates output “up to 30% faster” than Fable 5.1, communicates more clearly, and at Medium effort, the default in Claude apps and Claude Code, completes challenging tasks with fewer tokens than Fable 5.1. On the API the default is high, not medium, which matters for anyone moving traffic from Opus 5.5: a request that omits effort runs one level higher on Fable and the change shows up only in the bill and the latency.

The announcement’s own guidance on model choice is explicit: “For most coding and knowledge tasks, we recommend that users start with Claude Opus 5.5, our strongest daily driver.” Fable and Mythos are described as “best for the most ambitious, open-ended technical work”. The models overview puts the trigger more operationally: use Fable 5.2 “when your evals on Claude Opus 5.5 at higher effort still fall short”.

What the benchmarks say about the gap, and under which conditions

Anthropic’s launch table shows Fable 5.2 ahead of Opus 5.5 on most rows. The system card says Fable 5.2 “scored highest on 14 of 16 results” in its capability summary, trailing Opus 5.5 on the GDPval-AA and AA-Briefcase Elo ratings. Several rows were run by outside groups, which is the closest thing to independent evidence available at launch, but every number still reaches builders through Anthropic’s publication.

Source: the launch announcement and system card, section 8. Scores are with safeguards on unless noted; rows without a named runner were run or reported by Anthropic.

The table hides the variable a builder actually pays for: cost per task. The FrontierCode row is the clearest example. The system card reports every effort level Cognition ran. Fable 5.2 scored 34.2% at low for $2.10 per task, 37.6% at medium for $2.48, 45.3% at high for $6.72, 49.1% at xhigh for $14.19 and 45.7% at max for $44.70. Opus 5.5’s best score, 45.5% at max, cost $12.82. So the launch post’s claim that Fable at High “scored about level with Opus 5.5 at Max effort, for roughly half the cost per task” holds on this benchmark, and the system card adds a caveat the launch table omits: Fable’s max score includes 22 timed-out attempts out of 660, and counting them as zero would put it at 44.4%, below Opus.

That FrontierCode result is a hard-task result. Cognition derives the tasks from real pull requests and grades whether a maintainer would merge the diff. On easier work, the picture inverts. Anthropic’s cost guide reports results on 463 problems from an internal SWE-bench Pro subset, priced as a customer is billed:

Anthropic’s own reading: Opus 5.5 at xhigh lands “level with Fable 5.2 at high for a little over half the cost”. The same guide reports that on 44 DeepResearch Bench II tasks at default effort, Fable 5.2 cost 2.9 times as much as Opus 5.5 for a score 1.9 points lower, and 4.3 times as much as Sonnet 5.5 for no measurable gain. These are Anthropic-internal measurements and the subset scores are explicitly “not comparable to the public leaderboard”, but they come from the vendor that has every commercial reason to sell the more expensive model. We think that makes them more persuasive, not less.

The pattern across both sources is consistent. Where Opus 5.5 already solves most tasks, Fable’s higher per-token price dominates and Opus wins on cost per solved task. Where Opus’s curve flattens below the score you need, Fable can reach the same score at lower effort and lower total cost, as on FrontierCode, WANDR (Anthropic says Fable at Medium matches Opus’s top score for about 40% of the cost per task) and Humanity’s Last Exam (Fable at Low matches Opus’s top score for under a tenth of the cost). The question for a router is which of those two regimes a task is in, and the only reliable answer comes from your own evals.

Our guide to reading a model card explains why effort level, trial count and harness need to travel with every score. Fable 5.2’s card is a good test of that discipline: the same model is reported at its best effort in the summary table, at default effort on the Remote Labor Index, and at every effort in the FrontierCode chart.

The price cut, read through a cache

Fable 5.2 is twice Opus 5.5 on uncached input, cache writes and output. It is the same price on cache reads, because Anthropic set Fable’s cache-hit multiplier at 0.025 times input against 0.05 times on Opus. In an agent loop, where most input arrives as cache reads, that narrows the gap below two times. How much depends on how output-heavy the loop is.

A worked example with explicit hypothetical inputs

Take a hypothetical coding-agent session of 40 requests. Each request carries about 120,000 input tokens: 115,000 read from cache, 3,000 written to the 5-minute cache and 2,000 uncached. Each produces 4,000 output tokens, including thinking. These numbers are ours, chosen to resemble a long agent run with a stable prefix; they are not measurements of Fable 5.2 or of any customer.

Calculated from Anthropic’s list prices and cache multipliers as of 12 November 2026. Fast-mode cache rates assume the documented rule that “prompt caching multipliers apply on top of fast mode pricing”.

Three things fall out. First, at identical token counts Fable costs 1.82 times Opus in this session, not two times, because the 115,000 cached tokens per request cost $0.023 on either model. Second, output is most of the bill on both, so the lever that moves cost is how many tokens each model writes, which the example deliberately holds fixed. Third, Opus 5.5 in fast mode and Fable 5.2 in standard mode share a headline price of $8 and $40, yet Fable standard comes out slightly cheaper here because its cache reads stay at $0.20 while Opus fast’s rise to $0.40.

The example’s main limitation is the one that matters most. Real models do not use the same number of tokens for the same task. Anthropic’s FrontierCode data has Fable at high costing about half of Opus at max per task, despite double the per-token price, because Opus at max writes far more. Its SWE-bench Pro subset has Fable at high costing more than six times Opus at medium per solved task. Token price is an input to cost per task, not a substitute for it. Our prompt caching explainer covers how to keep the cached share of a loop high, which is the part of this arithmetic a builder controls.

Output caps can waste a Fable run

One Fable-specific cost trap appears in the cost guide. On an internal repository-task benchmark at default effort, a max_tokens cap of 16,384 ended 85% of Fable 5.2’s attempts and left it solving 20.3% of tasks at $27.96 per solved task. At 64,000 the cap ended 2% of attempts and it solved 77.4% at $24.42. Only 1.7% of Fable’s turns passed 16,384 tokens, but one long turn ends the whole attempt and the discarded turns are still billed. Anthropic recommends 64,000 for agentic work, or the 128,000 maximum when a cut-off attempt is costly.

The migration guide adds two related behaviour changes. Prompt lines such as “answer directly without deliberating”, which usually kept Fable 5.1 from thinking, no longer stop Fable 5.2 from thinking at medium and above, so a request that relied on such a line to fit a small max_tokens can now stop before any text. And at xhigh and max in an agentic coding product, Anthropic observed Fable 5.2 starting subagents to review its own work, which Fable 5.1 did not do on the same tasks. Subagents can account for a large share of a session’s cost.

Fast mode: paying for speed, not intelligence

Fast mode “runs the same model with a faster inference configuration”, according to the fast mode documentation, with “no change to intelligence or capabilities”. The gain is in output tokens per second, not time to first token, and it is most visible when streaming. The documented ceiling is “up to 2.5x”; Anthropic does not publish a typical figure.

You opt in with speed: "fast" on a Messages API request. The response’s usage.speed field reports which speed ran. Fast mode has its own rate limit, separate from standard limits, and returns a 429 with a retry-after header when exceeded. The default fast-mode limit for Fable 5.2, Mythos 5.2 and Opus 5.5 applies in the Start, Build and Scale usage tiers without an access request; organisations in the Evaluation tier must move up first.

The constraints are where builders get caught:

• No Batch API and no Priority Tier. Fast mode is unavailable on both. Fable 5.2 is not supported on Priority Tier at any speed.
• No shared cache across speeds. The documentation is explicit that “requests at different speeds do not share cached prefixes”, so falling back from fast to standard on a 429 pays a full cache write on the fallback request.
• Not on Managed Agents for Fable. The fast mode availability table lists Managed Agents support only for Opus 5.5, Opus 5 and Opus 4.8. The migration guide tells teams moving an agent to Fable 5.2 to remove speed: "fast" from the agent’s model object.
• Platform-specific IDs. On Anthropic-hosted Microsoft Foundry, fast mode is a separate deployment, claude-fable-5-2-fast, and sending speed to the standard deployment returns an error. On Google-managed Claude Models on Google Cloud, Google sets the fast-mode price. Fast mode for Fable 5.2 is not listed on Amazon Bedrock.
• Not ZDR. Fast mode is zero-data-retention eligible in general, but the documentation excludes Covered Models, and Fable 5.2 is one.

The economic question fast mode raises is new with this release. At $8 and $40, Opus 5.5 fast and Fable 5.2 standard cost the same per token. A team that wants a faster interactive agent can buy Opus’s speed or Fable’s capability at that price, not both. For a person waiting on each reply, Anthropic’s model-selection playbook suggests starting with Sonnet 5.5 at low or medium effort; fast mode is the option when the reply has to come from a larger model and the wait is the problem. For unattended runs where nobody is watching the stream, fast mode doubles the bill for a benefit no one sees.

The Advisor role: hard pairing rules, thin evidence

The launch post says Fable 5.2 “can also play the role of Advisor (where Haiku, Sonnet, or Opus models consult it to help solve harder problems)”. That role is implemented by the advisor tool, a beta server tool of type advisor_20260301 that needs the advisor-tool-2026-03-01 header. The cheaper executor model decides when to call it. Anthropic then runs a separate inference pass on the advisor model, which receives the executor’s full transcript, including system prompt, tool definitions and tool results, and returns guidance inside the same /v1/messages request. The advisor runs without tools, and its thinking is dropped before the result returns.

What the rules allow

The advisor must be at least as capable as the executor. Haiku 5.5, Sonnet 5.5 and Opus 5.5 executors all accept claude-fable-5-2 as an advisor. A Fable 5.2 executor accepts only Fable 5.2 or Mythos 5.2; any other advisor, Fable 5.1 included, returns a 400 error. In Claude Code, the advisor documentation adds that Fable 5.2 as the advisor requires Claude Code v2.1.321 or later and that “Claude Code doesn’t apply an Opus or Sonnet advisor to a Fable main model”.

Three operational details are easy to miss:

• You cannot read Fable’s advice. Fable 5.2 advisors return an encrypted advisor_redacted_result. The executor reads it server-side; your logs get an opaque blob. The documentation also says Opus 5.5 and Sonnet 5.5 executors pair only with encrypted advisors, so if your evaluation process depends on inspecting what the advisor said, a Fable 5.2 advisor rules that out.
• You cannot force a consult on modern executors. Fable 5.2, Opus 5.5 and Sonnet 5.5 executors reject tool_choice types tool and any, so the only levers are prompting and the max_uses cap per turn. Anthropic reports that a mid-conversation nudge raised pass rates by about 7 percentage points on Haiku 4.5 executors, had no measurable effect on Sonnet, and slightly lowered pass rates on Opus.
• Changing the advisor is a prompt edit. Adding, removing or changing the advisor tool is an edit to tools, which invalidates earlier thinking blocks. With a Fable 5.2 executor that returns a 400 error on every account unless you opt into dropping blocks, so advisor changes belong at the start of new conversations.

Availability is narrower than the model’s. The advisor tool is in beta on the Claude API, Claude Platform on AWS and Anthropic-managed Claude Models on Google Cloud. Claude Code’s advisor works only with the Anthropic API or Claude Platform on AWS, not Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry.

What the evidence shows

Anthropic has not published a measurement of Fable 5.2 as an advisor. Its cost guide measured three pairings, two of which used Fable 5.1:

Anthropic’s own summary is cautious: the one pairing that consulted often “bought about what more effort does”, and an advisor “can help only when the executor consults it”. The playbook post repeats the point and tells builders to measure the consult rate first. The advisor tool’s definition adds about 1,000 prompt tokens to every request, which a cached multi-turn loop pays at the cache-read price but a single-shot task pays in full.

The per-consult cost is easy to estimate. Extend the worked example above: put the same 40-request session on Sonnet 5.5 ($2.52) and suppose the executor consults a Fable 5.2 advisor three times, each on a 100,000-token transcript with 2,000 output tokens, thinking included. Without advisor caching, each consult costs about $0.80 in input and $0.08 in output, so $2.64 for three, and the session lands at about $5.16, roughly what Opus 5.5 alone cost. These consult counts are hypothetical. The API’s optional caching setting on the advisor tool lets later consults read the earlier transcript from cache; in Claude Code, the documentation says the advisor’s read “is not cached” and each call processes the full transcript anew.

So the Advisor role is real and documented, and its economics are plausible on paper. Whether it beats simply running Opus 5.5, or Sonnet 5.5 at higher effort, is unmeasured for Fable 5.2 in public. Builders who adopt it are running the experiment Anthropic has not yet published.

The Orchestrator role: the model is willing, the cost case is narrow

The other role the launch post names is Orchestrator, “where it delegates simpler tasks to smaller models”. On the Claude Platform that maps to multiagent orchestration in Claude Managed Agents, a beta feature configured with a multiagent block of type multiagent_20261001. The lead agent can delegate to subagents, write dynamic workflows that run many agents in phases, or consult an advisor. Delegation is one level deep, a session can hold at most 25 child threads at a time, and each predefined-agent list can name up to 20 agents. The feature is not ZDR eligible.

One rule decides whether an orchestrator saves money at all. The documentation states that “an inline agent uses the model of the agent that the session runs”. If Fable 5.2 runs the session and defines its workers on the fly, those workers run on Fable 5.2 too. To delegate to Sonnet 5.5 or Haiku 5.5, a builder has to create those workers as predefined agents with their own model and list them in subagents.predefined_agents or workflows.predefined_agents, and can disable inline agents to stop the lead from improvising Fable-priced helpers.

Anthropic’s evidence for the role comes in two kinds. The capability evidence is the Fermat’s Last Theorem run: a lead and 999 helpers, running an early version of Fable 5.2 in sandboxes with no network access, coordinating through a shared Postgres database and Git, finished the Lean formalisation in 28.7 hours (the launch post rounds this to 30). The 11 November amendment to the launch post adds a footnote quoting what the team was given: 60 statements, a one-sentence sketch of the classical route, the definitions those statements use and 47 proved lemmas from Anthropic’s earlier formalisation. Anthropic calls it “a toy experiment”. Under the same 1,000-agent setup, it reports, Opus 5.5 completed 26% of the formalisation in 18 hours. Partner testimonials on the launch page point the same way: a Datadog engineer describes Fable as “almost like an incident commander that can send out faster models”, and an Uber engineer describes a 10 to 12 hour audit in which it “sent out about 170 reviewer agents”. These are vendor-selected quotes, not measurements.

The cost evidence is narrower. On an internal defect-search benchmark of about 22 million tokens of Python source, the cost guide reports that Opus 5.5 orchestrating Sonnet 5.5 subagents matched Opus 5.5 alone at default effort for about a third less. Putting Fable 5.2 in Opus’s place as the orchestrator “cost 19% more and scored about the same”. Fable 5.2 running alone did score 1.6 to 5.9 points higher than Opus 5.5 alone at high, but for 1.5 to 2.4 times the cost. Anthropic’s general finding is that delegation came out ahead only for routine work with a long cost tail or work larger than one context window; for a single dependent chain, the orchestrator’s model alone at lower effort won in every case it measured on earlier models.

The reading for a builder: Fable 5.2 can run a large team, and Anthropic’s harness shows it inventing its own coordination tables. On the one published benchmark that compares orchestrators, Opus 5.5 was the cheaper lead at the same quality. Fable as orchestrator makes sense when the planning itself is the hard part, which is a claim to test on your own work, not one the published data establishes.

Preserved thinking is the change most likely to break your code

The launch post mentions it in a single sentence under anti-distillation: “preserved thinking now applies to all accounts”. For anyone who builds their own messages array, it is the most consequential item in the release.

Preserved thinking binds each thinking block to its prefix: the top-level system prompt, the set of tools and every message before it. If any of those change on a later request, that block and every later thinking block in the history fail the check. On Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5, enforcement depends on account age: accounts created on or after 31 August 2026 get a 400 error, older ones may not. On Fable 5.2 and Mythos 5.2, every account gets the error. The migration guide spells out the consequence: “on an older account, requests that pass on Claude Fable 5.1 can fail on Claude Fable 5.2”. It also warns that a clean run on your own key proves little, because customers running your tool on their keys can get the error when you do not.

Anthropic’s distillation research post, published 12 October 2026, explains why. Distillers had moved protected reasoning blocks between conversations, models and accounts to coax Claude into revealing its full reasoning. Preserved thinking stops the conversation route, model binding stops earlier models reading newer reasoning, and account binding, which now covers Fable 5.2 thinking blocks, stops the account route. Anthropic says its combined defences cut the data harvested by distillers by 90 to 99%, and concedes that preserved thinking “has required some developers to update their integrations”.

The patterns that trigger the error are ordinary harness habits. The documentation lists rebuilding the system prompt with today’s date or a mode flag, re-rendering context in the first user message, shortening old tool results, client-side summarisation that keeps recent thinking, editing the tools list, adding and later removing reminders, and an MCP connector whose tool list changes between requests. That last one is specific: an unpinned MCP tool list that shifts is an edit for Fable 5.2 thinking blocks but not for Fable 5.1 or Opus 5.5 blocks. Each pattern has a documented replacement, such as mid-conversation system messages, tool_addition blocks or server-side compaction.

The escape hatch is thinking.block_binding.prefix_mismatch_behavior: "drop_block" behind the thinking-binding-controls-2026-08-01 header. Dropped blocks are not billed, but the model then re-creates the reasoning it lost, and the documentation warns this “can significantly increase output tokens” when it happens every turn. On a model whose output costs $40 per million tokens, a harness that drops blocks on every turn turns a compatibility fix into a recurring cost. Nothing changes for teams whose history is managed by Claude Code, claude.ai, Managed Agents or the Claude Agent SDK.

Preserved thinking also shapes routing. Thinking blocks are readable only in one direction across tiers. Fable 5.2 reads Opus 5.5, Sonnet 5.5 and Haiku 5.5 blocks on the Claude API and Google-managed Google Cloud, so escalating a conversation from Opus to Fable keeps the earlier reasoning. No model outside the Fable 5.2 and Mythos 5.2 pair reads Fable 5.2’s blocks, so a move down, a router fallback or a classifier fallback silently drops them, and the first turn after the switch costs more while the new model rebuilds context. A router that escalates up mid-conversation is cheap; one that bounces back down after each hard step pays for it.

Classifier blocks and fallbacks: fewer, but plan for them

Fable 5.2 keeps classifiers that block high-risk cybersecurity work, including penetration testing, exploit generation and binary-based vulnerability discovery, as well as “most tasks in research biology”. Anthropic says it observed “about 55% fewer blocks with Fable 5.2 compared with Fable 5.1”, about 60% fewer in cybersecurity and 40% fewer in biology. The conditions matter: those figures come from “early testing across claude.ai, Claude Code, and Cowork”, Anthropic’s own products, not from API traffic, and the announcement gives no absolute block rate. The system card’s section on cyber safeguards adds that source-code vulnerability discovery is allowed, so developers can use Fable to write more secure software, while vulnerability discovery in compiled binaries is blocked.

When a classifier blocks a request, Anthropic’s apps fall back automatically: cybersecurity blocks go to Opus 4.8, biology blocks to Opus 5, and a narrow set of frontier-LLM development topics, such as kernel development on certain nonstandard accelerators, also to Opus 5. On the API, a block is a normal 200 response with stop_reason: "refusal" and a stop_details.category, and fallback is opt-in. The refusals documentation describes fallbacks: "default", in beta behind the server-side-fallback-2026-07-01 header, which retries on the model Anthropic recommends for the category.

Builders should plan for four consequences:

• Some blocks are billed. A refusal before any output is billed when its category is bio, frontier_llm or reasoning_extraction, which Anthropic says are the categories where it measured low false-positive volumes as of September 2026. cyber and general_harms refusals before output are not billed.
• Visible-reasoning prompts get refused. The reasoning_extraction category catches prompts that ask the model to write its reasoning into the output, such as a <thinking> section or a reasoning field in JSON. It has no fallback model. The fix is to read thinking blocks with display: "summarized" instead.
• Fallbacks lose reasoning and change behaviour. The fallback model does not receive Fable 5.2’s thinking blocks. In the system card’s Terminal-Bench 4.0 run, 2.5% of Fable’s requests were flagged and answered by the fallback model, affecting 10% of trials.
• Prompt-injection exposure shifts. The system card reports that Fable 5.2 “falls back to Opus 4.8 more frequently than recent models do in prompt injection scenarios, resulting in a higher attack success rate”, while being one of Anthropic’s most robust models when it answers itself. An agent that reads untrusted content with security-flavoured text in it may be served by an older model on exactly the turns that matter. Our prompt-injection explainer covers the defences that sit outside the model.

Security teams whose legitimate work trips the cyber classifier have a separate route. The Cyber Verification Program offers three access tiers that cover Mythos 5.2, and Claude Enterprise customers can use Claude Security, whose scanning models, Anthropic says, now include Mythos 5.2. Fast mode for Mythos is limited to organisations in the verification programmes.

Availability, retention and the other gates

Fable 5.2 is generally available on the Claude API, Amazon Bedrock through the bedrock-runtime endpoint (as global.anthropic.claude-fable-5-2 or us.anthropic.claude-fable-5-2), Claude Platform on AWS, both forms of Claude Models on Google Cloud and Microsoft Foundry. It has its own rate limit, separate from the combined limit Fable 5.1 and Fable 5 share and from Opus 5.5’s; the migration guide says Fable 5.2 has lower token limits than Opus 5.5 at each tier. Capacity planning based on either model does not carry over automatically, and the launch materials do not publish the numbers.

The gate most likely to stop an enterprise is retention. Fable 5.2 is designated a Covered Model, which means a 30-day minimum retention period for prompts and completions on every surface where it runs, including third-party clouds. On the Claude API, a request from an organisation or workspace without 30-day retention returns a 400 error. Anthropic’s stated reason, in its September post on Enterprise Frontier Safeguards, is that detecting sophisticated misuse requires correlating traffic across time and accounts. Eligible customers can get a time-limited ZDR arrangement for internal business applications as a transition to EFS, which stores monitoring data in the customer’s own cloud and is in private beta with customers including Bridgewater, Salesforce and Stripe.

Smaller gates are in the migration guide. Forced tool use (tool_choice of any or tool) returns a 400 error, as on Opus 5.5, and so does a prefilled assistant turn. The documentation says to omit temperature, top_p and top_k, some values of which also return a 400 error. In organisations with customer-managed encryption keys, structured outputs are unavailable on Fable 5.2 while Opus 5.5 supports them. The older computer_20251124 tool returns a 400 error everywhere except Amazon Bedrock; Fable needs computer_toolset_20260801.

For subscribers on Claude’s paid plans, Anthropic’s launch offer runs on its own clock. Pro plans and standard Team seats get all Fable models included for one week, up to 50% of weekly usage limits, through 16 November 2026 at 11:59 pm PT, plus one Fable limit reset that expires at the same time; after that, Fable usage returns to usage credits. Max, Ultra and premium seats get one to three Fable limit resets depending on subscription length, expiring on 8 March 2027.

Timeline

A routing worksheet

The worksheet below condenses the evidence into decisions. It is our synthesis of Anthropic’s published guidance and measurements, not a test we ran; every “Evidence” cell points to a vendor-reported result.

A proposed acceptance test, which we have not run: take the 50 most expensive tasks Opus 5.5 failed last month, run them on Opus 5.5 at xhigh and on Fable 5.2 at medium and high, each in a fresh session so caches do not mix, and record cost from each response’s usage field. Route to Fable only the task classes where its cost per solved task beats Opus’s. Anthropic’s own four-step method in its cost guide follows the same shape, ending with a shadow run on live traffic before cutover.

What we still do not know

Several open questions could change the routing advice.

No independent cost-per-task data yet. Cognition and Proximal ran some of the benchmarks, but their results reach builders through Anthropic’s system card, and the cost figures are Anthropic’s. The Proximal page we could read describes FrontierSWE v2’s design and earlier results; it does not report Fable 5.2. Independent leaderboards that price runs at list rates would show whether Anthropic’s own SWE-bench Pro and DeepResearch numbers generalise.

The advisor role for Fable 5.2 is unmeasured in public. None of the advisor pairings in Anthropic’s cost guide uses Fable 5.2 as the advisor; its current table uses Fable 5.1 and Opus 5.5. Fable 5.2 is cheaper than Fable 5.1 per token and, per Anthropic, uses fewer tokens at Medium, so the economics could be better than the Fable 5.1 result suggests. Or the executor’s consult rate could again be the bottleneck. A published pairing table with Fable 5.2 would settle it.

The 55% reduction in blocks has no API baseline. Anthropic gives a relative figure from its own products. Builders in security tooling, bioinformatics or ML infrastructure do not know their absolute block rate until they measure it, and billed refusal categories mean false positives now carry a direct cost in some cases.

Rate limits and fast-mode speed are unquantified. Fable 5.2’s rate limit is separate from Fable 5.1’s and, per the migration guide, lower than Opus 5.5’s at each tier, and the fast-mode limit is separate again, but launch materials give no figures. “Up to 2.5x” is a ceiling, not a typical gain.

Retention terms are in transition. The ZDR arrangement is described as time-limited and EFS as rolling out in phases, with no end date published for either. Teams in regulated industries cannot yet plan beyond that.

The orchestration evidence is mostly one experiment. The Fermat run shows coordination at scale under a sandbox and monitoring stack most builders do not have, and the 11 November amendment shows how much structure the team was given. The only published orchestrator cost comparison favours Opus 5.5 as the lead.

Evidence that would move the conclusion towards Fable as a default would be independent cost-per-solved-task results showing it cheaper than Opus 5.5 across ordinary coding work, not just the hard tail. Evidence that would move it further away would be reports of high block rates or frequent fallbacks on mainstream engineering traffic.

What to do this week

1. Leave the default on Opus 5.5 and make Fable 5.2 an escalation target, as Anthropic itself recommends. Our Sonnet 5.5 guide covers the step down for well-scoped work.
2. Audit the harness for prefix edits before routing a single request. Run a session with drop_block and the beta header, log input_transformations, and fix every prefix_binding_mismatch.
3. Set effort and max_tokens explicitly on Fable requests: an explicit effort level so the API’s high default does not surprise the bill, and 64,000 output tokens so long turns do not end attempts.
4. Handle refusals as data. Read stop_reason and stop_details.category, decide whether to opt into fallbacks: "default", and strip any prompt that asks for reasoning in the output.
5. Price fast mode against Opus fast, not against Fable standard, for interactive agents, and keep it off batch-style and unattended jobs.
6. Treat the Advisor and Orchestrator roles as experiments. Predefine cheaper workers explicitly, measure the consult rate, and keep a pairing only if it beats the single model’s effort curve.

The price cut changes the arithmetic of escalation more than the arithmetic of defaults. Fable 5.2 at $8 and $40 is a cheaper way to rescue the tasks Opus 5.5 cannot finish. The builders who benefit will be the ones who know which tasks those are.