Claude Fable 5 vs Kimi K3 vs GPT-5.6 Sol: Which is best for AI agents

The Big AI Triumvirate

A year ago, when Gemini 2.5 Pro came out, I coined the term AI triumvirate to address the then-big 3 of the AI race. Claude, GPT, and Gemini. This was the first triumvirate ruling the AI space. I personally consider Anthropic as Caesar, OpenAI as Pompey, and Gemini as Crassus. Now, Crassus is dead, and we’re left with raging Pompey and Caesar, each at each other’s throats. The lore kind of fits here tangentially.

Source: ChatGPT Image gen

But in 2026, especially after the launch of Kimi K3, we may be looking at a second AI triumvirate: Claude, GPT, and Kimi. If we follow the Roman casting, Claude Fable is Octavian, GPT 5.6 Sol is Mark Antony, and Kimi K3 is Lepidus.

This is the best ChatGPT could do for Yang Zhilin

If history is any guide, Claude’s future might be glorious.

The Triarchy at a glance

Claude Fable 5 is Anthropic’s top generally available Claude model, pitched for ambitious, long-running work such as agent runs, large coding projects, enterprise workflows, and vision-heavy document work. It includes the full 1M-token context window at standard pricing.

Kimi K3 is Moonshot AI’s 2.8T-parameter flagship, built with native vision, a 1M-token context window, and Moonshot’s positioning as an open model in the 3T-class (they haven’t yet made it open though). Moonshot is explicit about the target: long-horizon coding plus knowledge-work and reasoning tasks.

OpenAI’s gpt-5.6 alias points to GPT-5.6 Sol, the flagship member of the GPT-5.6 family for complex reasoning and coding. It has a 1.05M-token context window and supports up to 128K output tokens.

Pricing Comparison

The only thing that matters now in LLMs is their pricing. Nobody wants to live under Dario’s API cost terrorism. So, here’s how the pricing of the trio compares.

Pricing sources: Fable, Kimi, GPT 5.6

Prices are official list rates per 1 million tokens. GPT 5.6 Sol figures shown are standard short-context rates; OpenAI lists higher long-context rates of $10 input, $1 cached input, and $45 output per million tokens.

Effort controls

Effort levels are probably the most confusing thing right now: which effort preset to even choose. There are half a dozen to choose from for each model.

It’s always better to start with the default setup. Then go up and down based on your usage requirements.

How they fare on popular benchmarks

If any benchmarks still deserve attention, they are these five.

On DeepSWE, GPT 5.6 Sol leads at 73% pass@1, followed by Fable 5 at 70% and Kimi K3 at 69%. The cost gap is less subtle: DeepSWE reports an average of $8.39 per task for GPT 5.6 Sol, $21.63 for Fable 5, and $4.65 for Kimi K3.

CritPt tests models on unpublished, research-level physics problems. GPT 5.6 Sol leads at 32.3%, ahead of Fable 5 at 28.6% and Kimi K3 at 23.4%. This is consistent with what people have been reporting: Kimi still has some way to go in math and physics to match Fable and GPT 5.6 Sol.

On the broader Artificial Analysis Intelligence, Fable 5 remains first at 60, GPT 5.6 Sol is one point behind at 59, and Kimi K3 scores 57. Artificial Analysis estimates about $1.04 per task for GPT 5.6 Sol, $3.25 for Fable 5 and $0.94 for Kimi K3, while describing Sol as delivering near-Fable intelligence at roughly one-third of Fable’s cost.

On WeirdML, Fable 5 reaches 91.9% at max effort, while GPT 5.6 Sol scores 88.8% at high effort. Kimi K3 does not yet have a published WeirdML result, so this row is not a complete three-way comparison. The effort settings also differ, which matters when interpreting the narrow gap.

KernelBench Hard tests whether an agent can write correct and fast CUDA or Triton kernels for six demanding GPU workloads. Fable 5, Kimi K3 at 256k context, and GPT 5.6 Sol all produced correct solutions on 6/6 H100 tasks. The July 17 snapshot places Fable first at 23.9% mean peak fraction of roofline, with Kimi at 20.9%. The published summary confirms GPT’s six correct kernels but does not expose a directly comparable aggregate roofline score, so I have not invented one.

The trend is almost the same across benchmarks. Fable leads in raw intelligence, Kimi K3 offers similar performance with 1/4th of the Fable cost, and GPT 5.6 Sol is the middle child. The safest option, if you have decision paralysis.

Composio Golden Eval benchmark

It’s the benchmark time. One of the highest usages of LLMs currently comes from automation workflows, where agents have to interact with external tools to carry out complex automation.

