Claude Sonnet 5 vs Claude Fable 5

I saw a lot of hate around Claude Sonnet 5 when it dropped, which honestly felt weird because I don’t remember the older Sonnet releases getting this kind of reaction.

Usually, Sonnet launches are pretty chill. People test it, say it is great at coding, complain about limits, and move on.

But the Sonnet 5 release was different.

The complaints were mostly about cost, token usage, and whether Sonnet 5 even makes sense anymore when Opus and Fable exist.

Which is funny, because on paper Sonnet 5 sounds exactly like the model I would want to use. 🤷‍♂️

Near-Opus agentic performance, better coding, better tool use, huge context, and cheaper pricing than Opus.

A cheaper Sonnet that can get close to Opus for real coding work? That sounds like the perfect daily driver.

So I wanted to test it properly. And what better model to test it against than Fable 5, which just recently became public again after all that Trump drama earlier.

TL;DR

If you want a quick take, here is how both models performed in these tests:

• Fable 5: Clear winner overall. It handled both the agentic coding test and the Clash Royale-style game much better. Faster, cleaner, and the game build worked in one shot with no noticeable bugs in my run.
• Claude Sonnet 5: Definitely better than Sonnet 4.6. I could see improvements in its agentic capabilities, and the UI work was genuinely good. But in longer coding sessions, the cost gets ugly fast. More time, more cost, more code, and still needed a lot more fixes.
• Cost/value: This is where Sonnet 5 gets hard to defend. It is supposed to be the cheaper near-Opus model, but in my tests it did not feel any cheaper in practice.

For coding, I don’t really see the point of Sonnet 5 right now. It is good, but not good enough to justify the added cost in longer agentic coding sessions.

⚠️ NOTE: Don’t treat this as some universal benchmark. This is just a small set of practical coding tests, but the cost and token usage gap was bad enough that it is hard to ignore.

Brief on Sonnet 5

Sonnet 5 just dropped, around 4 days old by the time of writing this post. A long-awaited Sonnet release.

Not because Antrhopic is calling it the best model ever again. Every lab says that every 3 business days at this point. 🫩

It has pretty much the same selling point, near-Opus-level performance, but this time it's more of a near-Opus level agentic performance.

On benchmarks, it does look like a solid jump from Sonnet 4.6. Sonnet 5 scores around 63.2% on SWE-bench Pro, compared to 69.2% for Opus 4.8. On Terminal-Bench 2.1, it gets around 80.4%, which is pretty close to Opus 4.8 at 82.7%. It also gets 81.2% on OSWorld-Verified, again sitting close to Opus territory.

So yeah, the pattern is pretty clear. Opus 4.8, which is the premium frontier model from Anthropic is still dominating, but Sonnet 5 comes pretty close when tools are involved.

Since we’re comparing it with Fable 5, the question is simple: can the cheaper Sonnet 5 keep up with the heavier, more expensive model on real coding tasks?

It also comes with a 1 million token context window and up to 128K output tokens, which is huge for long codebases, repo-wide refactors, docs, and agentic workflows.

But here's where things get a little different.

Sonnet 5 uses Anthropic’s newer tokenizer, and the same input can produce around 1.0x to 1.35x more tokens depending on the content. So even if the model looks cheaper per token, your actual task can still cost more because it may burn more tokens to do the same thing.

Pricing is also a bit of a drama. During the launch window, Sonnet 5 is $2 per million input tokens and $10 per million output tokens. After that, it goes to $3 input / $15 output, while Opus 4.8 sits at $5 input / $25 output.

So, on paper, Sonnet 5 is cheaper than Opus.

But on tasks? Not always 🤷‍♂️.

Some independent testing says, Sonnet 5 can end up costing more per task than Opus 4.8, mostly because it uses more output tokens and more agentic turns, especially at higher effort levels.

Sonnet 5 also supports multiple effort levels like low, medium, high, xhigh, and max. Higher effort means more reasoning, but also more tokens, more latency, and more cost. So running everything on max effort might not be the smartest move unless the task really needs it.

And that is exactly why the internet reaction is kind of bad right now.

Sonnet, as you know, is more of a general family of AI models, so just know that we got a more agentic-capable model in cheaper price.

Now, let's see if it actually does any better in the coding problems.

Test Workflow

For this comparison, I wanted to test these models on two different kinds of coding tasks.

One will be more serious and agentic, focused on how well the model can work inside an existing codebase. The other is more of a visual, fun, Twitter-styled test where we test it in coding a web game. You'll see in a minute.

So the test is going to be something like this:

1. Task 1: Build a Web-Based Clash Royale-Style Game

For this task, each model had to build a small browser-based Clash Royale game.

The game should have two sides, towers, deployable cards, units walking toward the enemy side, attacking behavior, health bars, basic enemy AI, win/loss conditions, you get the idea.

