Claude Fable 5.2 and Mythos 5.2: Power, Price and Limits

Claude Fable 5.2 can spend more time thinking and finish with a worse score. That is not a hypothetical warning: in the published FrontierCode evaluation, xhigh scores above max while costing less than one third as much. Elsewhere, the same release makes a substantial jump over its predecessor. Both observations matter.

Fable 5.2 and Mythos 5.2 are a substantial capability upgrade with an unusually important operating manual. To use them well, separate model capability from reasoning effort, access policy, context management and the total cost of an agent run. The useful question is which combination produces an accepted result within your constraints.

What are Claude Fable 5.2 and Mythos 5.2?

Anthropic released both on November 9, 2026. They are configurations of the same underlying model, rather than a small model and a separately trained superior one. Fable applies cybersecurity and biology safeguards for general availability. Mythos is offered under verification programs for approved work in those fields. Anthropic announcement

For a beginner, three terms explain much of the release:

• Effort controls how much work the model spends reasoning. It can change token use, latency and tool behavior.
• Harness means the surrounding agent software: prompts, tools, memory, timeouts, context management and grading. Changing it can change the result without changing the model.
• Context window is working capacity for a request, not a promise that the agent will use every part efficiently or remember everything forever.

The everyday starting point is still Opus 5.5 according to Anthropic. Escalate to Fable when representative tasks remain below your quality threshold at an appropriate Opus effort level. Use a smaller model when the simpler task does not need the premium capability. Choosing a Claude model

This suggests a practical split: routine extraction, small edits and bounded drafting stay on an economical model; difficult investigations, long migrations and unfamiliar engineering work receive a carefully budgeted Fable attempt. Mythos access is a separate decision about authorized work and safeguards.

Specifications, model IDs and availability

Sources: Fable model reference, Mythos model reference.

Fable is documented on the Claude API, Amazon Bedrock, Claude Platform on AWS, both Google Cloud hosting arrangements and Microsoft Foundry. Mythos has its own documented platform list and entitlement path; do not infer access from a model ID appearing in an SDK. Hosting and geography also affect retention and pricing responsibilities.

The launch announcement says Claude apps and Claude Code default to medium, while the API model reference says high. A comparison that leaves effort unspecified can therefore compare different operating points while displaying the same model name.

The tokenizer is also relevant to migration. Anthropic documents the tokenizer lineage used since Opus 4.7; the same text can require substantially more tokens than on older models. A lower price per token does not establish the price of your unchanged document. Count the actual input. Token counting

Pricing: what the token table does and does not tell you

These are standard Claude API prices in USD per million tokens, checked on November 11. They are not Claude subscription prices or universal cloud-marketplace quotes.

Haiku’s price increases above the stated input threshold. Fable’s full 1M context uses its standard token rates without a long-context surcharge. Batch input/output prices for Fable 5.2 are $4/$20. Fast-mode base input/output prices are $16/$80 and fast mode does not combine with Batch. Tool and platform charges remain separate. Claude pricing, Batch processing

At unchanged token counts, the reduction from Fable 5.1’s $10/$50 to $8/$40 is 20%. It is not a promise of a 20% cheaper task: the newer model may use a different number of reasoning tokens, calls or subagents.

The old cache-price inversion no longer applies to Opus 5.5

The earlier Fable/Mythos cache-read analysis compared older prices where Fable’s cached input was cheaper than Opus’s. For Fable 5.2 versus Opus 5.5, both now charge $0.20 per million cache-read tokens.

For equal usage, the common cache-read term cancels. Fable still charges more for uncached input, cache writes and output. There is no cached-context ratio that makes Fable 5.2 cheaper than Opus 5.5 under identical token counts at these standard rates.

That does not mean Opus always costs less per accepted task. Fable could finish in fewer attempts or solve something Opus does not. But that is a measured productivity claim, not a consequence of a cheaper cache-read column.

These are arithmetic examples, not observed model token counts. All output means billed output, including thinking—not only the final text visible to the user. Cache writes must be charged in their own category rather than counted again as uncached input. Prompt caching accounting

Download the offline cost calculator and source data. They make no network requests and contain no API keys. The calculator reproduces the examples, calculates explicit cache-write costs and rejects invalid usage values.

Fast mode, geography and latency

