Server-Side Fallback
Server-side fallback retries a request that was refused, within the same API call. You name up to three fallback models, and when Claude Fable 5 declines, the API runs the next model in the chain on the same request. You get back a response naming the model that answered, so your user gets an answer in one round trip.
On a streaming request, the retry happens on the same stream, and nothing you have already received is invalidated. If the decline happens mid-output, the fallback model continues from the partial output. For a non-streaming request, if a decline occurs mid-output, the response omits the declined model's partial output, and the fallback model responds from scratch.
Client-Side Fallback With The SDK Middleware
The TypeScript, Python, Go, Java, and C# SDKs include a refusal-fallback middleware. You configure it once on the client with your list of fallback models. Calls through client.beta.messages then retry refused requests automatically, on any platform.
Fallback Credits
At this point, you might be wondering what happens to prompt caches, since they are typically set per model. When Claude Fable 5 declines a request and you retry on another model, the conversation prefix that was already cached for Claude Fable 5 must be written into the new model's cache from scratch. Cache writes cost more than cache reads, so this would be problematic for your costs. However, Anthropic released a mechanism called fallback credit that removes that extra cost. The refusal carries a credit token, you then echo the token on the retry, and the retry is billed as though the conversation had been on the new model all along.
When using server-side fallback, this happens automatically on the server. When using the SD middleware, it automatically sends the fallback-credit-2026-06-01 beta header on every fallback request it handles, so retries are repriced without per-request setup. If you're using the Ruby or PHP SDK, sending requests over raw HTTP, or using custom retry logic, you need to set this up manually by following this page.
Estimating Fable 5's cost for a real workload therefore takes two inputs: token volume and how much of the traffic sits in or near the three classifier domains (or it may get mistakenly classified as if it belonged to those domains). A general-purpose workload will bill close to the Fable rate (assuming a low number of false positives, for example, when trying to perform a security review on the code), while a workload that gets frequently caught by the classifiers will land somewhere between Fable and the fallback model you use.
Data Retention and Conditional Behavior
Fable 5 also arrives with a data-handling requirement that applies regardless of workload. Anthropic requires 30-day retention for all traffic on Mythos-class models, including Fable 5, Mythos 5, and future models with similar or higher capabilities. This applies to both Anthropic's own surfaces (Claude.ai, Claude Desktop, Claude Code, Claude Design, and the Anthropic API) and to third-party platforms such as Amazon Bedrock.
Retaining traffic data lets Anthropic detect attacks that unfold across many requests and eventually reduce false positives from the model's guardrails. The company says the data is not used to train models, that human access is logged, and that data is deleted after 30 days in nearly all cases. On AWS, meeting the requirement has an additional consequence: invoking Fable 5 on Amazon Bedrock requires opting into data sharing by setting data_retention to provider_data_share, and AWS's documentation very clearly states that shared data leaves AWS's security boundary.
Conclusion
Fable 5 is Anthropic's first publicly available Mythos-class model, made fit for the public with safeguards, then blocked due to a lack of confidence in those safeguards, and now made available again with improved safeguards.
The launch comes with very strong claims, and each carries a boundary that is easy to lose in a roadmap or a budget:
- “Most capable” does not mean “best for every task”, neither in performance on specific tasks nor on price-performance. From our perspective, the advantage of Fable 5 is fully realized for long, complex, autonomous work. Short, well-scoped requests are just as good and far cheaper on Opus 4.8, Sonnet 5, or Haiku 4.5.
- Cybersecurity, biology and chemistry, and distillation requests (and anything that the classifiers mistakenly flag as those categories) are refused and must be handled with a different model.
- The 30-day retention requirement makes data handling a significant part of the adoption decision.
The teams running long-horizon, agentic, or document-heavy work that earlier models could not perform reliably have the most to gain. The teams that run workloads near the classifier domains of cybersecurity, life sciences, or model distillation, or that have data-handling requirements that the 30-day retention complicates, might prefer or be forced to skip Fable 5 entirely.
Fable 5 is generally available as claude-fable-5 on the Claude API, and through Amazon Bedrock and the Claude Platform on AWS as anthropic.claude-fable-5. The model is also available to Claude subscribers on Pro, Max, Team, and Enterprise plans, with a maximum of 50% of their plan's capacity available for Fable.
How Caylent Can Help
Whether you're evaluating Claude Fable 5 for autonomous software development, document intelligence, or complex agentic workflows, Caylent can help you identify where its capabilities deliver meaningful business value and where other models may be a better fit. As a Preferred Services Partner and Charter Member of the Claude Partner Network, and an AWS Premier Tier Services Partner, we help organizations assess model selection, navigate governance and data retention requirements, optimize costs, and build production-ready AI solutions on Amazon Bedrock that balance performance, security, and operational efficiency. Get in touch with us today to get started.
Guille Ojeda