This one is going to be more of a vibe test. Not just vibe coding, but also judging the actual vibe of the game like how good it looks, and how smooth it feels.

We’ll compare both models based on code quality, completion, bugs, visual output, token usage, cost, time to complete the build, and of course, the overall vibe.

2. Task 2: Build a RAG Debugger in OpenWebUI

For the final test, I wanted something more real-world and agentic.

So I cloned the Open WebUI repo locally and gave both models the same feature request inside that codebase.

Open WebUI is a huge project, around 400K lines of code, with a proper frontend, backend, RAG system, document upload flow, Knowledge area, APIs, settings, and all that.

The task was to add a RAG Debugger.

Basically, instead of just chatting with a document and seeing the final LLM answer, I wanted a way to inspect what the RAG system is actually doing before the model answers.

The debugger should show things like document processing status, extracted text preview, generated chunks, chunk metadata, retrieval results for a test query, source info, and score/confidence where available.

Coding Tests

1. Build a Web-Based Clash Royale-Style Game

The task was not so simple. Both LLMs are being asked to build a full Clash Royale-style game, which, if you’ve played it, is a pretty big and complex tower defense game.

You might have seen people on Twitter trying to build things like Mario, balls in a circular pit, and similar projects. But those feel like unworthy tests for our models.

Fable 5 and Sonnet 5 are both supposedly beast models, so the test has to match their level.

The models have to build a full Clash Royale-style game with lobby support, custom decks, human-versus-human gameplay, human-versus-bot gameplay, and a lot more.

If you’ve played the game, you know how messy the logic gets, from sprites to attacks, defense, targeting, movement, and all those unit interactions.

💁 PROMPT: You can find the prompt here Web-Based CR Prompt

Fable 5

Fable 5 absolutely cooked on this one.

I honestly expected a decent browser game, maybe a good-looking demo with half the game logic working. But what it built was way more complete than that.

It had the full flow of what's asked in the prompt:

• card collection
• custom deck builder
• matchmaking lobby
• PvP mode
• real-time battle screen
• practice vs bot mode
• elixir-style system (similar to that in Clash Royale)
• cards/troops/buildings
• just so much more...

And the craziest part is all of that worked (hate to say it, but in one shot) 😵‍💫

Movement, attacking, tower defense, targeting, tower health, health bars, card deployment, win conditions, all of it worked like a charm.

The elixir system was also done properly. You start with energy, it regenerates over time, maxes at 10, and doubles in the final 60 seconds.

💁 Of course, the sprites and characters don’t really look that right, but that is not a code problem at all. That is completely outside the coding part. For a coding test, this is already insane.

The architecture was probably the most impressive part.

The client only sends intents like deploy, surrender, emote, and ready. The server validates everything before changing the game state: card in hand, energy cost, placement zone, match phase, side ownership, and all that.

All to say, it was not hacky implementation at all. It actually built it like a real multiplayer game.

To make things even insane, there are about 31 Vitest tests covering all parts of the game implementation.

After the build was done, Fable installed Playwright to visually inspect the app. It opened the game, took screenshots, checked how things looked, and used that to verify the implementation.

Proper AI agent moment. What it did here in one shot was completely out of the world for me.

It took around 45 minutes to complete the build. In my run, I could not find a single noticeable bug.

You can find the code it generated here: Fable 5: Clash Royale

Here's the demo:

• Cost: $27.97
• Duration: 41min 7sec API time, 48min 16sec wall time
• Code Changes: +5,817 lines, -32 lines
• Token Usage:
  • Claude Haiku 4.5: 5.2k input, 35 output
  • Claude Fable 5: 10.4k input, 183.5k output
  • Cache read: 13.5M
  • Cache write: 260.8k

💁 NOTE: The whole run cost me around $28, which is definitely not cheap. But Fable 5 is a costlier model, and considering the input/output token pricing, the cost feels fair. The result also makes it much easier to justify, because this was not a half-working demo. It was a proper, playable build.

Claude Sonnet 5

Sonnet 5 also did a decent job on this test.

The implementation was big, and honestly the UI looked even better than Fable 5 in some places. Sonnet still has this weirdly good taste with frontend work.

But this run was not as smooth.

First, I hit the classic Next.js hydration error again.

I don’t even know what to say about this error anymore. Sometimes it shows up even in a fresh Next.js scaffold. Just one of those weird Next things.

In the first run, most of the implementation looked ready, but I couldn’t drop troops into the arena at all. So the game looked good, but the core interaction was broken.

After a few back and forth fixes, Sonnet finally found the issue and got troop deployment working.

Once fixed, the game was actually pretty good. The UI was polished, the arena looked nice, and the overall implementation was more complete than I expected.

But then the time and cost showed up, and this is where I started losing my mind a bit.