Composio Golden Eval is created to assess exactly that. How can you benchmark which model + harness combo is the most reliable for multi-app cross-workflow tasks?

This is how it works.

• An agent has to complete hard, multi-step SaaS tasks against live accounts, then the grader reads the account state back through the API to see what actually happened.

• The runtime is straightforward: Claude Code drives Fable 5 and Kimi K3, while the OpenAI Codex CLI drives GPT 5.6. All three talk to tools through the hosted Composio MCP router.

• After each run, the verifier queries the account through the API and checks the resulting state against expected assertions.

• The grader reads account state instead of a transcript-level vibe check. Writes are uniquely tagged and cleaned up afterwards, so the benchmark can run against live Gmail, Slack, Sheets, Calendar, Drive, Salesforce, HubSpot, GitHub, and Linear accounts without leaving junk behind.

The 12 cases are split into two bands:

• Five “frontier kill” cases, built specifically to break frontier models.

• Seven “historical” cases, which strong models usually pass.

If a model clears the historical band, fine; that is the expected floor.

The frontier-kill band is about whether the agent can keep a messy cross-app workflow straight until every checked record lands in the right final state.

What the frontier-kill tasks look like

The frontier-kill cases are mostly CRMs, Gmail, Slack, and Sheets sync-and-reconcile workflows. The agent has to pull the right records across systems and turn them into the exact final state. Partial credit is tracked per graded check, but a task only passes if the whole state is right.

The hardest one is the ticket sync case: a multi-app support-ticket workflow across Gmail, Slack, and Sheets where the agent has to reconcile ticket state across systems and land the exact final set. This one has 24 graded checks, which leaves a lot of surface area for a tiny mistake to break the final answer.

The invoice sync case is similar in shape, but with invoices. The agent has to reconcile invoices across systems into the exact ledger state; the grader has 13 checks. The refund ledger case is another 13-check workflow, where the agent has to build a refund ledger from cross-app records exactly.

There are also 13-check tasks for roster sync and vendor directory reconciliation. The failure mode is the same: one wrong merge or one record touched by mistake can break the final account state.

The historical band is easier, but still requires working across tools. One CRM identity-dedup case asks the agent to find contact emails that exist in both Salesforce and HubSpot among tagged contacts, follow canonical-source notes buried in Gmail, and return a review without mutating records. Those cases still require real cross-app reading and careful writes. The frontier-kill band gives the model less room to recover from one bad merge or accidental write.

Results

All three ran the same 12 case templates through the same Composio MCP tool router, with real-account API readback verifiers grading pass/fail.

• Fable 5 and Kimi K3 were paired with Claude Code.

• GPT 5.6 ran as gpt-5.6-sol under the OpenAI Codex CLI.

Because GPT 5.6 ran separately, I read this as a task-for-task comparison on the same templates; account state varied between runs.

Check scores (e.g. 20/24) are partial-credit verifier checks on the failed Kimi K3 and GPT 5.6 cases: how many of the graded assertions the model got right before missing the requirement that every checked record match.

The scoreboard is close:

• Fable 5 finished 7/12,

• Kimi K3 finished 7/12, and

• GPT 5.6 Sol finished 6/12.

The frontier-kill band produced the same pass/fail result for everyone: all three models failed all 5 cases. On the historical cases, they mostly tied, with GPT 5.6 losing one extra case on CRM identity dedup.

Findings

The frontier-kill set was overkill for all the models. Each one failed all 5 workflow cases, the cross-app Gmail, Slack, and Sheets sync-and-reconcile tasks where the grade depends on multiple verifier checks and an exact final state.

A straight pass/fail score doesn’t tell you how close a model got. GPT 5.6 got closer than Kimi K3 on ticket, 20/24 vs 17/24. It also led vendor, 12/13 vs 11/13, and refund, 10/13 vs 8/13. Then it slipped on roster, where Kimi had 8/13, and GPT had 7/13. For failed-case partial credit, the useful comparison is GPT 5.6 against Kimi K3.

Note: 12/13 here means how many checks a model got right. In this case, 12 checks out of 13.

None of the models reached the exact final state on any of the 5 frontier-kill tasks. The failed-case label hides useful distance, though. GPT 5.6 was one or a few checks away on several of them, so its failures look like near-miss reconciliation errors rather than a total derailment.

The one clean split was CRM identity dedup. That was the Salesforce + HubSpot + Gmail task where the agent had to match contacts across two CRMs and follow canonical-source notes hidden in email. Fable 5 passed it. Kimi K3 passed it. GPT 5.6 failed it at 5 of 7 checks. That single miss is why GPT 5.6 ends at 6/12 while Fable 5 and Kimi K3 land at 7/12.

