← Blog

Is Claude Fable Really Better Than Opus

Well, yes. Obviously. I feel the difference every time I use them for planning, and many benchmarks agree.

But that’s not the question I wanted answered. The real question: if a detailed implementation plan already exists, which model completes the implementation at a cheaper price point? In other words, which model is the better implementer? Let’s find out.

Test Setup

V2 isn’t ready yet, so I scuffed together a V1.5 on top of the old 10-card benchmark, with one key change: every model got a detailed implementation plan up front — the architecture, the order of operations, and the usual traps to avoid.

That makes this less an end-to-end test of engineering ability and more a test of whether a model can carry a long, fiddly implementation all the way through without going off-script.

Here’s the full field:

Configuration Runs Mean pass rate (range) Mean $/run
Opus 4.8, xhigh effort 6 83.1% (80.7–85.5) $29.35
Fable 5, medium effort 3 82.3% (80.7–83.1) $37.96
Fable 5, xhigh effort 10 (3 partial runs excluded) 81.9% (77.1–86.8) $47.07
Fable 5, high effort 3 81.5% (77.1–85.5) $38.49
Sonnet 4.6, high effort 5 71.6% (66.3–77.1) $10.24

Learning 1: Fable 5 Is Overkill

Fable 5 is the newer, shinier model, so the obvious bet is that it pulls ahead of Opus. It doesn’t. Zoom in on the frontier configs:

Configuration Pass rate (range) ~ tests / 83 Mean $/run
Opus 4.8, xhigh effort 83.1% (80.7–85.5) 69.0 $29.35
Fable 5, medium effort 82.3% (80.7–83.1) 68.3 $37.96
Fable 5, xhigh effort 81.9% (77.1–86.8) 68.0 $47.07
Fable 5, high effort 81.5% (77.1–85.5) 67.6 $38.49

Every config lands within about one test of every other, and the run-to-run spread inside each config dwarfs the gaps between them. If anything, Opus is nominally ahead.

That’s a statistical tie — except Fable charges ~1.6x more per run to get there. On structured implementation work, that premium buys you nothing.

Reasoning effort buys nothing either. Fable at medium effort matches Fable at xhigh while taking noticeably less wall-clock time. If you’re running structured coding pipelines on Fable, the cheap setting is the right setting.

The why is the interesting part. Fable is the bolder model: it’s far more willing to reach into the engine itself and rewrite core code to make a card behave, where Opus works with the engine as it finds it. Sometimes that pays off — Fable owns the single best run of the round (86.8%). Just as often, those sweeping edits quietly break the hidden tests other cards depend on.

That’s why Fable’s runs swing so much wider (77.1–86.8) than Opus’s steadier band (80.7–85.5). Against a hidden test suite, boldness cuts both ways often enough to hand the steadier, cheaper incumbent the edge.

Learning 2: Sonnet Shows Its Age

Sonnet 4.6 is the budget workhorse and the oldest model in the lineup. Here the gap stops being subtle.

Configuration Pass rate (range) ~ tests / 83 Perfect cards / 10 Mean $/run
Opus 4.8 / Fable 5 (best configs) 81.5–83.1% ~68–69 3.0–3.3 $29–47
Sonnet 4.6, high effort 71.6% (66.3–77.1) 59.4 3.4 $10.24

Sonnet’s best run (77.1%) barely reaches the frontier models’ worst. That’s not run-to-run noise — it’s a whole tier down.

The gap is roughly nine to ten tests per run — an order of magnitude bigger than anything separating Fable from Opus. The frontier models differ by fractions of a test; Sonnet trails by a whole card’s worth of functionality.

One wrinkle: Sonnet loses on breadth, not on finish. It actually completed slightly more cards perfectly per run (3.4 of 10) and touched the engine the least — it nails the cards it understands and quietly flubs the edges of everything else.

And yes, at a quarter of Fable’s price, Sonnet is by far the cheapest per run. But paying a third of the cost to lose a tenth of the tests is the wrong trade for real engineering work.

I’ll re-run this on Sonnet 5.x when I get the chance. Until then, I’m leaning Opus for real work.

What Still Resists Everyone

What none of the models can crack is surprisingly concentrated. Ten of the 83 tests have never been passed by any model in any run — they need deep engine subsystems no agent has built yet — so the practical ceiling sits around 88%. Fable owns the closest run at 86.8%.

One card, a double-faced card with token creation and a “prepared” back-face mechanic, is just a wall: 24 of 27 runs scored 1 out of 6 on it, and no run has ever passed its five hard tests. Another card is pure variance, with its 13 tests swinging anywhere from 2 to 12 passed depending on whether the model happens to guess a few engine interfaces right.

Every test is checked against a reference implementation, so none of this is a grading artifact. These are real capability gaps, and they’re the same ones for every model.

The Takeaway

The more you spell everything out, the less room a newer model has to be cleverer than the last one. That’s exactly the regime where Opus 4.8 wins: it’s the cheapest path to the top score, and it edged ahead because of the hand-holding, not despite it.

So if your work has a precise spec, a fixed API, and a disciplined workflow: don’t pay the Fable premium, and don’t crank the reasoning dial. The one thing that does still cost you is reaching back a generation — that’s where the real gap lives.

And the next real gains won’t come from model shopping. They’ll come from whoever builds the engine subsystems those ten stubborn tests are waiting for.

Closing Remarks

I know this post came a bit late (I was distracted by the World Cup). But I think the lessons here are still quite relevant, so better sharing it now than never.

I’m currently still working on V2, as well as another exciting project that’s hopefully coming soon.