Testing Local AI Coding Models on Strix Halo: Building a Pixel-Art Dog Headlamp Maze Game

Testing the top rated models as of July 2026..

I have been testing local AI coding models properly now, not just with small prompts or synthetic benchmarks, but with real coding tasks where the output has to work.

For this test, I wanted something visual, interactive and easy to judge. So I asked a group of local models to build the same browser game: a pixel-art dog with a headlamp exploring a dark maze-like room, lighting the map as it moves, avoiding furniture, finding the key or exit, and completing the game.

This was a better benchmark than asking for a basic app or a single function because it tested almost everything that matters in a coding agent:

• following a detailed prompt

• generating a full HTML, CSS and JavaScript file

• drawing a usable UI

• handling movement and collision logic

• tracking explored tiles

• creating lighting and visibility effects

• adding obstacles, doors and objectives

• making the game actually playable

• fixing broken code afterwards

The result was very clear: Qwen3.6-27B-MTP-GGUF Q8_0 is still the best initial-build model I tested, which lines up with what other people have also been seeing. It was not just about speed. It produced the best overall first-pass game.

The other important result was workflow related. For my setup, the best approach is now:

Use Qwen3.6 27B MTP Q8 for the initial build, then switch to Qwen3.6 35B A3B MTP Q8 for edits and fixes.

That combination gave me the best practical result.

Hardware and local setup used

These tests were run locally on my Strix Halo-style machine:

In the logs, Lemonade reported the Radeon 8060S with a very large visible memory pool. Vulkan showed around 114GB available to the backend in the logs, while ROCm showed around 110GB. That made it possible to test these larger Q8 and MTP GGUF models locally.

The test prompt

The base prompt asked each model to create a complete local browser game with no external assets.

The important requirements were:

• cute pixel-art dog

• dark room or maze

• dog has a headlamp

• WASD and arrow-key controls

• obstacles and furniture block movement

• explored areas remain softly visible

• unvisited areas stay dark

• exit door and win screen

• polished pet-themed design

• single HTML file with CSS and JavaScript included

I then tested the output in the browser and logged both model performance and actual playability.

Ranked model results

Figure 1: Qwen3.6-27B-MTP-GGUF Q8_0, best overall first build

Click to Play

This was the best overall one-shot result from the whole test. Qwen3.6-27B-MTP Q8 produced the most complete dog headlamp maze game, with the best balance of design, gameplay, lighting, dog character, explored-area behaviour and requirement-following.

It was not the fastest model, but it produced the strongest actual result. This is the model I would use first for local AI coding builds where I want the best chance of a working first version.

Figure 2: Qwen3.6-35B-A3B-MTP-GGUF UD-Q8_K_XL, best follow-up editor and fixer

Click to Play

Qwen3.6-35B-A3B-MTP Q8 did not beat the 27B model as the best first-pass game builder, but it became the best model for follow-up edits and fixes. After the Aeolus model had issues, this 35B model handled targeted fixes more effectively. This is the practical workflow I ended up with: use Qwen 27B Q8 for the initial build, then switch to Qwen 35B Q8 for fixes, cleanup and editing. For its own generation of the game, this version had directional issues on first run, where the light didn't follow the direction the character was facing.

Figure 3: Qwopus3.6-27B-v2-MTP-GGUF Q8_0, strong design but too many functional issues

Click to Play

Qwopus3.6-27B-v2-MTP Q8 produced one of the best-looking designs. The room layout was clean, the lighting effect worked well, and the game had a strong visual style. I originally considered this second, but after testing it more, I moved it to third. The dog could rotate into odd directions, the game did not end when I collected the key and reached the door, and the fix attempt started looping. It is a strong creative builder, but not as reliable as Qwen 27B Q8.

Figure 4: Ornith-1.0-35B-GGUF Q8_0, very good visual result but blocked by gameplay issues

Click to Play

Ornith 35B Q8 produced one of the best-looking visual results. The dog was larger, the atmosphere was strong, and the headlamp effect looked good. The issue was playability. The dog could get stuck, the map/pathing caused problems, and completion was not reliable. It was visually impressive, but not as useful overall as the Qwen 27B or Qwopus outputs.

Figure 5: Ornith-1.0-35B-AEON / MTP Q8, good map and obstacles but weaker game logic

Click to Play

