Claude Fable 5.2 for Plugin Work: The Hidden Secret Cost to Know Now

Short answer: Claude Fable 5.2 is Anthropic’s top public model, released on 9 November 2026 at $8 per million input tokens and $40 per million output tokens, and Anthropic itself says most coding work should still start on Claude Opus 5.5. For WordPress plugin work, that is our reading too. We would keep Opus for writing, fixing and reviewing everyday plugin code, keep Sonnet for investigation, content and releases, and keep Fable for the few jobs where a cheaper model has already come up short. We have not run Fable 5.2 on our own tickets yet, so everything below is either Anthropic’s documentation, a clearly labelled third-party number, or our own routing rules. We say which is which.

If you read our post on Claude Opus 5.5 for WordPress plugin work, this is the next chapter, and it follows the same shape: what the vendor says, how we route work today, what to watch for, and how to test it yourself before you change anything.

The short version

• What it is: Claude Fable 5.2, model ID claude-fable-5-2, released 9 November 2026. Anthropic says Fable and Mythos are the same underlying model, with Fable carrying strong cybersecurity and biology safeguards so it can be offered to everyone.
• Price: $8 input and $40 output per million tokens. That is double Opus 5.5 ($4 and $20) and four times Sonnet 5.5 ($2 and $10).
• Anthropic’s own advice: start with Opus 5.5 for most coding and knowledge tasks, move up to Fable for the most ambitious, open-ended technical work, or down to Sonnet or Haiku when the job is simpler.
• The number a third party gave it: Artificial Analysis lists Fable 5.2 at 65 on its Intelligence Index. That is an independent index, not a WordPress test, and we treat it as one data point.
• Something agencies must check: Anthropic’s docs say Fable 5.2 requires 30-day data retention and is not available under zero data retention unless Anthropic expressly authorises it. If a client contract promises zero retention, that matters before anything else.
• What we have not done: run it on our own plugin tickets. We will not quote speed or quality numbers we do not have.

What is Claude Fable 5.2, in plain facts?

This section comes from Anthropic’s launch announcement and its model page. We read both directly.

• Name and ID: Claude Fable 5.2, claude-fable-5-2 on the Claude API. The docs list the same ID on Google Cloud and Microsoft Foundry, and anthropic.claude-fable-5-2 on Amazon Bedrock.
• Released: 9 November 2026. The docs list retirement as not sooner than 9 November 2027.
• Purpose: Anthropic describes it as built for demanding reasoning and long-horizon agentic work, such as agent sessions that run for hours, multistep research and analysis carried through to a finished document.
• Size: a 1 million token context window and up to 128,000 tokens of output.
• Price: $8 per million input tokens, $40 per million output tokens. Cache reads are $0.20 per million, a five-minute cache write is $10, and the Batch API takes 50 percent off.
• Fast mode: optional, up to 2.5 times faster token generation, at $16 per million input and $80 per million output.
• Thinking: adaptive thinking is always on and cannot be turned off. You steer it with the effort setting, and the default for Fable 5.2 is high. That is different from Opus 5.5, whose default is medium.
• Knowledge cutoff: June 2026.
• Speed claim: Anthropic says it generates output up to 30 percent faster than Fable 5.1, and costs less than Fable 5.1 did.

What is Mythos, and do you care?

Anthropic says Claude Mythos 5.2 is the same underlying model as Fable 5.2, without the cybersecurity and biology safeguards, offered only to organisations that pass its verification programs. A plugin agency building WordPress features will almost certainly be on Fable. The reason to know about Mythos is simple: if someone tells you a benchmark number is “Mythos”, that is the restricted version, and some of Anthropic’s published security numbers are for it. We mark those when we mention them.

How does it compare with the rest of the lineup?

Anthropic’s model overview lists the current four side by side. We put the numbers that matter for agency budgeting in one table.

Model	Input / output per million tokens	Default effort	Latency (Anthropic)	Anthropic’s description
Claude Fable 5.2	$8 / $40	high	Moderate	Demanding reasoning and long-horizon agentic work
Claude Opus 5.5	$4 / $20	medium	Moderate	Long-running agentic coding and knowledge work
Claude Sonnet 5.5	$2 / $10	high	Fast	Best combination of speed and intelligence
Claude Haiku 5.5	From $0.10 / $0.50	medium	Fastest	High-volume, latency-sensitive tasks