Outside the frontier-kill band and CRM dedup, the three passed the same six cases: calendar free/busy, recurring-event repair, Drive external-share audit, Gmail label batch, GitHub access audit, and GitHub/Linear reconciliation. GPT 5.6 passed those outright rather than landing on partial credit.

With scores clustered at 7/12, 7/12, and 6/12, cost becomes the separator.

What it costs

These cost figures are ceiling estimates. To keep the comparison conservative, I priced every runtime token at each model's list input rate. Cached reads would bill cheaper. GPT 5.6's tokens were measured directly; Fable 5 and Kimi K3 use their recorded runtime-token counts normalized per case. The ratios are more useful than penny-level totals.

Estimates price every runtime token at each model's list input rate. Cached reads would bill cheaper, so treat the dollars as ceilings. Fable 5 and Kimi K3 use recorded runtime-token counts normalized per case; GPT 5.6’s tokens were measured directly. The ratios matter more than the penny-level totals.

Claude Fable 5 averaged about 776k tokens per case. Kimi K3 averaged about 463k. GPT 5.6 landed between them at about 538k. At list input prices, that comes out to roughly $7.76 per case for Fable 5, $2.69 for GPT 5.6, and $1.39 for Kimi K3. Across the 12-case suite, the estimates are about $93, $32, and $17.

List prices widen the spread. Fable 5 is $10 input and $50 output per million tokens. GPT 5.6 is $5 and $30. Kimi K3 is $3 and $15. In this run, Fable 5 combined the highest token price with the heaviest token use, while Kimi K3 had the lowest token price and fewest tokens; GPT 5.6 landed between them on both.

Fable 5 and Kimi K3 both scored 7/12, but Fable cost about 5.6x more per case to get there. GPT 5.6 cost more than Kimi K3 and finished one case behind both. On this suite, higher price did not buy a higher score: the cheapest model tied the most expensive, and the mid-priced one scored lowest.

Verdict

If you ask me, Kimi K3 is my default for ordinary SaaS agents from this run. It matched Fable 5's score for roughly a sixth of the cost, while GPT 5.6 cost more than Kimi and dropped the two-CRM dedup that the other two handled.

If your agents do exact cross-app reconciliation like those frontier-kill cases, I would not ship any of these three alone yet. Put a verifier/retry loop around them and expect confident near-misses. For ordinary SaaS tool use, the quality spread is tight enough that price decides it for me.

Before production authority, I would rerun the same style of account-backed workflows on my own tools with account-state graders and a retry path.

Vibe-checking Code gen with Sim City build

1. Build a SimCity-Style City Builder

The task isn’t as simple as it sounds, trust me. All three models are being asked to build a full browser-based SimCity-style game.

If you’ve played the game, you know it’s pretty dang complex.

Even if we’re not able to rebuild this entire thing, we should get pretty close to it in terms of the look and feel.

There are roads, traffic, money, population, jobs, power, happiness, demand, and a bunch of systems that need to work together.

Fable 5, Kimi K3, and GPT-5.6 Sol are all supposed to be beast coding models, so the test has to be at their level.

We are also giving all three models the exact same 3D assets, including buildings, roads, cars, and trees.

💁 If you’re interested in the assets used, they are from Quaternius Downtown City MegaKit.

We’ll compare visual quality, gameplay feel, feature completion, bugs, performance, code quality, token usage, cost, time, and of course, the overall feel.

Fable 5

Holy! Fable 5 pretty much nailed this one.

I expected it to produce a nice-looking Three.js city, maybe with a few buildings, some roads, and a bunch of statistics pretending to be a simulation. But what it built felt much closer to an actual small city-building game.

It had pretty much everything I asked for:

• a full starter city

• roads and connected intersections

• residential, commercial, and industrial zoning

• buildings that develop after placing zones

• parks, fire stations, and power plants

• population, jobs, happiness, and money

• power usage and capacity

• residential, commercial, and industrial demand

• moving traffic

• pause and speed controls

• day and night modes

• camera controls

• bulldozing

• space to expand the city

You could place roads, add new zones, watch buildings appear (in steps), see cars driving around following lanes, and notice the population, jobs, power, demand, and economy change as the city grew.

The visuals were probably the best part.

It inspected the asset catalogue, loaded the models, handled their scale and rotation, reused them across the city, and arranged everything into residential areas, industrial areas, a downtown section, parks, roads, and a waterfront.

It could have easily ended up looking like an asset-pack demo with random buildings placed everywhere. Instead, it looked like a properly planned miniature city.

The gameplay also felt way more polished than I expected.

Of course, it was not perfect.

