Somewhere right now, an orchestrator agent is breaking a refactor into a dozen tickets and handing them to subagents, while the developer who launched it watches the token meter and asks the question of the season: Claude’s Opus 5.5 vs. Fable 5.1, which model deserves that seat? Anthropic released Claude Opus 5.5 on September 22 at $4 per million input tokens and $20 per million output tokens, against $10 and $50 for Claude Fable 5.1, and said the cheaper model performs at Fable’s level on most work. For once, the newest model isn’t the hungriest. When most of a bill is agents talking to agents, a 60% discount on every token is the difference between running a pipeline overnight and rationing it.
So the temptation is obvious: swap the model string and keep the difference. The trouble is that Fable-level performance on most work is a statement about averages, and agent systems fail at the tails. The evidence gathered in the three weeks since launch, from an independent security benchmark, from Anthropic’s own measured cost studies, and from developers running both models daily, points to a more useful answer than yes or no. The real trade-off is not between two models. It is between seats.
Why orchestrators turned model choice into a budget problem
The pattern is no longer experimental. In 2025, Anthropic described the multi-agent system behind Claude’s Research feature: a lead agent that plans the work and delegates it to parallel subagents, each with its own context window. With Claude Opus 4 leading and Claude Sonnet 4 subagents, the system outperformed a single Opus 4 agent by 90.2% on Anthropic’s internal research evaluation. The price was steep. Multi-agent runs consumed roughly 15 times the tokens of an ordinary chat, and token volume alone explained about 80% of the performance difference. That last number deserves a pause. Multi-agent systems work largely because they let a problem consume more tokens, which turns the per-token price of every seat into an architectural decision rather than an accounting detail.
Claude Code makes the stakes concrete. According to its documentation, a subagent’s model is resolved in a fixed order: the model passed for that specific call, then the model written into the subagent’s definition, then a project-wide environment variable, and only then the main conversation’s model. Leave the first three empty and every worker inherits the orchestrator’s model. A session running Fable 5.1 with unpinned subagents pays Fable rates for file searches and test runs. Anthropic appears to agree that this is wasteful: when the main conversation runs Fable on a Claude subscription or Console account, the built-in Explore agent drops to Opus by default.
What the price sheet hides about long agent loops
On paper, the gap is simple. Opus 5.5 costs 40 % of Fable 5.1 on input, output, and cache writes. But the line that matters most in agent work is different. Every turn of an agent loop resends the whole growing conversation, and Anthropic’s own cost guide reports that cache reads are routinely the largest single component of what an agentic task costs. On that line, Fable 5.1 charges $0.25 per million tokens and Opus 5.5 charges $0.20, according to the official price list. The 60% discount shrinks to 20.
This cuts both ways. A long-running orchestrator with a stable, well-cached prompt pays far less of a premium on Fable than the headline rates suggest. But Fable also punishes a broken cache harder than any other current model. Anthropic calculates that a single cache miss on a 100,000-token prefix costs 50 times the cached read on Fable 5.1, against 25 times on Opus 5.5. An orchestrator that stamps the time at the top of its system prompt, or switches effort levels mid-session, quietly turns Fable’s cheapest line into its most expensive one.
Opus 5.5 vs. Fable 5.1 on a benchmark that checks for memory
The most revealing independent test so far comes from Endor Labs, an application security company that runs a coding-agent leaderboard called the Agent Security League. Its tasks are built from real projects at the point where a historical security fix was made. The agent is never told a vulnerability is involved; it is only asked to follow security best practices. On September 24, Endor published its Opus 5.5 results, run inside Claude Code, the same harness it had used for Fable 5.1. The efficiency story was everything Anthropic promised. Opus 5.5 finished the full run for $116 in recorded spend, against $672 for Fable 5.1. Its mean task time was about four minutes versus nine and a half, and it made roughly 17 tool calls per task, while Fable made 42.
The capability story was different. Once confirmed cheating was removed, Opus 5.5 produced functionally correct code on 68.7% of tasks and code that was both functional and secure on 33.5%. Fable 5.1 reached 87.2 and 37.4%. Most of that gap comes from what Endor calls training recall: the model recognizing a fix it encountered during training and reproducing it instead of deriving it. Endor’s pipeline confirmed 51 such cases for Opus 5.5, the highest count on its board, against 17 for Fable. Counted as passes, the recalled solutions would have put Opus 5.5 first on security by more than 11 points. Removed, they cost it 25.7 points of functional score and 19 points of security score, while Fable lost 6.7 and 3.9. The recalled solutions were also the fastest, averaging three minutes and about 13.5 tool calls. Endor’s verdict on the connection is blunt: a model that recognizes its task is “both fast and, on this benchmark, not solving it.”
Here is why this matters beyond one leaderboard. Security fixes in public projects are exactly the kind of material a model can absorb in training. Your private codebase is not. If part of Opus 5.5’s speed comes from recognizing familiar problems, that shortcut disappears on genuinely unfamiliar work, such as the proprietary integration, the in-house protocol or the bug nobody has ever posted about, and what remains is derived reasoning, where Fable led in this test. That is an inference rather than a measurement, and it rests on a single benchmark. It is still the right question to put to your own workload.
Anthropic’s own numbers tell a more flattering story for Opus, and they are not wrong either. On a 478-problem subset of SWE-bench Pro, Anthropic measured Opus 5.5 at its default medium effort solving 92.8% of tasks for $0.22 per solved task, while Fable 5.1 at its default solved 92.3% for $1.19. That is the same result at about a fifth of the price. Anthropic notes, however, that both models largely saturate this subset. When a test is nearly maxed out, it can no longer separate two strong models; it can only tell you which one is cheaper. Endor’s recall-audited tasks are where the difference became visible.
Where Fable 5.1 still earns its price
Anthropic does not claim that Opus 5.5 replaces Fable. Its model selection guide now tells most workloads to start with Opus 5.5, yet still names Fable 5.1 as the choice when you need the highest capability, citing agent sessions that run for hours and multistep, deep research and analysis carried through to a finished document. The escalation rule is specific: if your evaluations at xhigh or max effort still fall short on demanding reasoning or long-horizon agentic work, move to Fable. The same guide carries a line worth printing above every model picker: “Tuning effort is often a better lever than switching models.”
The outside evaluator METR, whose findings appear in the Opus 5.5 system card, expects Opus 5.5 to deliver slightly more productivity uplift than Fable 5.1 but saw no evidence of a large improvement in judgment skills such as foresight, prediction, and research taste. Developers reached a similar conclusion by another route. In a widely discussed r/ClaudeAI thread asking why anyone would still choose Fable, the substantive replies converged on size: Fable is the larger model, better suited to long and ambiguous tasks, while Opus shines on well-scoped work. One upvoted reply compressed the argument into a single line: “Bigger model = more world knowledge on obscure topics.”
Fable’s edge is real, but narrow, and it carries costs of its own. In Anthropic’s internal test of translating the HAProxy load balancer from C to Rust, both models passed nearly all regression tests, yet Opus 5.5 finished in 9.5 hours against 12 and cost 51% less. In a research-report test where a single invented figure failed the report, 16 of 18 Opus 5.5 reports passed, and no Fable 5.1 report did. On long research loops, Anthropic found that Fable 5.1 can do more work per task, not less, and cost more as a result.
Reliability in unattended loops matters too. In a hands-on DevOps test by ComputingForGeeks, Fable 5.1 refused to write a routine Terraform security group opening ports 22 and 443 under a strict, tool-style system prompt, while Opus 5.5 produced valid code every time. The refusal depended on the prompt wording, but agents run on exactly that kind of prompt. Both models also hand most flagged cybersecurity requests to the older Opus 4.8, so in security-adjacent work, part of what you measure may be a fallback model rather than the one you chose.
Why a smarter orchestrator is not automatically a cheaper system
The intuitive architecture puts the most capable model on top and cheap models underneath. Anthropic has now measured that intuition in its cost and intelligence guide, and the results are sobering. In the advisor pattern, a cheaper executor runs the loop and consults a frontier model only on hard decisions. With Opus 5.5 at high effort as the executor and Fable 5.1 as the advisor, Anthropic’s internal coding benchmark rose by 1.7 points, at the edge of run-to-run noise, for about 2.1 times the cost, roughly what simply raising Opus 5.5’s own effort buys. An advisor can only help when it is asked. On a chart-reading benchmark, the executor consulted Fable on one task out of 300, and the pairing scored seven points below the executor working alone.
In the orchestrator pattern, the frontier model plans and hands bulk work to cheaper workers. Delegation paid off in exactly two situations Anthropic measured: routine work with a long tail of expensive cases, and work too large for a single context window. In the second case, a hunt for planted defects across 21.6 million tokens of Python source code, Fable 5.1 alone cost $468 to $552 per run and took 15 to 20 hours. A Fable 5.1 lead directing 25 Sonnet 5 workers cost about half as much and finished in about 2.3 hours, but scored 10 to 12 points lower. When the work was one dependent chain, or fit inside a single context, the orchestrator’s model running alone at lower effort outperformed it in every case measured. The lesson is uncomfortable for anyone who has drawn an elegant agent diagram. Fan-out buys speed and capacity. It doesn’t buy accuracy for free, and it doesn’t make dependent reasoning cheaper.
Sonnet 5.5 and Haiku 5.5 belong in the worker seats, with conditions
Below the two flagships, the 5.5 family filled in quickly. Claude Sonnet 5.5 arrived on September 28 at $2 and $10 per million tokens. On Anthropic’s SWE-bench Pro subset at its default high effort, it solved 87.6% of tasks for $0.11 per solved task, essentially matching Opus 5.5 at low effort, which solved 87.4% for $0.12. On Anthropic’s harder internal coding benchmark, the gap reopened: 77.8% for Sonnet 5.5 against 86.6% for Opus 5.5, each at its default.
Effort is where Sonnet 5.5 can surprise a budget. Artificial Analysis measured about 193,000 output tokens per task at max effort, the highest it has recorded, at $7.60 per task, and placed the model off its frontier of intelligence per dollar, with high effort as the most competitive setting. Sonnet 5.5 is a strong implementation worker for well-specified tickets at high effort. At max effort, it becomes an expensive imitation of Opus.
Claude Haiku 5.5, released on October 7, changes the economics of the bottom tier. At $0.10 and $0.50 per million tokens for prompts up to 100,000 tokens, it makes a subagent call nearly free. On GPQA Diamond, a graduate-level science test, it scored 85% against Opus 5.5’s 91% at about a twentieth of the cost per correct answer. Anthropic is explicit about its ceiling, saying Sonnet 5.5 and Opus 5.5 remain the better choices for complex agentic coding; on Terminal-Bench 4.0, Haiku scores 39.2% to Sonnet’s 70.6.
Two traps sit in Haiku’s price sheet. Any request whose prompt exceeds 100,000 tokens, cache reads included, pays five times the rate on every token, output included. And once workers are this cheap, the cost migrates to the orchestrator that digests their output. In one developer’s worked example from published prices, eight Haiku research subagents under an Opus 5.5 lead cost $0.13 in total, while writing their reports into the Opus context and re-reading them across later turns cost $0.14. A worker that reports only that the authentication logic lives in the middleware, rather than returning file paths and line numbers, forces the expensive model to re-read.
A routing map built on measured results
Put the evidence together, and the original question dissolves into a better one: not which model, but which model for which seat.
| Seat in the system | Start with | Escalate to | Escalate when |
|---|---|---|---|
| Orchestrator and planner | Opus 5.5 at medium or high effort | Fable 5.1 | Sessions run for hours, the problem is ambiguous or has little public precedent, or Opus at xhigh or max still fails your evaluations |
| Implementation worker | Sonnet 5.5 at high effort | Opus 5.5 at medium effort | The ticket spans many files, needs design judgment, or fails its tests twice |
| Search, exploration, summaries and compaction | Haiku 5.5 at low or medium effort, prompts under 100,000 tokens | Sonnet 5.5 | A prompt will cross 100,000 tokens, or the output feeds a decision nobody verifies |
| Review and security-relevant fixes | Opus 5.5 plus deterministic tests and scanners | Fable 5.1 | The logic is novel or security-critical, where recall cannot help |
| On-demand advisor | Off by default | Fable 5.1 as advisor | Your evaluations show the executor actually consults it and the gain beats simply raising effort |
Two practices make the map pay. First, when outcomes are checkable, start cheap and escalate only the failures. In Anthropic’s measurements, running Opus 5.5 at low effort and re-running failed tasks at high effort solved about 97% of tasks for roughly $0.17 each, against 95.3% for $0.29 with everything at high. Second, pin both model and effort in every subagent definition, and compare models at deliberately chosen effort levels, since Opus 5.5 defaults to medium and Fable 5.1 to high. Nothing should inherit the orchestrator’s rates by accident.
For security-relevant code, trust none of them blindly. Even Fable 5.1, the top result on Endor’s board, produced code that was both functional and secure on only 37.4% of tasks. Deterministic tests and scanners are not optional in any routing scheme.
Back to the orchestrator splitting its refactor into a dozen tickets. Most of those tickets are familiar problems under new names, and Opus 5.5, Sonnet 5.5, and even Haiku 5.5 will finish them faster and for a fraction of the price. One or two are not. They are the ticket with no precedent, the decision that shapes the next six, the code that has never existed anywhere a model could have read it. That is where the extra money buys something. The skill that matters now is not choosing the smartest model. It is recognizing which problems are truly new.
Follow us on X, Facebook, or Pinterest
