One prompt, three AI models, one calorie tracker: what a quick build-off taught me

I did a small thing this week that turned out to be more interesting than I expected. I took one prompt, handed it to three different AI models, and asked each of them to build the same app: a calorie tracker. The three were Fable 5, GPT 5.6 Sol, and Kimi K3.

I want to be upfront that this wasn't a rigorous benchmark. No controlled scoring, no repeated runs, no statistics. It was a vibe check, the kind of thing you actually do when you're deciding which model to lean on for real work. But even a loose test like this surfaced something I keep thinking about, so I wrote it down.

Why a calorie tracker

I picked a calorie tracker on purpose. It's small enough to build in one shot, but it isn't trivial. To do it well a model has to handle a few things at once:

• A form to log meals, with sensible input handling.
• Running totals and some basic state management.
• A bit of data visualization, a daily progress ring or a simple chart.
• Persistence, so your entries survive a refresh.
• A layout that doesn't look like a wireframe from 2011.

That mix is a nice stress test. It touches UI taste, state logic, and just enough data work to separate a thoughtful result from a lazy one.

The prompt

I kept it deliberately open, the way a real person would ask, rather than over-specifying:

Build a clean, modern calorie tracker web app. Let me log meals with
calories, show my daily total against a goal, visualize progress, and
remember my entries. Make it look good.

"Make it look good" was intentional. I wanted to see what each model reached for when I didn't hand it a design.

Round 1: UI and design

GPT 5.6 Sol came first, then Fable 5, then Kimi K3.

GPT 5.6 Sol clearly had the best taste out of the box. Spacing that felt considered, a progress ring that actually looked like a product feature instead of a demo, restrained color, good empty states. It was the only one I looked at and thought "I could almost ship this."

Fable 5 was close behind and honestly not far off. Its layout was clean and the hierarchy made sense. It just played things a little safer, a little more generic, where GPT 5.6 Sol committed to a look.

Kimi K3 got me a working, correct UI, but it was the most utilitarian of the three. Everything was there and nothing was broken, it just needed the most design love before I'd put it in front of anyone.

Round 2: speed

Same order: GPT 5.6 Sol, then Fable 5, then Kimi K3.

GPT 5.6 Sol was noticeably quick to a complete, runnable result. Fable 5 was comfortably in the same tier, quick enough that the difference only mattered if you were watching closely. Kimi K3 was the slowest of the three to finish the full build.

I'll add the caveat that raw speed is the least important axis for me most of the time. A few seconds either way rarely changes my day. It matters more when you're iterating in a tight loop or generating a lot of variations, and there it starts to add up.

Round 3: cost

Kimi K3 wins, hands down.

This is where the ranking flipped completely, and it's the part that stuck with me. On cost, Kimi K3 wasn't just cheaper, it was cheaper by a margin that changes how you'd use it. The kind of gap where a workflow that's expensive with one model becomes basically free with another.

And here's the thing: its output was correct and functional. Not as polished, but not wrong. When you multiply that across hundreds or thousands of generations, "good enough and very cheap" beats "excellent and pricey" for a whole category of jobs.

What I actually took away

The headline for me isn't "model X won." It's that there was no single winner, and the axes split cleanly:

• If I'm building something user-facing where taste matters, I'd reach for GPT 5.6 Sol.
• If I'm running a high-volume, cost-sensitive pipeline where the output just needs to be correct, Kimi K3 makes GPT 5.6 Sol hard to justify.
• Fable 5 sat as the steady all-rounder, rarely the best at any one thing, never embarrassing at any of them.

A year ago I would have just picked "the best model" and used it for everything. This little test made it obvious that's already the wrong mental model. The smarter question is which model for which job, and that means matching the tool to what the task actually rewards: design, throughput, or cost.

Interesting times to be building

The gap between these models is closing on quality and widening on choice. You now get to make real tradeoffs instead of taking whatever the one good option hands you. That's a genuinely good problem to have.

None of this was scientific, and your results will differ with your prompt and your task. But if you build with these tools every day, I'd encourage the same experiment: pick one honest little project, run it through a few models, and watch where they actually diverge. You'll learn more in twenty minutes than in a week of reading leaderboards.

Interesting times to be building.