Anthropic describes fast mode as up to 2.5 times faster token generation. That is not an end-to-end completion guarantee. Tool execution, external services, long reasoning and retries can dominate wall-clock time. Test normal and fast mode on the same accepted-output criterion. Fast mode

US-only inference adds a 1.1× multiplier to applicable Claude API token categories. Partner-operated cloud pricing can differ. Fast-mode availability also differs by platform: for example, Foundry exposes a separate Fable fast model, while a Bedrock model name alone does not establish fast-mode support.

Effort is a deployment setting, not a quality guarantee

The API supports five levels. Adaptive thinking stays on; sending thinking: {type: "disabled"} or manually setting budget_tokens is not a way to turn Fable 5.2 into a cheap non-thinking model. Use effort and a task-level budget. Effort documentation

The most instructive example is FrontierCode 2.0. Cognition ran the reported evaluation, and the System Card gives these Fable settings:

Source: System Card §8.4, pages 209–210. This suite measures agent-generated code changes under its own grading rules; the numbers are not probabilities that your own pull request will pass review.

Moving from xhigh to max increases reported cost by about 3.15× and reduces score by 3.4 percentage points. Relative to high, max costs about 6.65× for a 0.4-point difference. The card supplies no uncertainty interval for this Cognition result, so tiny differences should not be treated as decisive.

There is a second caveat. Fable’s reported max score includes graded results from 22 timed-out attempts out of 660. Scoring those attempts as zero gives 44.4%, below Opus 5.5’s reported 45.5%. Lower Fable effort settings did not time out in this run.

Anthropic’s own recommendation is to start at high, try xhigh for difficult long-running work where it helps, and reserve max for measuring the ceiling or exceptional tasks. Run an effort sweep rather than copying a setting from 5.1.

Benchmarks: substantial gains with meaningful exceptions

The following numbers come from the System Card. Unless the row has its own qualification, reported Fable results use max. FrontierCode instead shows the best effort for each model, and RLI uses default effort. The headline table explicitly contains selected evaluations.

Coding and long-running engineering

DeepSWE v1.1 additionally reports 74.3% for Fable 5.2. Sources: System Card §§8.2–8.6 and 8.10.

Terminal-Bench’s 1.2-point Fable–Opus gap is small compared with the reported standard errors; it does not establish a reliable large advantage. Fable’s run also used a default refusal-fallback policy: 2.5% of requests were routed to a fallback, affecting 10% of trials. This is a result for that evaluated system, not exclusively one model answering every request.

Knowledge work, reasoning, vision and CAD

Sources: System Card §§8.1 and 8.7–8.19. Percentage scores, rubric scores and Elo are different measurements; they must not be averaged into an invented overall percentage. For Terminal-Bench-Science, Fable’s reported standard error is ±4.3 and Opus’s ±4.8.

The rubric and Elo rows illustrate why even a benchmark name is insufficient context. A model can score better under a rubric while ranking below another model in pairwise preference. Neither measure directly tells you how long a reviewer will need to repair a generated report.

The 1M-context lesson: give the agent a fuel gauge

ProgramBench is particularly useful for platform design. In the original setup, the agent has a 1M-token window but is not told how much capacity remains. Fable 5.2 exhausts context before submission on 68% of tasks, versus 39% for Opus 5.5 and 28% for Fable 5.1.

When the harness reports remaining context after each step, Fable’s score rises from 85.6% to 91.6%. Opus changes from 91.2% to 91.1%; Fable 5.1 reaches 86.8%. This is a different setup and should be labeled as such, not silently substituted into the original leaderboard. Source: System Card §8.10.1, page 216.

The architectural implication is concrete: expose remaining context, elapsed time and budget; preserve checkpoints; and compact deliberately before the agent loses essential evidence. A large window is capacity to manage. The context engineering guide explains the wider design problem.

For a migration agent, maintain a short durable record of completed changes, test results, unresolved blockers and the next action. That record should describe verified state. It should not become an ever-growing transcript that consumes the capacity it was supposed to protect.

Independent measurements: what Artificial Analysis adds

Artificial Analysis’s Intelligence Index v5.0.1 aggregates nine evaluations. On the checked snapshot, Fable 5.2 at max scores 65, with a reported $26.54 per index task and 45.2 minutes per task. Its model page also reports 275M output tokens across the index run. These are evaluator measurements under its methodology, not a quote for your next request. Fable max results, index methodology

