Fable 5 vs GPT-5.6 vs Kimi K3: One Prompt, One App

$82.30. That's what one of these agents charged to build a calorie-tracking app from a single prompt. The cheapest of the three did the same job for $17.20 — a 4.8x spread on identical work, delivered on the same afternoon.

Here's the short answer for anyone weighing Fable 5 vs GPT-5.6 vs Kimi K3 on real app-building work rather than leaderboards: all three shipped a functioning calorie tracker from one prompt with zero revisions. Fable 5 won the combined score 17 to 8 to 8, almost entirely on design and usability polish. GPT-5.6 Sol finished fastest at 48 minutes and cost $23.93, but produced the thinnest app of the three. Kimi K3 was slowest at 1 hour 54 minutes, cost the least, and — despite the ugliest interface in the group — was the only one that shipped a paywall Apple wouldn't reject.

That last sentence is the one worth sitting with, and I'll get to why.

Whose Receipts These Are

I didn't run this build. Let me put that up front, because the internet is drowning in first-person benchmark theater and I'd rather be the guy who takes results apart than the guy who pretends he ran them.

The experiment came out of a live head-to-head: three flagship coding agents, one identical prompt, a complete calorie-tracking mobile app, no follow-up corrections allowed. The apps were scored on four axes — development speed, functionality, UI design, and native mobile feature fidelity — with real invoice totals attached to each run.

What I did do is verify every external claim in it against published sources, because a single run per model is an anecdote until something independent corroborates the mechanism. Two things corroborate this one unusually well, and I'll show both.

First, some naming cleanup, since the source transcript garbled two of the three:

• GPT-5.6 Sol, not "Soul." OpenAI's flagship tier in the GPT-5.6 family, announced June 26, 2026, sitting above Terra and Luna.
• Kimi K3, not "Kimik A3." Moonshot AI's 2.8-trillion-parameter mixture-of-experts model, announced July 16, 2026 with open weights following on July 27 under a modified MIT license. It activates roughly 104 billion parameters per token and carries a 1M-token context window.
• Claude Fable 5 is the only one the transcript got right.

Now the results table, exactly as recorded.

Three apps. Four hours and eight minutes of total wall-clock. $123.43 all in.

Read the totals column and the story looks settled: Fable 5 doubled the field. Read the individual axes and the story falls apart — which is exactly the part nobody covering these models is writing about.

Fable 5 vs GPT-5.6 vs Kimi K3: The Benchmark Paradox

Before this build, if you'd asked the published leaderboards which of these three writes the best frontend code, the answer would have been Kimi K3. Not close, either.

Kimi K3 debuted at number one on Arena.ai's Frontend Code Arena with 1,679 points, ahead of Claude Fable 5 at 1,631 and GPT-5.6 Sol at 1,618. It also tops Program Bench outright at 77.8, edging GPT-5.6 Sol's 77.6 and Fable 5's 76.8. On Terminal Bench 2.1 it scores 88.3 against Sol's 88.8, beating both Fable 5 and Opus 4.8, which tie at 84.6. On the broad Artificial Analysis Intelligence Index the three cluster at 60, 59, and 57 — a three-point spread across the entire frontier.

Then Kimi K3 built this app and scored 2 out of a possible 9-plus on design.

Inconsistent border radii. Cluttered screens. The kind of interface that makes a user close the app before logging their first meal. The model that was, by measurement, the best frontend coder in the world produced the worst-looking product in the room.

That contradiction isn't a scoring error. It's the most useful finding in the entire run, and it comes down to what those benchmarks actually measure.

Frontend Code Arena scores isolated, human-judged generations — a component, a page, a self-contained snippet, evaluated on its own merits with the task fully specified. Program Bench and Terminal Bench score correctness against tests and terminal outcomes. Every one of those tasks hands the model a bounded problem with a checkable answer.

A calorie tracker built from one prompt is a different task class entirely. The agent has to invent a design system nobody specified, then hold it consistent across an onboarding flow, a logging screen, a camera capture path, a history view, a settings pane, and a paywall — all while wiring three third-party SDKs and not contradicting itself thirty files later. Nothing tests that. There's no benchmark for coherence maintained across an unspecified surface over ninety minutes of autonomous work.