All four have a 1 million token context window and 128,000 tokens of maximum output. The big differences are price, default effort and speed. The default effort row is the one people miss. A model that thinks at high effort by default will, other things equal, spend more output tokens per turn than one that defaults to medium, and output tokens are the expensive ones.

What did Anthropic say about coding and cost?

Here we are reporting the vendor’s claims, from its own tests. They are not our measurements.

• Against Opus 5.5: Anthropic’s benchmark table shows Fable 5.2 ahead of Opus 5.5 on most of the tests it listed. On FrontierCode 2.0, which Anthropic describes as measuring whether a model’s code changes would be merged by the maintainers of open-source repositories, Fable 5.2 at its highest listed setting scores 49.1 percent against 45.5 percent for Opus 5.5. On FrontierSWE v2, a second agentic coding test, it lists 69.9 percent against 62.3 percent for Opus 5.5 and 65.5 percent for a competing model.
• The cost claim: Anthropic says that at high effort Fable 5.2 scores about the same as Opus 5.5’s best on FrontierCode 2.0 (45.3 percent against 45.5 percent) for roughly half the cost per task. That is a claim about cost per task, and it is the most interesting sentence in the announcement for anyone paying a bill, because the per-token price is double.
• Efficiency: Anthropic says that at medium effort, the default in Claude apps and Claude Code, Fable 5.2 completes challenging tasks with fewer tokens than Fable 5.1.
• Judgment: Anthropic says Fable 5.2 shows strong engineering judgment and can produce high-quality results from ambiguous requests.
• Roles: Anthropic says Fable 5.2 can act as an advisor that smaller models consult when a task gets hard, or as an orchestrator that hands simpler tasks to smaller models.

The announcement also includes customer quotes from companies that tested it early, and some very large demonstrations, such as a team of agents migrating a production service from Python to Rust and an operating system built by more than a thousand subagents over eight days. Those are impressive, and they are also Anthropic’s showcase examples. None of them is a WordPress plugin, and none of them says how the model behaves on a 12-year-old plugin with global state and three other plugins hooking into it. Read them as a sign of the ceiling, not as a promise about your Tuesday ticket.

What the benchmarks do not tell you

No benchmark in the announcement tests WordPress. FrontierCode and FrontierSWE use other kinds of repositories. A model can be better on those and still make the same mistake on your plugin that every model makes: fixing the one code path the ticket named while the sibling callers stay broken. That mistake is about reach and verification, not about raw intelligence, and it is exactly what the ten-ticket test later in this post is built to catch.

What did the third-party score say?

Artificial Analysis, an independent group that tracks model performance, lists Claude Fable 5.2 at a score of 65 on its Intelligence Index, in the Max setting, and ranks it first among the 74 models on that page when we read it. The same page repeats Anthropic’s $8 and $40 pricing and shows an output speed of about 103 tokens per second. We opened the page ourselves, and we are calling it third-party because it is not Anthropic’s number.

Two cautions. First, an index is an average across many tasks, and plugin work is a narrow slice of them. Second, rankings move within weeks as new models arrive, so a number like this is a snapshot, not a verdict. We would use it to decide whether Fable is worth a trial, and we would use our own tickets to decide whether it is worth a budget line.

We also looked for The Verge’s coverage of the launch to cite it. We could not find it when we searched, so we are not quoting it. The coverage we did find from other outlets agreed with Anthropic on the date, the price and the model ID.

Which model does which job on our team, today?

This is our own routing, and nothing in this section changes because Fable exists. It is the rule we would hand to a new developer.

• Opus for code. Writing code, fixing code and reviewing code: plugin features, REST endpoints, tests, security and performance reviews, and turning a bug report into a patch.
• Sonnet for everything else. Investigating and reproducing a bug, release notes and packaging, support drafts, content, documentation, site operations and research.
• Find the cause on Sonnet, then write the fix on Opus. Investigation ends in a short brief: the evidence, the root cause with file and line, the reach of the bad data across every reader and writer, and what is not yet verified.
• Escalate on purpose. If a root cause survives one fix attempt, or the work is a cross-plugin architecture decision, or a security review of a money or sign-in path, we flag it in one line and recommend the larger model. A person decides.