Sources: release comparison, high, xhigh. The evaluator labels these configurations Default Fallback. Rankings and endpoint speed change; retain the date and configuration when citing them.

Here, max does lead the aggregate, unlike FrontierCode’s best-effort result. It also costs about 2.92× as much as high for three additional index points. That is a decision about marginal value, not proof that max is either useless or necessary.

“Up to 30% faster than 5.1” from Anthropic and “long completion time at max” from an evaluator can both be true. Output speed, time to the first answer token and total task duration measure different things. A model that generates quickly but generates much more can still finish later.

Fable 5.2 versus GPT-6 Astra and Gemini 4 Carbon

The System Card reports FrontierSWE 69.9 versus 65.5 for Astra, and its selected table reports several other Fable leads. But the competitor numbers mostly come from developer cards or public leaderboards. They were not all rerun by Anthropic under one common harness. The card identifies an Anthropic-run Astra comparison on the same 82-task OSWorld subset and separately explains other evaluation-specific provenance.

ARC-AGI-3 makes the harness issue visible:

Source: System Card §8.15, pages 243–244, reporting ARC Prize Foundation results. Changing the harness changes the ordering. Fable’s own high also beats its max in both reported harnesses.

For an API procurement comparison, OpenAI’s official Astra reference lists $10 input, $50 output, $1 cached input and $12.50 cache writes per million tokens, with 1.05M context and 128K output. Requests above 272K input tokens incur the documented full-request long-context multipliers. Compare the intended request size and actual token use, not only the first two prices. Official OpenAI model documentation

Gemini 4 Carbon appears in Anthropic’s launch table but not the System Card’s Table 8.1.A. The announcement reports Carbon ahead on AutomationBench, 53.9 versus 51.4. Its FrontierCode configuration also differs in harness and selected effort. Those results belong in a sourced comparison, but not in a claim that Fable wins every category.

A single attractive shader, 3D scene or document is a useful demonstration. It is not a representative paired trial with a confidence interval. Use the demonstrations to invent evaluation tasks; use repeated, reviewable outcomes to select a production model.

Mythos 5.2: cybersecurity, biology and access

Mythos is relevant when approved security or life-sciences work needs a different safeguard configuration. It is not a general-purpose “unlocked Fable” recommendation. Routine secure development, patching and alert triage do not inherently require it.

The current Cyber Verification Program lists Defense, Red Team and Specialized Access. Individuals can apply for Defense Access; the higher tiers are for organizations. Access assignment, platform linking and the usage policy remain part of the process. Review targets differ by tier, so a blanket “approval in seven days” is misleading. Official CVP requirements

There is also a scheduled operational change: December 15, 2026 brings stricter Defense Access requirements around phishing-resistant MFA and removal of static or long-lived API keys. Check the official program page when planning an integration; an approved model and an approved authentication configuration are separate requirements.

For life-sciences research, use the official verification application. Neither an application nor an Enterprise subscription is a substitute for checking the account’s actual entitlement.

What the specialized benchmarks show

Source: System Card §§3.2–3.3 and 8.19. ExploitGym entries are counts from 869 cases, not percentages. The cyber and biology rows measure different tasks and should not be combined into one capability score.

CVE Rediscovery also depends on reporting policy. The card says counting only the first report narrows the Mythos–Opus gap from 8.3 to 2.6 percentage points. Possible training exposure is not ruled out. CyScenarioBench numbers from different labs are not automatically comparable when the task sets differ.

For general terminal work, Mythos’s reported 70.5 versus Fable’s 67.6 on Terminal-Bench does not establish a universal improvement independent of safeguards and configuration. The underlying model is shared; start by determining whether the safeguard distinction is relevant to the authorized task.

Safety: two sandbox metrics, two different conclusions

The System Card’s dedicated sandbox evaluation uses 1,829 deliberately weakened scenarios built around benign DevOps tasks. It is designed to tempt boundary crossing. These rates are not estimates of escape frequency in normal production use.

Source: System Card §6.5.1, pages 127–130. Mythos 5.2 improves substantially over its predecessors on both measures. Compared with Opus, however, the file/credential-use rate is similar while the broader boundary-reaching rate is higher.

In that evaluation, adding an explicit sandbox description and rules reduces Mythos’s broad rate to 1.2%. A reporting workflow also helps in the tested setups. That supports making boundaries understandable; it does not turn a prompt into an operating-system security control.

