My default would be Sonnet 5 for interactive work and Fable 5 for difficult, expensive-to-fail tasks. That is a routing policy, not a claim that one model wins everywhere. The useful comparison is how much a completed, validated workflow costs, including retries, latency, and human intervention.
The reported benchmark gap is substantial: Fable 5 scores 80.3% on SWE-Bench Pro versus Sonnet 5's 63.2%, with a reported 96% on SWE-Bench Verified for Fable. But benchmark results alone do not tell me which model should review a small pull request or process a support ticket.
Start with the Evidence and Its Limits
The release timeline matters for understanding availability. The source describes Fable 5 and Mythos 5 launching on June 9, 2026, followed by an access suspension on June 12 because U.S. export controls required nationality checks Anthropic could not perform in real time. It reports that the controls were lifted on June 30 and access began returning on July 1. Sonnet 5 was announced on June 30.
Those are reported release details, not independently verified results from my own testing. The same distinction applies to the performance figures below. I would check current provider documentation before making an availability or pricing commitment.
There are also inconsistencies worth resolving before budgeting. The source's pricing table calls Sonnet's $3/$15 rates introductory, while its more detailed pricing section specifies $2/$10 through August 31, 2026, followed by $3/$15 starting September 1. I use that explicit schedule below. Its claims that Sonnet fits either 70–80% or 80–90% of workloads are not useful deployment targets without a defined workload distribution.
What Actually Changes Between the Models?
| Dimension | Fable 5 | Sonnet 5 |
|---|---|---|
| Intended role | Frontier reasoning and long-running agents | High-throughput coding and automation |
| Context window | 1M tokens | 1M tokens |
| Synchronous Messages API maximum output | 128k tokens | 128k tokens |
| Reported SWE-Bench Pro | 80.3% | 63.2% |
| Input/output price per million tokens | $10/$50 | $2/$10 introductory; $3/$15 standard |
| Interaction profile | Higher latency, particularly at maximum effort | Better suited to interactive workloads |
Fable is described as Anthropic's most capable widely released model, with Mythos-class capabilities and additional safety classifiers. Its stated strengths include sustained autonomous work, difficult software engineering, scientific reasoning, vision, spatial reasoning, and legal analysis. The source lists a January 2026 reliable knowledge cutoff and says batch output limits can exceed the synchronous limit; it does not provide a batch maximum.
Sonnet 5 is positioned as a major upgrade from Sonnet 4.6, not a new frontier relative to more capable Opus- or Mythos-class models. Its system-card description places it below Mythos 5 on every automated AI research and development evaluation. That does not make it a poor agent model: the reported OSWorld and Terminal-Bench results suggest strong performance at medium effort.
Both support text, images, files, and advanced tool use. Equal context limits do not imply equal ability to reconcile contradictory documents or maintain a plan through a long sequence of edits and tool calls.
Latency Is Part of the Model Choice
The source reports Sonnet time-to-first-token around 2–3 seconds on optimized providers and output throughput of 50–70+ tokens per second. Fable can take 100+ seconds at maximum effort. These are reported observations, not latency guarantees or a controlled comparison across identical workloads.
I would evaluate interactive and asynchronous jobs separately. A deeper result may justify a long wait for a migration plan, but not for every developer-chat response. Higher effort can increase generated tokens, latency, and cost alongside quality, so effort settings belong in the evaluation matrix rather than being fixed at maximum.
Price the Workflow, Not Just the Request
Using the explicit schedule attributed to Anthropic's pricing documentation, a request with 100,000 input tokens and 10,000 output tokens has the following base token cost:
| Model and rate period | Input cost | Output cost | Total |
|---|---|---|---|
| Fable 5 | 0.1 × $10 = $1.00 | 0.01 × $50 = $0.50 | $1.50 |
| Sonnet 5, through August 31, 2026 | 0.1 × $2 = $0.20 | 0.01 × $10 = $0.10 | $0.30 |
| Sonnet 5, from September 1, 2026 | 0.1 × $3 = $0.30 | 0.01 × $15 = $0.15 | $0.45 |
At standard rates, Fable costs roughly 3.33 times as much for that token allocation; at introductory rates, it costs five times as much. Neither calculation includes caching discounts or the rest of an agent's execution.
Four equivalent Sonnet attempts at standard rates cost $1.80, more than one $1.50 Fable attempt. That does not establish that Fable will succeed first time, but it explains why lower token prices are not enough to choose a model. I care about validated completions, not cheap failed attempts.
Sonnet 5 also uses a newer tokenizer that can increase token counts for the same text. Reusing an older model's token estimates can therefore distort a migration budget. Measure actual usage, use prompt caching for repeated context, consider batch APIs for non-urgent work, and retrieve relevant material instead of attaching everything.
Where I Would Route Each Workload
Coding and Long-Running Agents
Sonnet is my starting point for bounded bug fixes, code explanations, unit tests, documentation, pull request review, and interactive repository questions. Fable is the candidate for large migrations, unfamiliar repositories, ambiguous requirements, and multi-file work that requires planning, editing, testing, recovery, and continuation.
A practical escalation rule is to move to Fable when a task fails twice, crosses many files, requires substantial architectural reasoning, or carries unusually high business value. I would treat that rule as a starting hypothesis and tune it against internal evaluations. Classification, formatting, and issue triage can remain on cheaper models.
Documents, Retrieval, and Research
Long input alone is not a reason to pay for Fable. Sonnet is the sensible starting point for normal RAG, policy questions, support knowledge bases, invoice extraction, meeting summaries, and document search.
Fable becomes more interesting when the task requires comparing contracts, building a financial model from multiple exhibits, tracing an argument across hundreds of pages, or resolving contradictory sources. I would retrieve and extract first, then escalate difficult synthesis rather than sending every document directly to the most expensive model.
The source reports a Fable lead on BrowseComp, but a smaller gap than on the hardest coding evaluations. That supports testing Sonnet as the default browsing agent and reserving Fable for deeper investigations, conflicting evidence, and high-stakes recommendations.
Visual Tasks and Support Automation
Fable's reported strengths include screenshot-to-code, scientific figures, raw visual-state interpretation, and SWE-Bench Multimodal. I would evaluate it when visual reasoning determines whether the task succeeds. Sonnet remains a practical candidate for screenshot review, chart explanation, UI feedback, PDF/image questions, and support attachments.
For customer support, Sonnet's lower cost and latency make it the default candidate. Complex enterprise tickets, technical debugging, legally sensitive cases, and unresolved escalations deserve a separate evaluation path. Community writing comparisons also describe Fable as stronger on prose texture and Sonnet as faster for drafting, but those anecdotes are not substitutes for application-specific tests.
Migration and Safety Details I Would Not Skip
Sonnet 5 uses adaptive thinking by default, with effort-style controls replacing older manual extended-thinking budgets. The source identifies low, medium, and high effort settings. Migration notes also warn that non-default temperature, top_p, and top_k settings can be rejected. I would audit shared request builders before switching models, especially where old sampling defaults are injected automatically.
For Sonnet, I would keep prompts concise and test effort levels explicitly. For Fable, I would provide constraints, relevant files, evaluation criteria, and success conditions, then ask it to plan, execute, validate, and report uncertainty. Neither approach removes the need for external validation.
Fable's safeguards cover cybersecurity, biology, chemistry, and model distillation. According to the described launch behavior, classifiers may route higher-risk requests to Opus 4.8, with users informed of the substitution. The reported aggregate is less than 5% of sessions triggering safeguards and more than 95% involving no fallback. Those averages do not predict the rate for a security-heavy application.
I would log model substitutions and handle refusals explicitly, without treating another model as a way around a safety decision. A unified multi-model API such as CometAPI can simplify routing integration, but endpoint support, live pricing, and fallback behavior still need verification.
The Decision I Would Ship
I would start with Sonnet, expose a deliberate escalation path to Fable, and evaluate both on the same representative tasks. The measurements that matter are completion quality, cost per successful workflow, time-to-first-token, total runtime, retries, human corrections, and safeguard-triggered substitutions.
Parameter counts, activated parameter counts, and full architecture details are not established here. Neither are future independent benchmark results, future Opus or Mythos releases, or stable third-party marketplace prices. My routing policy would remain revisable: use the cheaper model where it reliably completes the job, and pay for the stronger model where measured outcomes justify it.
Originally published at cometapi.com
Top comments (0)