That last line is where Fable 5.2 fits. Until now, “the larger model” on our list meant the most capable one available at the time. Anthropic’s own wording for Fable, jobs that are ambitious and open-ended, is close to our escalation list. So the honest plan is not “move the team to Fable”. It is “treat Fable as the model we escalate to, and test whether it earns that spot”.

Where we would try Fable first

1. A bug whose root cause survives one fix attempt. This is a hard, narrow job, and the cost of one extra run is small next to another day of a person’s time.
2. A cross-plugin architecture decision. For example, how a free plugin and its paid add-on should share one data table, where a wrong call is costly to undo.
3. A security review of a payment or sign-in path. Review is where a careful, expensive pass is worth paying for, and we would still review the result ourselves.
4. A large, long migration run with subagents. This is the shape of work Anthropic highlights, and the one where fewer wasted turns could outweigh a higher rate.

Where we would not

• Drafting a release note, a support reply or a docs page. A cheaper model does these well, and the result is checked by a person anyway.
• Quick lookups and small edits. High default effort on a one-line change is money spent for nothing.
• Anything where the client contract rules out 30-day retention (see below).

What does a session cost, in list-price arithmetic?

This is arithmetic from published prices, not a measurement. It ignores caching, batching and the thinking tokens a model spends, which count as output. Suppose a long coding session reads 200,000 tokens and writes 20,000.

Model	Input cost	Output cost	Total
Sonnet 5.5 ($2 / $10)	$0.40	$0.20	$0.60
Opus 5.5 ($4 / $20)	$0.80	$0.40	$1.20
Fable 5.2 ($8 / $40)	$1.60	$0.80	$2.40
Fable 5.2 fast mode ($16 / $80)	$3.20	$1.60	$4.80

Read this table in two ways. At list price, one Fable session costs twice an Opus session. But Anthropic’s own claim is that Fable at high effort can match Opus at its best for about half the cost per task. If that held on your work, the two lines would meet in the middle, and the per-token price would stop being the number that matters. Cost per accepted change is. That is why we do not decide from the rate card.

Fast mode deserves its own sentence. It doubles the price again for up to 2.5 times the speed. A person waiting at a screen may value that. An overnight migration run does not. We would reserve it for interactive debugging where the wait is the expensive part, if we used it at all.

For the wider picture of how limits and spend behave when several agents run at once, see our post on running several AI coding agents without hitting the wall. The routing and context rules in it apply to a pricier model even more than to a cheaper one.

What should a developer check before pointing code at it?

This section is for developers and technical leads. Decision makers can skip to the next heading.

If you only use Claude through a coding tool, the tool handles most of this. If you ship a plugin or an internal tool that calls the API, Anthropic’s model page lists these behaviours for Fable 5.2. We would check each one before changing a model string.

Thinking cannot be turned off

• What the docs say: adaptive thinking is always on. You control depth with the effort parameter.
• Quick check: search your request builders for any setting that disables thinking or sets a manual budget.
• Fix: remove it, then choose an effort level for each kind of call. Because the default for this model is high, set a lower level on purpose for small, simple calls and measure.

Forced tool use returns an error

• What the docs say: a forced tool choice of the any or tool type returns a 400 error.
• Quick check: search for your tool choice setting.
• Fix: use automatic tool choice, and validate output on your side whatever the schema promises.

Sampling parameters must be omitted

• What the docs say: omit temperature, top_p and top_k, because some values return a 400 error.
• Quick check: grep for those names in any shared client code.
• Fix: drop them from the request. If your plugin exposes a “creativity” slider that maps to temperature, that setting needs a different home for this model.

Classifier refusals and fallback

Anthropic says Fable 5.2 blocks high-risk cybersecurity requests and most research-biology tasks, and that blocked requests fall back to an older model. Anthropic reports about 55 percent fewer blocks than Fable 5.1 in its testing. For most WordPress work this will never appear. It can appear in security work: asking a model to write exploit code for a plugin vulnerability, even to prove a fix, is the kind of request a classifier may stop. The docs have a page on handling refusals and retrying on another model, and we would build that retry in before relying on the model for security tooling.