Fable 5 is unusually good at that specific thing. It always has been — I made the same observation when I looked at how Fable 5 and Opus 5 split across nine real knowledge-work tasks, where Fable lost decisively on bug-finding and won just as decisively on anything with a design surface. Same pattern, different task battery, and now confirmed on mobile.

So the working rule that comes out of this: frontend benchmarks predict snippet quality, not product coherence. Treat them as measuring different skills, because they do.

Which raises the obvious follow-up — how much of Fable's blowout win is actually design?

Strip Out Design and the Ranking Inverts

Look at the rubric's shape before you trust its totals. Across three models and four axes, exactly one score exceeds 4, and it's Fable's 9 on design. Every other cell in the table sits between 1 and 4. Design is running on a visibly wider scale than the other axes, which means it carries disproportionate weight in the total column.

So I recalculated the totals on the two axes a developer actually can't fix in an afternoon — functionality and native feature fidelity. You can restyle an app. You cannot easily retrofit a data model or a HealthKit sync path.

The ranking changes completely.

Kimi K3 goes from tied-for-last to a clear second, at roughly a quarter of Fable's cost per point of engineering delivered. GPT-5.6 Sol — the fastest finisher, the stable run, the one that never fell over — drops to last by a wide margin, and it wasn't even the cheapest.

Fable still wins. It should; 8 beats 6. But "wins by a hair on engineering and by a mile on aesthetics" is a fundamentally different purchasing decision than "wins 17 to 8." The first one tells you to hire Fable for the polish pass. The second one tells you to hire it for everything, and that would be the wrong read.

This is the part where blended scores mislead people. Any composite that folds a subjective axis and an objective axis into one number will quietly hand the subjective axis the steering wheel. Look at the columns, not the sum.

Cost is where this gets sharper still.

What Actually Drove the $82 Bill

Published API rates, all verified as of early August 2026:

Fable 5 costs 3.33x Kimi K3 per token on both input and output. But the invoice ratio was 4.79x — $82.30 against $17.20.

Rates alone don't explain that. Run the division: 4.79 ÷ 3.33 ≈ 1.44. Fable burned roughly 40-45% more token volume than Kimi did on the same brief. It isn't only more expensive per token; it does more thinking per unit of output.

The Fable-versus-Sol comparison lands the same way. Sol is half Fable's input price and 60% of its output price, so a purely rate-driven gap would land somewhere near 1.7-2x. The actual gap was 3.44x. More tokens again.

Now the corroboration I mentioned earlier, and it's a good one. Artificial Analysis publishes average cost per task on DeepSWE: $21.63 for Fable 5, $8.39 for GPT-5.6 Sol, $4.65 for Kimi K3. Fable-to-Kimi on that independent, completely unrelated agentic coding benchmark works out to 4.65x. This app build produced 4.79x.

Two evaluations, different task types, different evaluators, same cost multiple to within 3%. That's not coincidence — it's a stable property of how these models spend tokens, and it means you can budget against it. If Kimi K3 costs you X on an agentic build, plan for roughly 4.5-5x that number if you hand the same work to Fable 5.

The per-minute picture is its own kind of interesting. Fable ran at about $0.96 per minute of wall-clock, Sol at $0.50, Kimi at $0.15. If you're the sort of person who leaves an agent running while you make coffee, that's a meaningful difference in what an unattended hour costs you. I wrote a whole piece on cutting Fable 5 usage costs without downgrading the model, and every technique in it applies double to long autonomous builds like this one.

Why the Cheapest Model Took the Longest

Kimi K3 was the slowest run at 1 hour 54 minutes — 33% longer than Fable, 138% longer than Sol — and it was slow for an unglamorous reason. It hit errors and rebuilt. Multiple times.

That deserves more attention than it usually gets, because rebuild loops are where the token-price argument quietly dies for a lot of teams.

Kimi still came out cheapest here, so the loops didn't erase its cost advantage on this run. But they consumed 28 extra minutes against Fable and 66 against Sol. If you're an agency billing that time, or a solo builder with three hours between client calls, the model that saved you $65 just took the longest slot on your calendar. Cheap tokens and cheap hours are not the same currency, and only one of them shows up on the invoice.

