What happened
On 9 November Anthropic released two models: Claude Fable 5.2 and Claude Mythos 5.2. Fable 5.2 is available to every API customer, and on Amazon Bedrock, Google Cloud and Microsoft Foundry. Mythos 5.2 goes only to organizations verified through Anthropic's programs, such as the one for cybersecurity teams.
The price went down. Fable 5.2 costs USD 8 per million input tokens and USD 40 per million output tokens, against USD 10 and 50 for Fable 5.1. Cache reads drop from USD 0.25 to USD 0.20 per million tokens. Fast mode costs twice the standard rate.
The data terms did not change. Both models are Covered Models: they require 30-day retention and do not run under zero data retention (ZDR) unless Anthropic expressly authorizes it. A request from an organization without retention enabled fails with a 400 error.
What is new is a way around it. Anthropic justifies retention by saying some misuse only shows up as a pattern across many requests, not in a single response. Under Enterprise Frontier Safeguards (EFS), automated safety monitoring runs on prompts and responses stored in the customer's own infrastructure, which Anthropic says makes it compatible with ZDR. EFS is in private beta. Eligible customers can use the new models under zero retention before they implement EFS. Everyone else has 30-day retention.
The documentation holds two more points that did not make the headlines. Anthropic itself advises starting most workloads on the latest Opus model and moving to Fable only when Opus at a higher effort level still fails your evals. Opus 5.5 costs USD 4 and 20, half the price of Fable 5.2. And the default effort on Fable 5.2 is high, while on Opus 5.5 it is medium. A request that does not set effort runs one level higher after the switch, and the difference shows up only in cost, latency and results. A prompt line such as "answer directly, without deliberating" no longer stops the model from thinking at medium and above.
Our take
This is our interpretation. In August we wrote that zero data retention had become a property of the model rather than a vendor promise, and that Anthropic planned to move monitoring data into the customer's cloud. EFS is that plan in working, if still closed, form. The price cut will get the headlines, but for a European company the second change matters more.
A lower rate card does not mean a lower bill. The price per token fell, but a model that thinks before almost every reply and runs one level higher by default spends more tokens on the same task. Anyone who swaps the model ID and nothing else can end up with a bigger invoice at a smaller rate. Speculation: this will happen most often on simple tasks such as classification or pulling fields out of a document, where extra thinking improves nothing. The only way to check is on your own tasks.
EFS does not bring back zero retention in the old sense. It is a swap: the data sits with you instead of the vendor, and the vendor's monitoring runs on it. For the security team that is good news, because the data stays in your infrastructure. But someone has to store it, secure it and enter it in the record of processing activities. Nothing we read says how long the data has to stay with the customer or who can join the beta. Those are questions for your Anthropic account team, not for the developers.
The third point is model choice. If the vendor itself says "start with Opus", Fable should be an exception defended by an eval result, not the default because it is "the best model". For an organization with ZDR and no access to EFS, the choice is already made today: Opus runs under zero retention, Fable does not.
Why it matters
Private Equity
If a portfolio company tells its customers their data is not stored, ask for the list of models actually called in production and check whether any of them is a Covered Model. A cheaper release is exactly when someone switches retention on in one workspace "just for a test". Ask too whether anyone measured cost per task after the model change, rather than just comparing rate cards.
Enterprise
If you have ZDR and need Fable, ask your account team about EFS now, before teams start pushing for "the cheaper top model". In parallel, decide who on your side would hold the monitoring data and on what terms. That is a change in processing, which touches the impact assessment and the processing register, not just the API configuration. Before any migration, set effort explicitly and re-run your evals on your own data.
SMB / mid-market
Do not switch to Fable because it got cheaper. If you run on Opus today and the results are good enough, Fable 5.2 still costs twice as much per token. For agents built on ready-made patterns from our product library, the model and the effort level are written into the specification next to the data terms, so changing either one is a decision, not an incidental upgrade.
One move this week
Take one production task that runs on Opus today and push 50 historical cases through Fable 5.2 twice: with effort set to medium and to high. Compare quality, latency and cost per task, not per token. If your organization has ZDR, run the test in a separate workspace with retention enabled, and only on data that may sit with the vendor for 30 days. If you have no such data, hold the test until you know whether you are joining EFS. Describe your case: mailto:[email protected]?subject=Rozmowa%20z%20Aurora%20AI