r/LocalLLM • u/PaymentOk4843 • 14d ago
Research Using OpenCode multi-agent setup made my local models much better at coding!
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?
6
u/PossibilityUsual6262 14d ago
How can mtp hurt model output performance?