This session took 1h 9min 49sec API time and 1h 33min 46sec wall time.

For context, Fable 5 finished its build in around 45 minutes.

And somehow, Sonnet 5 still cost more.

Like, what are we even doing here?

The final cost was $33.85. That is more than my Fable 5 run.

The code changes were also bigger:

• Sonnet 5: +7,056 lines, -30 lines
• Fable 5: +5,817 lines, -32 lines

So Sonnet took longer, wrote more code, needed more fixes, and still ended up costing more.

You can find the code it generated here: Claude Sonnet 5 Code

Here’s the demo:

• Cost: $33.85
• Duration: 1h 9min 49sec API time, 1h 33min 46sec wall time
• Code Changes: +7,056 lines, -30 lines
• Token Usage:
  • Claude Haiku 4.5: 5.2k input, 30 output
  • Claude Sonnet 5: 60.5k input, 404.9k output
  • Cache read: 64.4M
  • Cache write: 1.6M

2. Build a RAG-Debugger in OpenWebUI

The prompt was pretty simple: add a useful RAG Debugger without rebuilding the whole RAG pipeline.

💁 PROMPT: You can find the prompt here RAG-Debugger Prompt.

Fable 5

Fable 5 nailed it.

It found the right parts of the Open WebUI codebase, understood the existing RAG flow, added the backend logic, and added a working UI for the debugger.

The best part is that it did not build some fake separate RAG thing. It actually reused the existing Open WebUI retrieval flow, which is exactly what I wanted.

I tested it locally by uploading a document and running test queries through the debugger. It showed the chunks, metadata, source details, and retrieval scores properly. So you can actually see what Open WebUI is pulling before the LLM gets involved.

That is the whole point of this feature.

The RAG Debugger tells you why that answer probably happened.

And Fable did all of this in one shot.

It took around 23 minutes to implement, which is honestly crazy for a feature inside a repo this big.

You can find the code it generated here: Fable 5: OpenWebUI RAG-Debugger

Here's the demo:

• Cost: $16.11
• Duration: 22min 54sec API time, 25min 14sec wall time
• Code Changes: +687 lines, -8 lines
• Token Usage:
  • Claude Haiku 4.5: 2.2k input, 34 output
  • Claude Opus 4.8: 10.9k input, 23.7k output
  • Claude Fable 5: 23.6k input, 58.7k output
  • Cache read: 7.6M total
  • Cache write: 369.2k total

That was a very strong result.

💁 For me, this is exactly what an agentic coding model should be good at: enter a large codebase, understand where the real logic lives, add a useful feature, and make it work locally.

Claude Sonnet 5

Sonnet 5 had a pretty similar result on this one.

No real complaints here.

It understood the Open WebUI repo, found the right places to make changes, and implemented the RAG Debugger properly. The feature worked, the UI was usable, and the overall implementation felt solid.

The only real difference was the approach.

Fable 5 went with a more recommended route where you can debug retrieval across the whole Knowledge base. Sonnet 5 implemented it more around inspecting one document at a time.

I personally prefer Fable’s approach, because RAG usually happens across a knowledge collection, not just one file. 🫩 But this is more of a preference than a model failure.

It took slightly longer than Fable and wrote a bit more code, but this time it was actually a bit cheaper:

• Fable 5: 22min 54sec API time, +687 lines, $16.11
• Sonnet 5: 27min 5sec API time, +847 lines, $12.05

Not a big deal.

You can find the code it generated here: Claude Sonnet 5: Open WebUI RAG Debugger

Here's the demo:

• Cost: $12.05
• Duration: 27min 5sec API time, 56min 3sec wall time
• Code Changes: +847 lines, -0 lines
• Token Usage:
  • Claude Haiku 4.5: 2.2k input, 34 output
  • Claude Sonnet 5: 36.8k input, 134.4k output
  • Cache read: 24.4M
  • Cache write: 515.7k

Overall, this was a good Sonnet 5 run.

Conclusion

Both Fable 5 and Claude Sonnet 5 did well in this test.

But for me, the winner was pretty clear.

There's not much to say about Fable 5. It's the flagship model, and it does great work with coding and all. So I had high expectations and it delivered.

Sonnet 5 was not bad at all. It's an improvement over Sonnet 4.6 of course. I still think Sonnet has this weirdly good frontend taste compared to the other models.

But the actual coding session was frustrating.

Like what do you mean it cost more than Fable which is a lot costlier based on token pricing, for the same task for long running tasks?

And that is where Sonnet 5 feels weird to me.

It is marketed as the cheaper near-Opus coding model, but in this run, none of it was cheaper. It was slower than Fable, more expensive than Fable, and needed extra fixing.

That is just a bad trade.

Sonnet 5 is good, sure. But for coding, I don’t see the point right now. Use Opus for the hard stuff, or Fable if you want the better coding run.