Preserved thinking

The model page says editing earlier turns invalidates thinking blocks, for every account. If your tool rewrites earlier messages to trim context, test that it still behaves, because it may now cost you the cached reasoning.

One place for the model string

Whatever you change, change it in one adapter. WordPress 7.0 added a core AI client, and our own standard is to prefer it where available and keep a small provider adapter as a fallback for older installs. A new model should be a one-line change in that adapter, not a search across twenty call sites.

The data retention question, for agencies

This is the part we would read first if we were a client or an agency lead. Anthropic’s model page says Claude Fable 5.2 requires 30-day data retention and is not available under zero data retention unless Anthropic expressly authorises it. The announcement says other customers have 30-day retention for safety monitoring, and describes a separate private beta of an enterprise option in which monitoring runs in the customer’s own infrastructure.

For an agency, the practical questions are plain:

1. Do any of your client contracts or data-processing terms promise zero retention for the AI tools you use on their code or data?
2. If so, is Fable in or out of scope for that client’s work?
3. Who on your team decides, and where is it written down?

We are not saying this is a problem. We are saying it is the kind of question that is cheap to ask before a model is switched on and expensive to ask afterwards. Read the exact retention wording in Anthropic’s documentation, and compare it with your own agreements. Do not rely on our summary for a legal decision.

How can you test it on your own plugin tickets?

You do not need a lab. You need ten tickets and a notebook. This is the same method we described for Opus 5.5, adapted for a model that defaults to high effort and costs more per token.

1. Pick ten closed tickets whose correct answer you already know. Include at least three that you would normally escalate: a bug that took more than one attempt, a change touching more than one plugin, and a review of a sensitive path.
2. Freeze the starting point. Check out the repository at the commit before each fix. Give every run the same ticket text and the same project guidance file.
3. Run each ticket on Opus 5.5 and on Fable 5.2 at explicit effort levels. Do not use the defaults, because they differ between the two models. Try Opus at medium and high, and Fable at medium and high.
4. Score the same things every time: did the tests pass, did the fix reach every caller of the changed code, did the diff stay small, how many turns, how many output tokens, and how many minutes a person spent reviewing.
5. Add a negative case. For each bug, keep the test that fails on the old code. A run that passes your tests but would also pass the old code proved nothing.
6. Compare cost per accepted change. A cheap run a person has to redo is the most expensive run you can buy. If Fable costs twice as much per run and gets accepted twice as often on the hard tickets, it is the cheaper choice for those tickets.

The point of including your hard tickets is that Anthropic itself says the extra capability is for the hardest work. If Fable does not beat Opus on the tickets where Opus struggled, it will not beat it on the easy ones either, and you have your answer for the price of ten runs.

The scoring sheet we would use

Question	How to record it
Did the tests pass?	Yes or no, from your own test run, not the model’s report
Did it fail the negative case on the old code?	Yes or no
Did the change reach every caller?	Count of callers you listed beforehand, and how many were handled
How large was the diff?	Files and lines changed
How many turns and output tokens?	From the tool’s usage report
How long did review take?	Minutes, written down by the reviewer
Was it accepted without rework?	Yes or no

What about long, unattended runs?

Anthropic’s examples lean heavily on agents that work for hours and coordinate subagents. If you plan to try that on a migration or an audit, the habits we described for Opus apply with more force, because each wasted turn costs more.

• Treat a text-only end of turn as a report, not as proof the task is finished.
• Keep the task’s parts in a checklist file the model updates, so progress shows in a diff and survives a context reset.
• Stop after two or three automatic continuations on the same task, so a stuck run ends and a person looks at it.
• Set a spending cap per run before you start, not after the first surprise.
• Review the subagents’ output as you would a junior team’s. Anthropic’s own customer quote about a 10 to 12 hour audit, with about 170 reviewer agents, ended in a write-up and fix pull requests. Someone still has to read those pull requests.

Our post on layering CLAUDE.md for WordPress developers covers how to keep project guidance short enough to survive long runs, which matters more as runs get longer.

Where is it better, and where is the evidence thin?

Where the evidence points to better

