Which Local AI Coding Model Actually Builds Better Software?

I tested the top Q8 models, head to head....

I tested local AI coding models by asking them to build the same Three.js dog game. Not a toy snippet. Not a synthetic benchmark. A real browser game with movement, UI, rewards, collision logic and bugs to fix.

Why I ran this test

If you spend any time around local AI discussions, you see the same thing over and over again.

People post tokens per second. They post benchmark charts. They talk about context windows, quants and throughput.

That all matters. But I wanted to test something more useful.

I wanted to know which local AI coding model actually builds better software.

So I set up a practical coding test using the same project brief across multiple local models running in Lemonade. The task was to build a complete 3D browser game called Pup Park Dash 3D.

The game had to be built in a single HTML file using Three.js. It had to include a start screen, a third-person dog, a 3D park, collectibles, obstacles, a care meter, a combo system, a reward screen, coupon code logic and mobile controls.

This turned into a much better benchmark than I expected.

The benchmark setup

For this round, I used the same broad game brief and tested several local models against the same task: build a playable 3D dog game in a single HTML file.

• Whether the game worked on the first run

• Whether movement and controls were correct

• How good the park, HUD and reward screen looked

• Whether the model could recover from errors after re-prompts

• How efficient it was with tokens

• How well the code was structured internally

This was not a sterile lab benchmark. It was a real coding session.

The results table

This is the final ranking after combining first-run success, final game quality, code structure, debugging ability and token efficiency.

Token and speed table

I also tracked the token footprint and the logged speed figures where they were available from the Lemonade/OpenCode run notes.

Speed note: throughput figures are from the Lemonade/OpenCode run notes captured during testing. Approximate values are marked with a tilde where the run was not captured as cleanly as the others.

Code review table

After the gameplay tests, I reviewed the generated HTML files directly. This changed my view of the winner slightly because the prettiest output was not always the cleanest codebase.

What I found after reviewing the code files

Once I had the finished HTML files, I opened them and looked at how each game was actually built.

This is where the benchmark became more interesting.

The prettiest result was not always backed by the cleanest code.

Best engineered code: Qwen3.6 35B A3B MTP UD-Q8_K_XL

From a code structure point of view, this was the strongest file in the set.

Its output came in at roughly 1,870 lines and was the most complete from a lifecycle point of view. It had clean separation between scene setup, environment generation, dog creation, particles, UI updates, event handling, pause/resume logic, game reset, reward logic and the main animation loop.

It felt like a more deliberate piece of software rather than just a long generated demo.

Best final playable experience: Qwopus3.6 27B Coder MTP Q8

This model did not win on first-run reliability.

It needed repair prompts, and it had issues with CapsuleGeometry, replay behaviour and some geometry problems on the dog body.

But once it was pushed into shape, the result was one of the strongest overall. The park felt good, the UI was strong, the movement ended up good, and the whole thing had a nice frontend/game feel.

Best balance of looks and usefulness: Qwen3.6 27B MTP Q8

This one impressed me because it worked first time and looked very good.

The initial movement logic was wrong, but it only took two prompts to get it into better shape. The visual quality was one of the strongest in the test.

Model-by-model breakdown

Qwen3.6 35B A3B MTP UD-Q8_K_XL

Qwen3.6 35B A3B MTP UD-Q8_K_XL: gameplay screenshot.

Score: 9.3 / 10

Status: The best first-shot result and the strongest code structure.

If I judged this test on practical usefulness alone, this model wins.

It produced the best first result in the whole round. The game worked first time. Movement was accurate. The GUI and button design were excellent.

The main issue was that some collectibles were floating too high for the dog to reach. That is annoying, but it is a much smaller problem than a broken start screen or inverted controls.

When I reviewed the code file, it also looked like the most complete piece of software engineering in the group.

What I liked

• Best first-run success

• No repair prompt needed

• Best code structure overall

• Best token efficiency

• Strong UI design

What held it back

• Some collectibles floated too high

• Dog and environment models were less charming than the best-looking rivals

