Claude Fable 5.1 vs Claude Opus 5: SWE-bench Verified Coding and Cost Per Solved Issue (September 2026)

Anthropic made Claude Fable 5.1 generally available on September 1, 2026, and the independent BenchLM coding rankings now put it on top of SWE-bench Verified at 83.9, ahead of Claude Fable 5 at 77 and Claude Opus 5 at 75.7. That is a clean win on pass rate. It is also the wrong number to make a decision on, because the thing you pay for in a coding agent is closed tickets, and closed tickets cost tokens. Here is the comparison first, then the arithmetic that decides which model is cheaper to run.

Headline Comparison

Dimension	Claude Fable 5.1	Claude Opus 5
GA date	September 1, 2026	July 24, 2026
Positioning	Top coding tier	Top reasoning tier
Context window	500K tokens	500K tokens
Input price, per 1M tokens (list)	$5.00	$5.00
Output price, per 1M tokens (list)	$25.00	$25.00
SWE-bench Verified (BenchLM, Sept 2026)	83.9	75.7
Median tokens per solved issue (our harness)	lower	higher
Typical failure	gives up early on a sparse repo	over explores, edits too many files

The list prices sit at the same tier, which is the first thing that makes this comparison sharper than most. When two models cost the same per token, the only levers left are how often each one solves the task and how many tokens it spends getting there. Fable 5.1 wins the first lever outright on the public number. The second lever is the one we measured, and it is where the two models separate in a way the leaderboard cannot show. Treat the pass rate as directional and the token counts as controlled test results from a fixed harness, not as a promise about your repository, which has its own shape.

What SWE-bench Verified Actually Rewards

SWE-bench Verified is a curated subset of real GitHub issues where a human confirmed the task is solvable and the hidden tests are fair. A model is handed a repository and an issue, and it has to produce a patch that makes the failing tests pass without breaking the passing ones. It is a genuinely agentic benchmark: the model reads files, forms a hypothesis, edits, and its patch either passes the hidden suite or it does not. That structure is why the score tracks real engineering utility more closely than an algorithmic puzzle test does, and it is also why the score alone hides the cost story. We wrote a full breakdown of what the number does and does not capture in what the SWE-bench Verified score measures, and the short version is that pass rate counts outcomes and ignores the token bill entirely.

Two models can reach the same patch by very different routes. One reads four files, writes a six line diff, and passes. The other reads forty files, writes three candidate patches, reverts two, and passes on the third. Both score one point. One costs five times the other. SWE-bench Verified records the point and throws away the difference, so if you stop at the leaderboard you are optimizing for the wrong variable.

The Cost Per Solved Issue Picture

Here is the method, kept deliberately boring so the numbers mean something. Same scaffold for both models, same maximum retry budget, same tool definitions, native tool calling rather than prompt hacks, one harness, tasks drawn from the SWE-bench Verified distribution. We recorded total input and output tokens for every attempt, then divided total token spend by the count of issues actually solved. That last step is the one that matters. Dividing by attempts flatters a model that fails cheaply; dividing by solved issues charges each model for its own failures, which is exactly how your invoice works.

Fable 5.1 solved more issues and, in our runs, spent fewer median tokens per solved issue. It tends to localize the fault faster and edit a smaller surface, so a win costs less and its failures are cheaper too because it does not thrash. Opus 5 has a different personality under the same harness. It is a stronger open ended reasoner, which is precisely why it over explores on a bug fix: it reads more of the repository than the task needs, entertains more hypotheses, and edits a wider set of files, so even its successes carry a heavier token load. On a pure reasoning task that breadth is an asset. On a scoped bug fix with hidden tests it is mostly overhead you pay for. We saw the same split on algorithmic work in the Opus 5 vs Fable 5 LiveCodeBench comparison, where the reasoning tier does not automatically win the coding tier's home game.

The practical read: at equal list price, the model with the higher pass rate and the lower tokens per solved issue is cheaper on both axes at once, and that is Fable 5.1 for straight repository bug fixing. The case for Opus 5 is not price, it is the class of task where the extra exploration is the point.

Where Opus 5 Still Earns Its Tokens

Do not read the above as retire Opus 5. The two models are tuned for different jobs. When the task is genuinely open ended, a design that has to be reasoned out, a gnarly refactor that spans subsystems, an incident where the failure mode is unknown and the model needs to explore before it can act, Opus 5's breadth stops being overhead and becomes the reason it finds the answer at all. SWE-bench Verified deliberately excludes that ambiguity by confirming each task is solvable and fairly tested, so it structurally undersells the exact strength Opus 5 leads on. We compared Fable 5.1 against the frontier reasoning tier on messier agentic work in the GPT-6 Astra vs Fable 5.1 agentic coding writeup, and the ordering there is not the ordering here, which is the whole point. Pick the model to the task, not to the leaderboard.

FAQ

Is Claude Fable 5.1 better than Opus 5 for coding? On SWE-bench Verified pass rate, yes: 83.9 versus 75.7 on the September 2026 BenchLM rankings, and in our harness Fable 5.1 also spent fewer tokens per solved issue. For scoped bug fixing at equal list price it is the cheaper and stronger choice. For open ended reasoning tasks the answer flips.

Do they cost the same per token? At list, both sit at the same top tier in our reference figures, five dollars per million input and twenty five per million output. Because token prices match, the deciding factor becomes tokens spent per solved issue, not the sticker rate.

Why divide by solved issues instead of attempts? Because your bill is driven by every token you send, including the ones spent on failed attempts. Cost per solved issue charges each model for its own misses, which is the honest unit for budgeting an agent that retries.

Should I switch our agent from Opus 5 to Fable 5.1? For a repository bug fixing agent, it is worth an A/B on your own tasks; the public numbers and our harness both point that way. For an agent doing design or open ended investigation, keep Opus 5 in the loop and measure before you move.

When This Applies to Your Stack

If you run a coding agent at volume, the leaderboard row is the least useful number you have. What decides your monthly spend is cost per solved issue on your repositories, with your scaffold, your retry policy, and your test suite, and the only way to know it is to run both models through one fixed harness and divide token spend by tickets actually closed. Fable 5.1 leads the public coding benchmark and, in our controlled runs, closed issues for fewer tokens; Opus 5 keeps its edge where the task is open ended enough that exploration pays for itself.

If you are standing up an agentic engineering workflow and want the model choice grounded in your own cost per solved issue rather than a leaderboard, that measurement harness is the kind of thing we build with teams. Contra Collective works on AI integration and agent engineering for teams putting these models into production, and getting the evaluation right is usually the cheapest decision you make all quarter.