• Capability on hard agentic coding tasks. Anthropic’s tests show Fable 5.2 ahead of Opus 5.5, and a third-party index puts it at the top of its list. Both are real signals, from different sources.
• Cost per task at high effort. Anthropic claims roughly half the cost per task of Opus 5.5 for similar FrontierCode results. That is a claim to test, and a promising one.
• Price against Fable 5.1. At $8 and $40, it costs less than Fable 5.1 did ($10 and $50, according to the Opus 5.5 model page we cited earlier).

Where we have no data

• Our own results. None. We have not run the ten-ticket test, and we will not publish numbers until we do.
• WordPress-specific behaviour. No benchmark in the announcement covers it.
• Plan limits. The announcement mentions a promotion tied to subscription plans and usage limits. Plans and limits change, so read the terms on Anthropic’s own pages for your plan and do not plan around a blog summary.
• Real behaviour at scale. Anthropic reports that high-stakes misalignment risk remains low and publishes a system card. Independent testers named in the announcement include the UK AI Security Institute and METR. We have not reviewed their reports, and we are not in a position to add to them.

What should an agency change this week?

1. Do nothing to your default routing. Opus for code, Sonnet for the rest. Anthropic’s own advice points the same way.
2. Add Fable to the escalation line, not to the default. Name the two or three situations that justify it, and who approves.
3. Check data retention against client agreements before any client code goes near it.
4. Set effort on purpose. The default for Fable is high, so set a lower level for small jobs.
5. Run the ten-ticket test with your hardest closed tickets before deciding.
6. Audit your API call sites for thinking, tool choice and sampling settings if you ship anything that calls Claude.

What should a non-technical owner take from this?

Three things. First, a more capable model does not mean a bigger bill by default. The bill depends on how many turns a job takes and which model does which job, and a good routing rule matters more than the rate card. Second, ask your lead developer two questions: which situations would justify the most expensive model, and who decides? If neither has an answer in writing, spend will drift. Third, ask about data. A model that keeps prompts for 30 days is fine for many projects and wrong for some. The right answer comes from your contracts, not from a vendor’s marketing.

If you would like a second opinion on how your own team routes work between models, or what it costs, get in touch.

Frequently asked questions

What is the model ID for Claude Fable 5.2?

On the Claude API it is claude-fable-5-2. Anthropic’s docs list anthropic.claude-fable-5-2 for Amazon Bedrock and the same ID as the API for Google Cloud and Microsoft Foundry.

How much does Claude Fable 5.2 cost?

$8 per million input tokens and $40 per million output tokens. Fast mode, which Anthropic says is up to 2.5 times faster, costs $16 and $80. The Batch API takes 50 percent off standard prices.

Is Fable 5.2 better than Opus 5.5 for WordPress plugin work?

Anthropic’s tests show it ahead on most agentic coding benchmarks, and Anthropic still recommends starting with Opus 5.5 for most coding work. Nobody has published a WordPress-specific comparison that we know of. Test it on your own hard tickets.

What is the difference between Fable 5.2 and Mythos 5.2?

According to Anthropic they are the same underlying model. Fable has strong cybersecurity and biology safeguards and is available to everyone. Mythos is offered only to organisations verified through Anthropic’s programs.

Can I turn thinking off on Fable 5.2?

No. Adaptive thinking is always on. Use the effort setting to control how much the model thinks. The default effort for this model is high.

Does Fable 5.2 support zero data retention?

Anthropic’s docs say it requires 30-day data retention and is not available under zero data retention unless Anthropic expressly authorises it. Check the current wording on the model page and compare it with your client agreements.

What did Artificial Analysis score it?

Artificial Analysis lists Claude Fable 5.2 at 65 on its Intelligence Index, and ranked it first of the 74 models on the page when we read it. That is a third-party figure and rankings change as new models launch.

Should my team switch everything to Fable?

We would not. Keep Opus for everyday code and Sonnet for investigation, content and releases, and use Fable for the few hard jobs where a cheaper model has already struggled. Measure before you change the default.

A closing thought

A new top model always tempts people to rewire everything in a week. The cheaper habit is dull: keep the routing rule, add one escalation line, check the retention terms, test ten hard tickets, and move only the work that scores well. We will publish our own numbers after we have run them, and not before.