The flip side is that Sol's 48-minute run was stable and clean, and it produced the least complete app in the group. Speed with nothing to show for it is its own kind of expensive. There's a version of this trade-off where the fast, cheap, stable run is the right answer — prototyping, throwaway demos, proving a concept before you commit real budget — and a version where it wastes the whole afternoon because you have to build it again properly.

Three models, three distinct failure modes: Fable burns money, Kimi burns clock, Sol burns scope. Pick your poison based on which one you can actually absorb this week.

The Integrations Are Why Any of This Worked

Strip away the model comparison for a second, because the setup deserves credit that usually goes to the agents.

The prompt specified three third-party services:

• Clerk for authentication
• RevenueCat for subscription management and paywalls
• Gemini API for image-based calorie analysis

None of the agents built auth. None of them built a payments layer. None of them trained a vision model to look at a plate of food and estimate macros. They wired SDKs.

That's the actual unlock behind single-prompt apps, and it's an architectural point, not a model point. Ask any of these three agents to hand-roll session management, receipt validation across two app stores, and a food-recognition pipeline, and you'll get ninety minutes of confident, unshippable code. Hand them a brief where the hard, security-sensitive, regulation-adjacent parts are already solved by services with well-documented SDKs, and they perform like competent mid-level engineers.

The lesson generalizes well beyond calorie trackers. The single biggest lever on single-prompt build quality isn't which model you pick — it's how much of the problem you've already removed from the model's plate before it starts. I ran into exactly this constraint when I built a niche mobile app with Claude Code and React Native over a weekend: every hour I saved came from a service I didn't ask the agent to reinvent.

If you'd rather hand the integration architecture to someone who's already mapped which services are safe to delegate to an agent and which absolutely are not, that's a large part of what I do on custom builds — fiverr.com/s/EgxYmWD.

Now the axis that separates a real app from a website in a costume.

What Do Native Features Actually Prove in an AI-Built App?

Native feature fidelity is the axis that tells you whether you got a mobile app or a web page wearing one. On this build it covered Apple Health sync, push notifications, native bottom tab navigation, live activities, and widgets.

Scores: Fable 5 and Kimi K3 tied at 4. GPT-5.6 Sol managed 2.

Meal logging, Apple Health integration, and notifications were handled well across all three — the baseline is genuinely solid now, and that's the headline finding people should take from this run. Where the gap opened was in the platform-specific chrome: real bottom tabs versus a styled div, live activities that actually surface on the lock screen, widgets that respect the system layout.

Kimi K3 implemented native bottom tabs and paywall elements properly, which is why it tied Fable on this axis while scoring a 2 on aesthetics. It built the right structures and dressed them badly. That is, mechanically, the easier problem to fix — a designer can restyle a correct navigation stack in a day, but retrofitting native navigation into an app that fakes it with a scroll view means gutting the shell.

Sol's 2 is the number that would worry me most in production. Weak native fidelity plus a 1 on functionality means you're not polishing an app, you're rewriting one.

Which brings me to the single most practically important detail in the entire experiment, and it belongs to the model that scored last on design.

The Paywall Detail That Decides Whether You Ship

Kimi K3's paywall included prominent links to the privacy policy and terms of use.

That sounds like a footnote. It is the difference between shipping and not shipping.

Apple's App Store Review Guideline 3.1.2 requires that apps with auto-renewable subscriptions provide functional links to both the privacy policy and the terms of use (EULA). The in-app subscription screen must show the subscription title, its length, and its price, along with the full auto-renewable subscription terms. And reviewers evaluate what a user can reach from inside the running app — if a reviewer can't tap a visible link and open the document immediately, the requirement isn't met. Missing links under 3.1.2 are one of the most common causes of subscription-app rejection, and each round trip with App Review costs days.

The ugliest app in the test was the one closest to actually passing review.

I keep coming back to that, because it inverts how most people evaluate these outputs. We judge AI-built apps on the screenshot. App Review judges them on compliance plumbing that never appears in a screenshot. A gorgeous 9-out-of-9 interface with a paywall missing its EULA link is further from the App Store than a cluttered one that got the legal furniture right.

