After several weeks of being blocked, we finally have Fable 5 available as a model in Anthropic, and what we are going to do is evaluate it, comparing it against the rest of Anthropic's models and then placing it on a general chart together with the other models we have analyzed.
For this I use my Github - Coding evals project, where you can see all the scores and where each one fits.
Table of Contents
1 - When should you use Fable 5?
The big difference between Fable 5 (or Sonnet 5) is not the level of code it is going to generate for you, but autonomy. The idea behind Fable is that you give it an objective and it should iterate until it achieves that objective.
These models are not designed for you to hold their hand, but rather for those global objectives. Think about your day-to-day life as a programmer: you have an epic, which is divided into tasks, and each task has its implementation.
With Sonnet 4.6 you have to investigate manually, think for yourself, reason things out, look at the code and understand it. Then, finally, you tell Sonnet where to make each change and how, so that everything makes sense.
With Opus 4.8 you can delegate the investigation and have a conversation about whatever comes up until, in the end, without writing code, it reaches the final goal. In many cases it requires several iterations with the model, either in the conversation part or personally having to iterate on the code by hand. As you can imagine, it gets much better results than Sonnet, but it is also much more expensive.
With Fable 5 it is different: you give it an objective, and Fable is the one that operates and iterates until it achieves the objective. Going back to the programmer example, it could be the epic: Fable investigates the task, understands it, divides it and implements it, all automatically. And if Opus used tokens, Fable is on another level. Not only that, but it also costs twice as much per token. So if you set it to do very heavy tasks, or tasks you know are long, it is going to take a lot of time and cost a fortune. A real fortune, not rhetorically speaking.
2 - Evaluation of Anthropic's models
In the end, this post is about evaluating what the new model is like, and in this case we are going to evaluate all of them.
In our case, we are going to continue with the 2026.06 test, which consists of two tests, both using the code from Distribt, which is a simulation of a distributed system written in C#.
A - Code review
The first task is a code review, where we present a PR to the model so it can evaluate it. This PR has issues (many of them), and the idea is to see how many it is capable of finding.
The general idea of the code change is a system that allows us to apply discounts to product prices.
B - Feature implementation
The second task is to implement a feature end to end, following the examples of other features we have in the code, checking how well it is implemented and whether it is correct. In this case, the code implementation is a feature to cancel orders.
So this does not become a massive post, I am going to include summaries in each section, but everything will be available in detail both on GitHub and in the YouTube video.
Obviously, to do this properly I have to clear memory, etc., between each of the tasks.
One note worth mentioning is that I noticed they took a very long time. In other tests I have done, both GLM 5.2, GPT-5.5, etc., the result was relatively fast. With Anthropic's models it took much longer.
2.1 - Analysis of Claude Sonnet 4.6 for development
The first model we are going to start with is Sonnet 4.6, and the idea of starting with this model is that we can treat it as a baseline to see where we are coming from.
Obviously, we could compare it with another model, either open source like GLM 5.2 or from other companies, but I think starting from Sonnet 4.6 as the baseline is ideal.
A - What is Sonnet 4.6 like for doing code reviews?
Sonnet 4.6 found 10 issues, most of which are correct: the integer division that always returns zero, publishing the event before confirming the write, the static dictionary that simulates a cache (although only halfway, because it did not mention the memory issue until a later finding), Math.Round with double instead of decimal, the test that validates absolutely nothing, etc.
What it missed: that the endpoint always returns 200 because the method always returns true, the cancellation token that is not being passed, the try/catch that swallows all exceptions, and the ID validation in the handler. It also did not fall into either of the two traps, but since I do not indicate the associated finding, there is no penalty.
Result: 64/100. And let me tell you one thing: 64 out of 100 is an acceptable mark.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-4.6/task1_code_review_evaluation.md
B - What is Sonnet 4.6 like for programming complete features?
Here things start to get a bit shaky, since it did not write tests, which, while not a requirement, no software should ship without tests.
From there, the endpoint exists but does not follow the style of the rest of the project (cancel goes in the URL instead of following the convention of the other endpoints), although it does use the result pattern without exceptions, it prevents a canceled order from being canceled again, follows DDD principles with its Apply, respects idempotency (it does not generate another event if it is already canceled), and passes cancellation tokens everywhere.
Result: 70/100, very acceptable.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-4.6/task2_feature_implementation.md
Total Sonnet 4.6: 134 points, which puts it above GPT-5.5 in the ranking. Hey, not bad.
NOTE: I made all these scores "live" during the video, and for some reason Sonnet 4.6 takes much longer than the rest, and even spends more tokens, something I still do not understand even after editing the video. The effort was the same as with the rest, so I have no idea what happened there.
2.2 - Analysis of Claude Sonnet 5 for development
Now that we have the baseline, we can move on to the models that are better, but obviously more expensive. The theory says that Sonnet 5's behavior for code review should be similar, a bit better but similar, while the feature implementation is where the difference should be noticeable, since these models are evolving toward autonomy in long tasks.
A - What is Sonnet 5 like for doing code reviews?
Sonnet 5 has been quite a bit faster and cheaper than Sonnet 4.6, which is already good news. It found practically the same things: the integer division, the static dictionary (this time yes, mentioning that it grows without limits, so full points), the cache key with the wrong price, double instead of decimal, publishing the event without guarantees, the lack of input validation, the test that validates nothing, and the cancellation token that is not passed.
It missed the try/catch (it mentions that it can cause errors, but not that it always returns true, which is what I want it to tell me) and the ID validation in the handler.
Result: 72/100. A tiny bit better than Sonnet 4.6, but much, much faster.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-5/task1_code_review_evaluation.md
B - What is Sonnet 5 like for programming complete features?
This is where it fell short. The endpoint and the result pattern are perfect, it prevents a canceled order from being canceled again, follows DDD with the Apply, and passes the cancellation tokens.
But for some reason it did not generate the domain event, so there is no handler, no real idempotency via events, and that whole block of points collapses. And on top of that, a 10-point penalty for putting the tests in the wrong project.
Result: 60/100.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Sonnet-5/task2_feature_implementation.md
Total Sonnet 5: 132 points. As you can imagine, Sonnet 4.6 beating Sonnet 5 in this score is shocking, but it is also true that the reason is not creating the domain event or the handler. That alone is 20 points.
2.3 - Analysis of Opus 4.8 for development
Personally, this is the model I use at work, and I expect a result similar to what GLM 5.2 gave us, which made me wonder whether I would have to change the test.
A - What is Opus 4.8 like for doing code reviews?
When it comes to finding issues, Opus 4.8 delivered, since it found practically all the problems, including some that the Sonnet models missed, such as the fact that the method always returns true and therefore the endpoint always responds 200.
The problem? The traps. Opus found the try/catch issue but did not mention that the associated test validates incorrect behavior, and that is a direct -20 points. And you can say, "oh man, that is harsh," but it is what it is: we have to be serious, and a 20-point deduction is a 20-point deduction. It is the same penalty Composer 2.5 got back in the day for the same thing.
Result: 60/100.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Opus-4.8/task1_code_review_evaluation.md
B - What is Opus 4.8 like for programming complete features?
It took 7 minutes to implement the feature. It placed the tests in the correct project (unlike Sonnet 5) and they pass, the endpoint with its response types is very good, it uses the Result pattern with error binding, which I think is wonderful...
But then CanBeCancelled checks whether the status is created or paid instead of checking the statuses in which it CANNOT be canceled, it does not generate the domain event (so goodbye idempotency, goodbye handler), and as for infrastructure, integration event and outbox pattern, nothing at all.
Result: 50/100. Total disappointment, and I was not expecting it.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Opus-4.8/task2_feature_implementation.md
Total Opus 4.8: 110 points. Unfortunately, the result was not as good as I expected, although it is also true that this is largely because of the penalty for not finding the code review trap. Which, well, I only penalize if they find the bug itself, and that hurt Opus 4.8 while it did not hurt the Sonnets, which also did not flag the trap. Something to keep in mind.
2.4 - Analysis of Fable 5 for development
Finally we get to Fable, the new model, and now we are going to see whether there really is an important change and whether it is worth paying twice as much per token compared with Opus 4.8.
Without having tested anything yet, the model's own definition suggests that the review should be at a similar level, that is, almost perfect, while where it should improve is in the feature implementation, which is the abstract task with an objective. My bet before running anything: between 180 and 200 total points.
A - What is Fable 5 like for doing code reviews?
It found practically everything: the integer division, the cache key, the static dictionary with its memory issue (grows unbounded), publishing the event before confirming the write, the silent try/catch together with the "always returns 200", input validation, the test that validates nothing, double vs decimal, the cancellation token... And most importantly: it identified the trap of the test that validates incorrect behavior, which is exactly why we took 20 massive points away from Opus and why we are not going to take them away from Fable.
The only thing it did not flag is that the handler should validate that the ID exists, which we could debate whether it is really necessary (in my opinion yes, but it is debatable).
Result: 92/100. It is by far the highest score in a code review; the previous record was GLM 5.2 with an 80. Same prompt, exactly everything the same.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Fable-5/task1_code_review_evaluation.md
B - What is Fable 5 like for programming complete features?
It wrote tests (a lot of them, in fact), they compile and pass. The HTTP PUT cancellation endpoint with its different response types is correct. Result pattern, correct (it simplified things and does not use binding like others, but it is fine). A canceled order cannot be canceled again, correct. It follows DDD with the Apply, generates the domain event, respects idempotency, ensures that a shipped or completed order cannot be canceled, and has its domain handler with a TODO to release the reserved stock.
Any issues? The event publish does not include the cancellation token, so that point is half awarded. And from the bonus points, none: no fake API to return the stock, no infrastructure, no mention of the outbox pattern. Maybe the prompt is too vague for that, but hey, we are supposedly paying a fortune for these models precisely for that.
Result: 90/100.
Link to the result: https://github.com/ElectNewt/llm-coding-evals/blob/main/2026.06/Evaluations/Fable-5/task2_feature_implementation.md
Total Fable 5: 182 points. Honestly, I have no words.
3 - Conclusion
We are done, and the results are expected on one hand and unexpected on the other: we have Sonnet 4.6, which I was going to use as a baseline and which ended up being the big surprise. I do not really know why it happened, but the reality is that it got a great score (134), even ahead of Sonnet 5 (132) and Opus 4.8 (110), although the trap penalty did considerable damage to Opus.
As for the matter this post is about, which is Fable 5: 182 points out of 200 (240 if we count the 40 bonus points, none of which it got).
It takes first place in the ranking by a huge margin, with a 92 in code review, which is an absolute record, and a 90 in implementation, where it did practically everything right on the first try, without hand-holding. The difference between GPT-5, Opus or Sonnet and Fable 5 is brutal.
Is it worth it? It depends. Right now, on a personal account, usage is kind of subsidized and you can get by; but when you pay through the API, at twice the price per token compared with Opus, and with the number of tokens it consumes, the bill gets out of control.
For day-to-day work I will continue using Opus 4.8 at work (although starting Monday I am going to begin giving Sonnet 5 a chance), and I would reserve Fable 5 for those global epic-style objectives where its autonomy really makes a difference, or for making the plan.
And this is how they look inside the global ranking in our testing tool:
If you look closely, this confirms what I feared when GLM 5.2 got such good results: I am going to have to create a new test, because with Fable 5 brushing up against a perfect score, the 2026.06 test has become too small.