The shadows had some issues, and there was also a funny glitch where parts of the land started looking like water when I zoomed in too much.

What I liked was how Fable tried to debug the shadow issue.

Instead of randomly changing lighting values and hoping something worked, it created a tiny temporary React Three Fibre scene just to test the shadows.

It first checked whether the directional light was the problem. Shadows worked in the small test scene, so it figured out that the issue was probably somewhere in the main scene setup or the lighting component.

That was honestly pretty cool to watch.

The amount of code it changed was also kinda insane.

It added 5,702 lines and removed 313 lines, so the full run touched more than 6,000 lines of code.

It also spent a lot of time working on the project. The API time was a little over one hour.

It inspected files, ran commands, built features, opened the app, found issues, and fixed things.

Here is the game in action:

You can find the generated code here: Fable 5: City Builder

• Cost: $73.18

• Duration: 1h 3min 23sec API time, 2h 24min 26sec wall time

• Code Changes: +5,702 lines, -313 lines

• Session Usage: 30% used

• Token Usage:

  • Claude Haiku 4.5: 9.5k input, 36 output

  • Claude Opus 4.8: 28 input, 17.0k output

  • Claude Fable 5: 854 input, 248.9k output

  • Cache read: 45.35M

  • Cache write: 865.4k

• Cost by model:

  • Claude Haiku 4.5: $0.0096

  • Claude Opus 4.8: $1.47

  • Claude Fable 5: $71.69

💁 NOTE: This run cost $73.18, so yeah, this was not cheap at all. Fable 5 alone used $71.69 of that. If you’re on API usage, you would be robbed.

The crazy number here is the 45 million cached tokens read. That gives you an idea of how much context the agent kept going through while working on the project.

Honestly, this whole thing still feels kinda unreal to me.

If you showed me this back in 2020 and said an LLM would build the whole thing in an hour just six years later, I would’ve called it fake.

At this rate, give it a few more years, and it might be building Earth 2 or something. 🫩

GPT-5.6 Sol

Okay, so Sol did… decent. But man, there were just too many issues along the way.

The first attempt technically gave me a build. But when I opened it with npm run dev, my CPU usage shot above 90%, and my laptop straight up crashed. Twice. Before I could even record the demo.

Here’s what that first approach looked like:

ℹ️ Notice, the CPU usage at the top of the screen.

After a bunch of back-and-forth fixing, it finally got me a working build.

But to be fair, this isn’t anywhere close to the Fable 5 output. There are just too many bugs in the game implementation itself. It’s not polished, the cars are literally jumping back and forth, and there’s no proper simulation running underneath.

That was a little disappointing, especially since I expected more from the new GPT-5.6 Sol lineup.

One thing I’ll give it credit for: it was fast. Sol shipped its first build in a fraction of the time Fable took. But speed doesn’t mean much when the implementation doesn’t come close.

• Duration: ~22 minutes

• Code Changes: ~2,400+ lines, 166 deletions, 12 files changed

• Context Used: 37% (104k/258k)

Here’s the final demo after all the fixes:

As you can clearly see, this isn’t close.

💁 NOTE: This test mainly focuses on visual quality. So even if the underlying implementation is strong, a result that does not look visually right cannot be considered the best overall.

Kimi K3

Okay, this one seriously surprised me.

Kimi K3 delivered the best result I’ve seen from an open model in any of these coding tests so far. For $15.02, the implementation is kinda ridiculous.

The shadows, cars, traffic, and overall look and feel are much better than GPT-5.6 Sol. More importantly, the whole thing feels rock solid, prettier, and actually functional.

Here’s a quick video demo (see the shadow effect):

Considering the price, this might be even more impressive than Fable 5. It was a lot slower, taking around 1.5 hours, but the final result absolutely justified it.

You can find the generated code here: Kimi K3: City Builder

• Cost: $15.02

• Duration: ~1.5 hours

• Context Used: 26%

• Token Usage: 275,607 tokens

💁 NOTE: This run used Kimi K3 through OpenCode with OpenRouter, so the exact timing and behavior may have been affected by the OpenRouter workflow.

2. Add Disasters and Composio

For the second part, the models have to extend the city with more interaction and logic.

Things like power failures, blocked roads, damaged buildings, fires, and changes to the city’s economy should all connect back to the systems built in the first task.

Whenever a major event happens inside the city, the game has to create an incident in Slack, post live updates as the situation changes, and log the final results in Google Sheets.

So we’re not just testing visuals here. We’re also testing whether the models can connect the game state to real external tools and make the whole flow feel natural.

Claude Fable 5

This is peak coding. I genuinely don’t know how Fable 5 keeps pulling this stuff off.