Use enforced filesystem scope, short-lived identities, controlled egress and tool permissions. Keep production credentials outside general-purpose agent sessions. The AI agent security guide develops those controls independently of any one model’s behavior.

Anthropic also reports reduced unnecessary classifier blocks and stronger anti-distillation measures in its announcement. Treat those as provider claims with their stated scope. Behavioral audit averages, refusal rates and sandbox metrics are different instruments, not interchangeable evidence that a model is safe for every deployment.

Healthcare and spectacular demos need their own caveats

On the raw HealthBench results run by Artificial Analysis at Anthropic’s request, Fable 5.2 scores 58.8, below Opus 5.5’s 64.3, Fable 5.1’s 63.9, Sonnet 5.5’s 65.9 and Haiku 5.5’s 61.2. Its length-adjusted position differs. On HealthBench Professional, it scores 71.1 raw, versus Opus’s 71.4; Fable leads the reported length-adjusted version. The card gives no confidence intervals for those results. Source: §8.16, pages 244–246.

The lesson for evaluating a model is to state the scoring rule. Raw and length-adjusted scores cannot be swapped to preserve a preferred winner. These benchmarks assess generated responses under particular rubrics; they do not establish clinical reliability.

The release also includes ambitious demonstrations: a large agent team formalizing Fermat’s Last Theorem in Lean, an operating-system prototype, a Python-to-Rust migration, physics research and electronic devices. They show plausible directions for use, but the evidence is uneven.

These are provider-reported projects, not repeatable head-to-head timing trials. They are most useful as examples of the artifacts a long-running agent might help produce.

The Fermat result uses an earlier model snapshot, existing definitions and supporting lemmas, and one team run for each compared model. It is not a clean-room proof invented by a single chat session. RoboDojo Sim’s 64.9 result is an internal robotics evaluation in the launch announcement, rather than a corresponding result in the System Card’s benchmark summary. Sources: System Card §8.12.3 and the launch report.

For your own demo, define a testable artifact before starting: a bootable image, a passing migration test, a verified proof or a design that survives physical review. Keep the artifact and the validation evidence. A persuasive narrative alone is a weak acceptance criterion.

API migration: the changes that can break production

Moving from Fable 5.1 is mostly familiar at the API level, but not merely a string substitution. Moving from Opus adds different defaults, retention and rate-limit considerations. Official migration guide

1. Preserved thinking binds to its conversation prefix

Fable 5.2 enforces the prefix check for every account. If your client changes the top-level system prompt, tool definitions or earlier messages before replaying a bound thinking block, the request can return 400. Common triggers include changing dates in a regenerated system prompt, rewriting old tool results and letting an MCP tool list change between turns.

Keep conversation history stable and append new information using supported mechanisms. If you compact, use a deliberate supported compaction path rather than retaining reasoning bound to an edited history. Preserved thinking

The beta thinking.block_binding.prefix_mismatch_behavior: "drop_block" option can keep a request moving while you repair the integration. It requires the matching thinking-binding-controls-2026-08-01 header. Treat it as a stopgap: discarded reasoning may increase subsequent output work. Log transformation metadata without exposing the private conversation.

2. Model switches do not preserve every reasoning block

Fable 5.2 and Mythos 5.2 can read one another’s thinking. Other models cannot read their blocks; an unsupported block is dropped rather than causing the request to fail. Account binding can likewise cause drops when sessions move between unlinked accounts.

That matters for routers, retry paths and fallbacks. An HTTP 200 after a model switch does not prove the replacement model received all prior reasoning. Preserve a durable task state and validate the recovery path. Cache continuity and thinking compatibility are separate properties. Model-specific changes

3. Computer use and advisors have compatibility requirements

The legacy computer_20251124 tool returns an error on the documented platforms except Amazon Bedrock. Migrate to computer_toolset_20260801 and update the agent loop, not only the tool declaration. A Fable 5.2 executor using the beta advisor tool needs a Fable 5.2 or Mythos 5.2 advisor. Computer use documentation, advisor tool

4. Audit the rest of the request and account configuration

Check the model’s actual rate limits and features for the target account. The retirement floor is a planning boundary, not a commitment that every partner deployment remains unchanged. Model deprecations, rate limits

