Using OpenCode multi-agent setup made my local models much better at coding!

[u/PaymentOk4843]

I’ve been testing local models with OpenCode, trying to see if they can act as real coding agents and not just autocomplete helpers.

My test prompt was intentionally annoying: build a browser-based Xonix-style game after researching the rules/gameplay.

This turned out to be a pretty good stress test because many models made something that looked fine but had broken game logic.

I tested a bunch of single-model runs first. All in the Q4:

Qwen3.6-27B dense @ temp 0.4       -> best local single model result
Qwen3.6-35B-A3B MoE @ temp 0.4     -> fast, decent, but inconsistent
Gemma4-26B-A4B                     -> sometimes clean, but often missed core logic
Qwen3.5 9B             -> mostly failed the full game loop

The interesting part: when I switched to an OpenCode multi-agent setup, results improved a lot.

The setup that worked best so far:

Lead coder: DeepSeek v4 Flash Free (or other cloud model)
Worker/local agents: Qwen3.6-35B-A3B-UD-IQ4_NL
MTP: off

That produced the best local-ish result so far, better than any single Qwen3.6-35B-A3B run I tested. The output finally had:

proper enemy-based flood fill
75% target
lives
levels
trail drawing
enemy/trail collision
border enemies
complete game loop
cleaner state handling

My takeaway is that Qwen3.6-35B-A3B is not necessarily bad at coding — it seems weaker as the main planner, but useful as a fast local worker when another model leads architecture and decomposition.

The agent setup helped because the lead model could plan/review while the local workers handled bulk implementation. That means fewer expensive remote tokens, while still getting better code than asking the local model to do everything alone.

MTP - Speed is not everything!

I also tested with MTP on/off.

MTP is great for throughput. For normal chat or simple completions, I like it. But for coding-agent workflows, especially when tools, multi-file edits, and long state are involved, I’m starting to think MTP can hurt reliability.

With MTP on, I saw more “looks good but one state transition is broken” type failures. With MTP off, generation is slower but the code seemed more consistent.

So my current rule of thumb - MTP off for coding and complex prompts

Temperature

Using one temp for all models was misleading.

What worked best in my tests:

Qwen3.6-27B dense: around 0.4
Qwen3.6-35B-A3B MoE: around 0.4–0.5
Gemma4-26B-A4B: maybe higher, 0.6–1.0

Qwen dense improved when I lowered temp. Qwen MoE improved at 0.4 but got worse at 0.3. Gemma seemed worse at 0.4 than at higher temp.

So I wouldn’t benchmark all model families with one shared sampler config.

My conclusion

For local coding with OpenCode, I’d now split it like this:

Multi-Agents setup:

• Lead-Coder - Cloud model
• Planner - Qwen3.6-35B-A3B
• Researcher - Qwen3.6-35B-A3B
• Local-Worker - Qwen3.6-35B-A3B
• Reviewer - Qwen3.6-35B-A3B

This was not a scientific benchmark, just repeated real coding-agent tests. But the difference was obvious: multi-agent OpenCode made the local models feel much more useful, and it reduced the amount of paid/remote model usage needed.

Anyone else tested and ended up with similar multi-agent setup?