So when you're auditing an AI-generated app before you ship it, the checklist that matters looks nothing like the one you'd use for a design review:

1. Does the paywall link to a live privacy policy and terms of use, tappable from inside the app?
2. Does it display subscription title, billing period, and price without ambiguity?
3. Is the full auto-renewable subscription terms text present?
4. Do the links open documents that actually exist at those URLs?
5. Is there a working restore-purchases path?

None of that is on the four-axis rubric. All of it gates your release.

Fable 5 vs GPT-5.6 vs Kimi K3: What to Use Each For

Here's the allocation I'd run, given what this build shows and what the published benchmarks show alongside it.

Use Fable 5 when the design surface is the product. Consumer apps, onboarding flows, anything where a user decides in eight seconds whether to keep the app. Its 9 on design, its onboarding integration, the keyboard handling, the editable calorie inputs, the chart animations — those bonus points are conversion mechanics, not decoration. A better onboarding flow on a subscription app pays for an $82 build in a handful of trial conversions. Just go in knowing you're paying roughly 4.5-5x Kimi's rate for it.

Use Kimi K3 when structure matters more than skin. Internal tools, admin surfaces, MVPs headed for a design pass anyway, and any project where a human designer is doing the visual layer regardless. It gets the architecture right, ships the compliance furniture, costs a quarter per engineering point, and the weights are open under a modified MIT license if you need to self-host. Budget for the rebuild loops on your calendar, not just your card. My fuller take on where it holds up and where it doesn't is in the Kimi K3 review.

Use GPT-5.6 Sol for speed-to-something. Forty-eight minutes and a stable run is genuinely useful when you need a working artifact in front of a stakeholder before lunch. Do not mistake the artifact for a foundation — a 1 on functionality means you're demoing an idea, not starting a codebase.

Or split the job. The most interesting option this data suggests isn't picking one. Let Kimi K3 or Sol produce the structural build cheaply, then hand the result to Fable 5 for a design and usability pass on the surface layer only. You'd pay Fable's rate on a fraction of the tokens. I haven't seen anyone publish clean numbers on that hybrid, and it's the experiment I'd most like to see run next. The same split logic showed up when I looked at how these models diverge on creative work — the winner changes with the task, so stop looking for one.

What This Run Doesn't Prove

Sample size one. Per model. On one app category.

I'd be doing you a disservice to present that as a benchmark, so let me name the specific limits.

A single run can't separate model capability from prompt luck. Rerun the same brief three times per model and you'd almost certainly see the scores move — possibly a lot, given how much of the design axis is subjective judgment. Kimi's rebuild loops in particular might be a property of the model, or might be one bad seed on one afternoon. One run can't tell you which.

The rubric weights design heavily and never publishes its per-axis ceilings, which is why I recalculated on the engineering axes rather than trusting the totals. And a calorie tracker with three well-documented SDK integrations is close to a best case for single-prompt generation — well-trodden category, abundant training data, hard parts outsourced to services. Try this with a real-time collaborative editor or anything with genuinely novel state management and I'd expect all three scores to collapse.

What the run does establish, and what independent data supports, is directional and useful: all three frontier agents now clear the "does it work at all" bar on mobile, the differentiation has moved from functionality to coherence and polish, and the cost spread between them is both large and predictable enough to plan around.

That's a different world from twelve months ago, when the question was whether any of this compiled.

The Number That Stays With Me

Not the $82.30. Not the 17-to-8 scoreline.

It's $123.43 — the total for all three apps — against four hours and eight minutes of wall-clock. Three working, integrated, subscription-ready mobile applications, with authentication, payments, vision-based food analysis, and Apple Health sync, from three prompts, in half a working day, for less than the hourly rate of the developer who used to be required to build one of them.

None of them are ready to publish today. Every one of them needs a compliance audit, a design pass, and a human who understands what App Review will do to a paywall with a broken link. The polish gap is real, and it's exactly where the remaining work is.

But the gap between "AI generated something app-shaped" and "AI generated something you could finish in an afternoon" closed while most people were still arguing about benchmark tables.

Pick the model that matches the axis you can't fix yourself. Then go find out how much of the remaining afternoon is actually yours.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io