Click to play and test the game yourself!

End of Game Scorecard:

Qwen3.6 35B A3B MTP UD-Q8_K_XL: reward screen.

Qwopus3.6 27B Coder MTP Q8

Qwopus3.6 27B Coder MTP Q8: gameplay screenshot.

Score: 8.8 / 10

Status: One of the best final games after repair. (Best looking game)

This was one of the most dramatic test runs.

The game eventually turned into one of my favourites, but it absolutely did not start that way. The first run failed when clicking start with a familiar CapsuleGeometry error.

After that came more issues. The body geometry needed fixing, the replay button broke the lighting, and even after the body orientation was corrected there were still extra geometry lumps sticking out of the sides of the dog.

And yet, despite all that, this model still ended up near the top. Once it got there, the result was genuinely strong. The GUI was one of the best, the park looked good, movement ended up good, and the whole thing had a nice frontend-oriented game feel.

What I liked

• One of the best GUIs in the whole test

• Good final movement and park layout

• Nice frontend instincts

• Strong final overall feel

What held it back

• Broken first run

• Several repair prompts needed

• Replay and geometry bugs

• Lower trust on first-shot reliability

Click to Play

End of Game Scorecard

Qwopus3.6 27B Coder MTP Q8: reward screen.

Qwen3.6 27B MTP Q8

Qwen3.6 27B MTP Q8: gameplay screenshot.

Score: 8.5 / 10

Status: One of the best-looking results, with a fixable movement issue.

This was one of the best-looking results in the whole benchmark.

It ran first time, which matters. The issue was control logic. The dog initially faced the camera when it should have faced away from it, and movement directions were inverted or circular in some cases.

The difference was that it recovered well. Two prompts were enough to get the controls into much better shape.

What I liked

• Worked first time

• Very attractive output

• Strong reward screen

• Repaired faster than several rivals

What held it back

• First-run movement logic was wrong

• Slightly behind the top model on code robustness

• HUD not quite as strong as the best Qwopus outputs

Click to play

End of Game Scorecard:

Qwen3.6 27B MTP Q8: reward screen.

Qwopus3.6 35B A3B Coder MTP Q8

Qwopus3.6 35B A3B Coder MTP Q8: gameplay screenshot.

Score: 8.2 / 10

Status: Strong final output, better than the Qwopus 27B v2 result, but still hurt by first-run reliability.

This was the first strong lesson of the test.

The final game had a nice HUD, a decent overall feel and a good reward screen. The dog model was better than the Qwopus 27B v2 output, and it also had a nice breathing animation while the dog was idle, which gave the character more life.

It also avoided the weird yellow scene-line artefacts that showed up in the Qwopus 27B v2 run.

But the first run still failed badly. It hit a THREE.CapsuleGeometry error, then a THREE import/global issue, and it needed multiple repair prompts before it became playable.

Even then, the early working version had direction problems, with the dog moving in odd ways relative to the camera. Once repaired, though, I would rank it above Qwopus3.6 27B v2 because the final model quality and scene presentation were clearly better.

What I liked

• Good HUD design

• Better dog model than Qwopus 27B v2

• Nice idle breathing animation

• No strange yellow line artefacts

• Complete feature coverage

• Respectable final polish once fixed

What held it back

• Broken first run

• Multiple repair prompts needed

• Relatively expensive token use for the result

• Direction/orientation issues early on

Click to Play

End of Game Scorecard

Qwopus3.6 35B A3B Coder MTP Q8: reward screen.

Qwopus3.6 27B v2 MTP Q8

Qwopus3.6 27B v2 MTP Q8: gameplay screenshot with the yellow line artefacts.

Score: 7.8 / 10

Status: Efficient and good after a compatibility fix, but visually weaker than the 35B Coder result.

This one was interesting.

The first run did not work because it used CapsuleGeometry with a Three.js version that did not support it. Once fixed, the game came together well.

It had a nice park layout, a very good GUI and, importantly, no persistent movement issue like some of the other models.

