Claude Code vs Kimi Code: how I'd check a $13 vs $4 game build

Two coding agents built a Counter-Strike style game. Here is a step by step check of the cost, quality and fairness claims before you trust them.

A note on how this was written: an AI writing assistant drafted it from the source listed at the end, and every claim was checked against that source before it went out.

At a glance

A video pitted Claude Code against Kimi Code on five steps of building a shooter game, and Kimi cost far less per step.
The quality verdicts come from one viewer, judging Kimi first every time, from one run each.
Here are 5 checks I'd run before I'd pick a coding agent on numbers like these.

One video, five steps, two very different bills

I watched a video where two coding agents race to build a Counter-Strike style game from scratch. What caught my eye wasn't who won. It was how much a single comparison like this tells you, and how much it can't.

The setup: Claude Code running Claude Opus 3.5, against Kimi Code running Kimi k 1.5 Pro. Each agent was connected to Blender through MCP and also used Godot. The prompts were the same word for word. No ready-made models or animation packs were allowed. The build went in five steps: an arsenal (an AK-47, a pistol, a karambit knife and three grenades), a map, a first-person player, fighter models with animations, and the full game.

The creator's summary is simple: Claude wins on quality, Kimi wins on cost. The cost gap is large. On the first step it was almost 4 dollars for Kimi against 13 for Claude, at pay-per-use rates. If you're choosing a coding agent, a gap like that makes you want to switch. So here's how I'd check a claim like this, one step at a time.

Step 1: Pull the cost claim apart from the quality claim

These are two different claims, and they rest on different kinds of evidence. Cost is measured: tokens and dollars per step. Quality is a judgment: one person looking at a rifle and saying the trigger sits too low.

The cost numbers from the video, step by step:

Arsenal: Kimi used almost half as many tokens, almost 4 dollars against 13.

Map: about 13.5 million tokens and 4 dollars for Kimi, against 39 million tokens and 16 dollars for Claude.

First-person player: Claude spent nearly three times more tokens, and the step cost almost four times more.

Fighter models: almost 11 million tokens against 51.5 million, and a little over 3 dollars against 20. That's almost six times the cost.

What a bad result looks like here: a post or video that blends the two claims into one ('Kimi is the better deal') without saying better at what. A cheap run that you have to redo isn't cheap. So the cost per step only matters once you know the result at that step was usable.

Step 2: Put the cost in the unit you actually pay

The video gives three different ways to count cost, and they don't point the same way.

Per token, Kimi is far cheaper. But the creator also compared plan limits. On the arsenal step, Kimi used 45% of its five-hour limit and 2.5% of its monthly limit on a 39 dollar plan. Claude's 100 dollar plan used 7% of its five-hour limit and 1% of its weekly limit. The creator then guessed that on a 20 dollar Claude plan you could multiply by five: 35% of the five-hour limit and 5% of the weekly.

Notice what that last pair is. It's not a measurement. It's an estimate by multiplying, and the creator says so ('for the sake of example'). I'd keep it out of any decision until someone runs it.

What a bad result looks like: comparing a monthly limit to a weekly one as if they were the same. A 2.5% monthly share and a 1% weekly share can't be lined up directly. If you're on a subscription, the question that matters is how many of these tasks fit in a window before you hit the wall. If you pay per token, the dollar figures are the ones to read.

Step 3: Check who judged, and in what order

Every quality call in the video comes from one person. The creator says at the start that Claude will likely do better, and also that they're rooting for Kimi. On the arsenal step they call the result 'a matter of personal taste.' That's a fair thing to say, and it's also the point: there was no score sheet.

Then there's order. In each step the creator reviews Kimi's work first and Claude's second. When you always see one option first, the second one is judged against it. That can push the verdict either way, and you can't tell which from one pass.

If the judge scores the same output differently on a second look, that spread is the noise floor. Any gap smaller than that isn't a real difference.

What a bad result looks like: one reviewer, a fixed order, and no written criteria. That's the setup here, so I'd read the quality verdicts as one person's first impressions, not as a ranking.

Step 4: Look for things that broke the clock

Time is the easiest number to get wrong. On the first-person player step, Claude spent almost 2 hours. But the creator explains that Blender froze for half an hour and Claude just waited, and then they restarted it. Kimi spent an hour and 17 minutes on that step. After the freeze, the creator says the time came out about the same.

Kimi's slowness has its own excuse: the creator points to load on Kimi's servers, which Kimi's site warned about.

So both timing numbers carry something that isn't the model. One is a frozen tool. The other is a busy server. Neither is a fact about how fast the agent thinks.

What a bad result looks like: a single wall-clock number per agent with no log of stalls, retries or restarts. If I were running this, I'd record active time and waiting time separately, and I'd mark any run where the tool hung.

Step 5: Ask whether one run is enough

Each agent built each step once. Coding agents don't give the same output twice. One run of the arsenal might give a strange trigger and a pistol pointing the wrong way (both of which the creator saw in Kimi's first try). The next run might not.

There's also one task. A shooter built in Blender and Godot leans hard on 3D work and on reading the screen. The creator says from experience that Kimi 'has worse vision,' and the hand and finger work on step three is where Kimi fell furthest behind. That may tell you a lot about 3D-heavy jobs and very little about, say, writing a data pipeline.

What a bad result looks like: a winner named from one run on one kind of task, then applied to everything. I'd want at least a few runs per step and a task that looks like my own work before I trusted the gap.

One more thing I couldn't check: the transcript I read was cut off during the final step, so I didn't see how the two full games played. I'm only judging the parts I could read.

The case for the video as it is

To be fair to it, this kind of test is useful. The prompts were the same. Both agents worked at the same time, each on its own copy. Nothing pre-made was allowed. And the token and dollar numbers are real measurements from real runs, which is more than most comparisons give you.

The cost gap is also big enough that noise is unlikely to erase it. Four to six times cheaper per step, across several steps, is a signal. Where I'd hold back is on the quality side, because that's where one judge, one run and a fixed order all stack up.

The mistakes I see people make

Treating a cheaper run as a cheaper result. If you redo it, you pay twice.

Mixing plan limits and token prices in one sentence. They answer different questions.

Trusting time numbers without a log of stalls. A frozen tool or a busy server can eat an hour.

Taking one reviewer's taste as a score. Fine for a video, not enough for a choice you'll live with for months.

Reading a pooled verdict as if it held at every step. In this video the arsenal step was split (Claude better on the rifle and grenades, Kimi better on the pistol and knife), while step three went clearly to Claude. A single 'Claude wins on quality' hides that split.

Check it yourself

Pick one real task from your own work and write the prompt once. Give it to both agents word for word.
Run each agent at least three times on that task. Save every output.
Log tokens, dollars, active time and waiting time for each run. Mark any run where a tool hung or a server was slow.
Before you look at any output, write down three to five things a good result must have. Score each output against that list.
Shuffle the outputs and hide which agent made which. Score them in a random order, then score one of them again later as a control. If your two scores for the same output differ, any gap between agents smaller than that doesn't count.
Divide the cost by the number of runs that were usable, not by the total runs. That's your real cost per good result.

This post was drafted with AI. I checked every number against the video's transcript and cut anything I couldn't trace there.