I’ve been testing coding models since 2024, and this is easily the finest result I’ve seen so far. At this point, no other model I’ve tested comes close.

Just look at the output:

The rain alone looks drop-dead realistic.

And the craziest part is that I did not provide it with any rain assets. There were no premade raindrop models, weather effects, or fancy shaders waiting inside the project.

Fable created the entire effect with Three.js.

The level of detail is honestly ridiculous.

But what impressed me even more was the Composio integration.

Fable searched the internet, read through the current Composio documentation, understood the SDK, figured out which actions to use, kept the API key on the server, and connected everything to the actual game state.

When an incident started, it created a real Slack message. As the disaster progressed, it posted live updates inside the same thread. When the incident ended, it updated the original message and posted a final summary.

It also logged the final incident result in Google Sheets, including the incident ID, disaster type, duration, affected buildings, blocked roads, economic loss, and final status.

All the pieces of functionality work. It just does.

Here’s the final demo:

You can find the generated code here: Fable 5: Disasters and Composio

• Cost: $45.28

• Duration: 47 minutes API time, 56 minutes 26 seconds wall time

• Code Changes: +4,195 lines, -236 lines

• Session Usage: 50%

• Token Usage:

  • Claude Haiku 4.5: 14.2k input, 36 output

  • Claude Opus 4.8: 62 input, 32.3k output

  • Claude Fable 5: 726 input, 193.6k output

  • Cache Read: 26.2M

  • Cache Write: 643.4k

• Cost by model:

  • Claude Haiku 4.5: $0.0143

  • Claude Opus 4.8: $2.80

  • Claude Fable 5: $42.47

💁 NOTE: Fable added another 4,195 lines of code and completed the whole run in under an hour of API time.

It understood an unfamiliar integration, connected it to an already complex game, built the disaster effects procedurally, and somehow still made everything look so good.

GPT-5.6 Sol

GPT-5.6 Sol struggled with this one.

The rain and fire effects technically worked, but neither looked particularly convincing in the actual game. That could come down to personal preference, but compared with the Fable 5 result, the visual difference was pretty clear.

The bigger problem was the Composio integration.

Sol managed to write much of the integration logic correctly. It understood the general Composio flow, created the server-side pieces, and implemented the Slack and Google Sheets actions.

But it could not properly connect those pieces to the live game state.

So while the individual pieces were there, Sol was not able to put everything together into a working end-to-end experience.

Here’s the demo:

You can find the generated code here: GPT-5.6 Sol: Disaster and Composio

• Context Used: 197k of 258k

• Context Remaining: 25%

• Weekly Usage Remaining: 81%

Kimi K3

Kimi K3 handled the disaster and Composio implementation better than GPT-5.6 Sol.

It connected the game state to Composio, kept the incident updates tied to the simulation, and somehow the whole thing actually works.

The only obvious gap was the rain. There is a bit of a thunder effect, but no proper visible rainfall. That is still a miss, but visuals are not the main thing in this part. The disaster logic and the Composio flow work, which matters more here.

At this price, it somehow feels even more impressive than Fable 5. Kimi K3 has now overshadowed GPT-5.6 Sol in both coding tests, which is honestly a little scary for an open model.

Here’s a quick demo:

You can find the generated code here: Kimi K3: Disasters and Composio

• Cost: $10.90 for this task, $25.92 cumulative

• Duration: ~1 hour

• Token Usage: 117,845 tokens for this task, 393,452 cumulative

Conclusion

So far, the two benchmarks are telling very different stories.

On the coding side, Fable 5 delivered the strongest raw visuals, but Kimi K3 was the biggest surprise. It produced a far more polished and functional result than GPT-5.6 Sol, handled the disaster logic and Composio integration well, and did it at a fraction of Fable’s cost.

GPT-5.6 Sol was faster, but the difference in implementation quality was clear. It produced its first build in a fraction of the time, yet the performance problems, bugs, and weaker simulation made the result feel unfinished. In the second task, it understood much of the Composio flow and wrote the individual pieces, but failed to connect them properly to the live game state.

For ordinary SaaS agents, Kimi K3 is also my default pick. It matched Fable 5’s 7/12 score at roughly one-sixth of the estimated cost. GPT-5.6 Sol finished at 6/12, despite costing more than Kimi K3.

The biggest warning is still the frontier-kill set. All three models failed all five cases. These exact-state, cross-app workflows remain difficult enough that I would not deploy any of them without verification, retries, and strict account-state checks.

If you want the most polished coding output and cost is secondary, Fable 5 is the strongest option. If you want the best balance of capability and price across both coding and tool use, Kimi K3 is the clear winner.