The problems were more visual than architectural. There were odd yellow lines across the scene, and the dog model had a comically oversized rear end.

That is why I moved it below Qwopus3.6 35B A3B Coder MTP Q8 in the final ranking. The 27B v2 run was efficient and usable, but the 35B Coder output had the better dog model, better idle character feel and no strange line artefacts.

What I liked

• Good GUI

• No persistent movement issue

• Nice overall park layout

• Strong token economy relative to quality

What held it back

• Broken first run due to geometry compatibility

• Strange scene lines

• Dog proportions looked off

• Final visual quality was weaker than Qwopus3.6 35B A3B Coder MTP Q8

Click to Play

End of Game Scorecard

Qwopus3.6 27B v2 MTP Q8: reward screen.

Ornith 1.0 35B Q8_0

Ornith 1.0 35B Q8_0: gameplay screenshot.

Score: 7.0 / 10

Status: Good first impression, but poor targeted debugging.

Ornith ran first time, which immediately gave it credit.

The design and general model output were better than I expected. The dog model and reward screen were good. But movement was wrong, and even after six prompts it still was not properly fixed.

That was a big warning sign. A model can look promising, but if it cannot resolve a core gameplay bug after repeated repair attempts, it loses usefulness fast.

What I liked

• Ran first time

• Nice visual style

• Clean reward screen

• Pleasant overall game feel

What held it back

• Saved the file to the wrong folder first

• Direction bug persisted

• Poor repair efficiency

• Highest token usage of the round

Click to Play

End of Game Scorecard

Ornith 1.0 35B Q8_0: reward screen.

Ornith 1.0 35B AEON Ultimate Uncensored MTP Q8

Ornith AEON MTP Q8_0: gameplay screenshot showing the unusual tube-like item.

Score: 6.4 / 10

Status: Fast, but the weakest practical result.

This was fast, and it worked first time, but it was also one of the weakest final results.

Movement was strange in every direction. Every button seemed to move the dog oddly. The heart collectible looked like a long tube rather than a heart.

A second prompt did not improve things in a meaningful way. This is the kind of result that reminds you why speed alone is not enough.

What I liked

• Fast

• Worked first time

• Complete feature set

• Clean enough reward screen

What held it back

• Strange movement in every direction

• Weak object quality

• Repair round did not really help

Click to Play

End of Game Scorecard

Ornith AEON MTP Q8_0: reward screen.

So which model actually built the best software?

I think there are three honest answers.

• Best first-shot coding model: Qwen3.6 35B A3B MTP UD-Q8_K_XL. This is the model I would trust first if I wanted a strong, working result without babysitting it.

• Best final game after iteration: Qwopus3.6 27B Coder MTP Q8. This is the model I would choose if I cared most about frontend feel and I was willing to guide it.

• Best balance of visual quality and reliability: Qwen3.6 27B MTP Q8. This one sits in a very nice middle ground.

Why tokens per second are not enough

This benchmark reminded me of something I already suspected.

The fastest model is not automatically the best model.

If a model gives you great tokens per second but sends you into a six-prompt debugging loop to fix basic movement, that speed advantage disappears quickly.

A slightly slower model that produces a more coherent codebase, gets the direction system right, manages state properly and only needs light correction is often the better choice in real life.

What matters is not just how quickly the tokens come out. What matters is how quickly you get to a result you can trust.

Final verdict

If you forced me to pick just one model from this benchmark for real coding work, I would currently choose Qwen3.6 35B A3B MTP UD-Q8_K_XL.

It was the best engineer.

If you asked me which model felt the most exciting creatively, I would say Qwopus3.6 27B Coder MTP Q8.

If you asked me which one looked the best without becoming a total debugging sinkhole, I would say Qwen3.6 27B MTP Q8.

That is the real conclusion of this test. There was no single winner in every category. But there were very clear personalities.

And after spending a frankly ridiculous number of tokens making dogs run around low-poly parks, I came away even more convinced that real-world coding benchmarks are far more useful than generic synthetic scores.