Retention, refusals and fallback belong in application logic

Fable/Mythos 5.2 require 30-day data retention unless Anthropic expressly authorizes an exception. The standard docs do not grant blanket ZDR merely because a platform or feature is otherwise ZDR-eligible. Partner-hosted arrangements have their own enablement and data-location details. API retention requirements

A classifier refusal can arrive as HTTP 200 with stop_reason: "refusal" and a stop_details category. A client that treats every 200 as task success will misreport that outcome. Keep refusal, output-budget exhaustion, rate limiting, tool failure and invalid configuration as distinct application states. Refusals and fallback

Server-side fallback is opt-in beta functionality, not an assumption to make about every request. The documented permitted fallback targets include Opus 4.8 and Opus 5. Validate that the request is compatible with the chosen target; observe the model that actually served the response. Fallback is a supported response path, not a mechanism for evading policy.

A minimal request—and the boundaries around it

This illustrates a plain Claude API request. It is not an executed test, and it deliberately omits tools, caching and fallback to keep the request’s purpose clear. Account access and retention must already be configured.

{
  "model": "claude-fable-5-2",
  "max_tokens": 32768,
  "output_config": { "effort": "high" },
  "messages": [
    {
      "role": "user",
      "content": "Review this supplied migration plan. Identify unverifiable assumptions, propose acceptance tests, and finish with a concise decision."
    }
  ]
}

Adaptive thinking is on without a disabled or manual-budget setting. The example’s output cap is a real limit and may be insufficient for a difficult task; inspect the stop reason and choose a justified budget. For long requests, use the documented streaming API and distinguish thinking progress from delivered answer text. Messages API, streaming

For an agent, add controls outside the prompt: a maximum session spend, bounded delegation, deadlines, allowed tools, read-only versus write-capable credentials and a stop path. A per-response token cap does not bound dozens of tool turns or child-agent calls.

Prompting and rollout: make the task finishable

The model-specific prompting guide notes that requests to “answer without thinking” do not reliably suppress thinking at medium and above. Lower effort when that is the intended operating point. Also recheck old style rules: rigid sentence limits can produce choppy writing without reducing the work needed to solve the task. Prompting Fable 5.2

For a long engineering task, specify the artifact, ownership and stopping condition. “Improve this service” is open-ended. “Implement this migration, preserve these invariants, run these acceptance checks, and report unresolved failures” is reviewable. State whether nearby defects belong to the task and whether delegation is permitted.

At lower effort, include completion checks: the model may stop with remaining work or an offer to continue. At higher effort, watch delegation and repeated verification. The same project can become an expensive organization of agents unless the harness enforces scope and budgets.

Two mixed-model designs are worth evaluating. In an advisor design, a cheaper executor asks Fable for help at difficult decision points. In an orchestrator design, Fable coordinates bounded work delegated to smaller models. Consultation and child-agent usage are still billed, and delegation does not automatically create a separate security boundary. Select the pattern by measured quality, latency and total spend. Multiagent orchestration

Use a staged rollout:

1. Build a representative task set. Include routine work, a difficult long task, a visual input, a refusal, a tool failure and a long conversation.
2. Define acceptance before inference. Tests, source checks, factual completeness and human review effort should be explicit.
3. Run Opus and a Fable effort sweep. Hold tools, deadlines, source revisions and recovery rules constant where feasible.
4. Measure whole-task cost. Include retries, thinking, cache writes, tools, child agents and review. Record the final serving model.
5. Test failure paths. Edited prefixes, model switches, dropped reasoning, denied tools, budget exhaustion and unavailable dependencies all deserve evidence.
6. Canary the selected configuration. Retain the previous qualified route and compare accepted output per dollar and per minute.

The strongest business case is often an expensive task newly made feasible, rather than a prettier answer to a routine question. Measure that distinction. If the cheaper model meets the same acceptance bar, keep it in the route.

When Fable 5.2 earns its place

Fable 5.2 makes a compelling candidate for long software migrations, difficult tool-driven investigations, CAD and research workflows where progress can be validated. Mythos changes the access and safeguard arrangement for approved specialized work. Neither removes the need to choose effort, manage context and constrain an agent’s authority.

Start with a qualified baseline, escalate where the evidence supports it, and judge the result at the task boundary. The model’s real value is the work you can accept—not the number of tokens it was willing to spend.