The Ornith MTP Q8 run had a good map and strong obstacle placement. It also generated quickly and looked promising at first. The problem was the actual gameplay logic. The light at the front of the dog did not behave correctly in the first version, the dog could flip or move in odd directions, the door was missing at first, and part of the map was not accessible. A follow-up improved some of this, but the model also hit an OpenCode format issue.

Figure 6: Qwen3.6-35B-A3B-MTP-GGUF UD-Q6_K_XL, solid but not as strong as Q8

Click to Play

Qwen3.6-35B-A3B-MTP Q6 produced a decent playable-looking result, with a visible headlamp cone and a dark exploration feel. It was useful, but the result was not as strong as the Q8 version. The design was less polished and it did not stand out enough to beat the top models. I would treat this as a lighter fallback rather than the main model for this type of build.

Figure 7: Ornith-1.0-35B-MTP-GGUF Q6_K, fast and usable but weakest of the shown outputs

Click to Play

Ornith 35B MTP Q6 was fast and produced a usable game-like result, but it was the weakest of these visual outputs. The lighting and atmosphere were there, but the overall polish, map design and gameplay feel were not as strong as the higher-ranked models. It is still interesting as a speed-focused coding model, but for this dog game test it did not beat the better Qwen, Qwopus or Ornith Q8 outputs.

What I learned from the test

The biggest lesson was that the best workflow was not one model for everything.

I confirmed that Qwen3.6-27B-MTP-GGUF Q8_0 is the strongest local model I tested for the initial build. It followed the prompt better and created the most complete game. Other models were impressive in places, and some were faster, but Qwen 27B Q8 gave me the best practical first-pass result.

The second lesson was that Qwen3.6-35B-A3B-MTP-GGUF UD-Q8_K_XL is better for edits. When the original game still had issues, I tried fixing it with Qwen 27B first. It did make some changes, but it still left problems and the session became slow as the context grew. When I switched to Qwen 35B Q8, it fixed issues more quickly and behaved better as a code editor.

That is the main practical finding from this test.

The workflow I would use now

Profiles that worked best

For Qwen3.6-27B-MTP-GGUF Q8_0, the best initial-build profile was:

Backend: Vulkan
Context: 131072

--parallel 1 -ngl 99 --split-mode none --main-gpu 0 --flash-attn on --spec-type draft-mtp --spec-draft-n-max 2 --cache-type-k q4\_0 --cache-type-v q4\_0 -b 4096 -ub 512 --top-k 0

For Qwen3.6-35B-A3B-MTP-GGUF UD-Q8_K_XL, the best edit/fix profile was ROCm-based:

Backend: ROCm
Context: 131072

--parallel 1 -ngl 999 --split-mode none --main-gpu 0 --flash-attn on --spec-type draft-mtp --spec-draft-n-max 3 --cache-type-k q8\_0 --cache-type-v q8\_0 -b 2048 -ub 512 --top-k 0 --top-p 0.9 --min-p 0.05 --temp 0.25 --presence-penalty 0.2 --repeat-penalty 1.08

The important backend difference for my machine was:

• Qwen 27B Q8 worked best for me on Vulkan.

• Qwen 35B Q8 worked best for me on ROCm.

• Ornith Q8 also behaved much better on ROCm than Vulkan in my tests.
  

Common failure modes I saw

The failures were useful because they showed where these local coding models still struggle.

Across the tests I saw:

• dog sprites rotating upside down

• light revealing tiles rather than illuminating them naturally

• the whole map being visible at the start

• doors missing from the map

• key and door logic not ending the game

• blocked or inaccessible sections

• the dog moving too fast or skipping tiles

• OpenCode rejecting malformed agent/tool output

• models getting stuck in long thinking loops during fixes

This is why I now separate “builder” and “fixer” models instead of expecting one model to do every stage perfectly.

Final conclusion

For my local AI coding setup, the best result came from a two-model workflow.

Qwen3.6-27B-MTP-GGUF Q8_0 is the model I would use to create the first version of a project. It gave me the strongest full game from the original prompt and handled the visual/gameplay requirements better than the others.

Qwen3.6-35B-A3B-MTP-GGUF UD-Q8_K_XL is the model I would use afterwards for edits and fixes. It was better once there was already a file to work on and the task became more about repairing logic than inventing the whole thing from scratch.

That is the practical takeaway from this test:

Build with Qwen 27B Q8. Fix with Qwen 35B Q8.

For local coding on Strix Halo, that is currently the strongest workflow I have found.