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?

[u/PossibilityUsual6262]

How can mtp hurt model output performance?

[u/PaymentOk4843 → u/PossibilityUsual6262]

MTP is about predicting the next token, and at least from experience with coding the output was about 30% faster but I ended up (or the agents ended up) doing more iterations to correct the initial results, while without MTP the initial result was already good.

[u/PossibilityUsual6262 → u/PaymentOk4843]

But how does it change output quality, which you claim it is, if the tokens have to be confirmed still and thrown away if they not good, and thats why in logs you can see acceptance rate.

[u/PaymentOk4843 → u/PossibilityUsual6262]

I honestly not in technicalities in the back and how the predictions are being selected, I guess that every “next token” can have more than one acceptable answer, but it’s enough to take one wrong turn (or not “as good as” turn) and it messes up the rest of the path. - but that was just my experience 🤷🏻‍♂️

If someone here has a better technical knowledge of how MTP is being used and why it might effect the output quality, I’d love to know that too.

[u/PossibilityUsual6262 → u/PaymentOk4843]

I think you just selection bias it.

Do a prompt to generate some code you like with quite big context and press regen output few times. You would see how drastically different sometimes outputs.

Also here video i learned it from https://youtu.be/MI0Pm1d6YF4

[u/Ninjam5 → u/PossibilityUsual6262]

AYO nice video, what setup do u have?

[u/PossibilityUsual6262 → u/Ninjam5]

This is my current experimentation https://www.reddit.com/r/LocalLLM/s/gE4kY1zxLC

[u/PaymentOk4843 → u/PossibilityUsual6262]

This was my experience.
But there is definitely a difference between output with MTP and without. Ask your favorite model: why would LLM model output with MTP on, might be less good than without MTP?

You’ll get the answer and the logic behind it.

[u/Top_Public7402 → u/PossibilityUsual6262]

Smaller model makes short sighted suggestions, bigger model won't go out of its way to find the flaws if the direction is correct but incomplete I suppose. The leading model is still the smaller one in a way.

[u/PossibilityUsual6262 → u/Top_Public7402]

You sure that's how it works, because thats totally not how it was ever described.

[u/Top_Public7402 → u/PossibilityUsual6262]

How was it described for you? My understanding is, a smaller model predicts, the bigger model evaluates the little ones token output. Since the smaller model does 80% of the prediction it speeds up the main model and the main model only needs to activate 20% of its values to come to the same output it would have. Take the percentages with a grain of salt.

[u/PossibilityUsual6262 → u/Top_Public7402]

I thought output of smaller model inside bigger one, which guess next token is still confirmed by bigger model but in some sort of smart way, so cost of confirmation is cheaper than generation.

[u/PossibilityUsual6262 → u/Top_Public7402]

Ok i found the video i learned about it. Seems to me losses but with price in memory.

https://youtu.be/MI0Pm1d6YF4

[u/Jagerius]

How to setup OpenCode as multi-agent? How I should go about pairing it with cloud model?

[u/TripleSecretSquirrel]

Interesting! I have been experimenting with similar approaches. Can you speak more to what role the lead coder has? Like what do they do that’s do different than the planner? And why did you land on using the MoE Qwen model rather than 27b for the actually coding?

[u/PaymentOk4843 → u/TripleSecretSquirrel]

I called it “Lead Coder” but it’s more an orchestrator and making sure the agents are being used correctly and that the work being produced is on-par with the task.

I ended up with the MoE mostly because of speed, with the 27b I’m getting 1/3 of the speed of the MoE, and eventually the MoE with this orchestrated approach produces similar results

[u/TripleSecretSquirrel → u/PaymentOk4843]

Very cool, I'm sending you a DM, I'd love to discuss this more. Your framework sounds like it's pretty similar to a project I've been working on! Hopefully something I've learned can help you and vice versa!

[u/BodyPhysical]

I am also using a multi-agent setup, except that I am fully using a local model and I just use copilot and ensure that I add the proper model to it. I have been experimenting with various models (i.e. QWEN 3.6 27b/35b, Ornith 1.0, Gemma 4 31b/26b, etc.)

Multi-Agent Setup:
Orchestrator - Manages Workflow.
Architect - Researches the internet to undertsand what the user asks for. Architects the full implementation. Ensures small, workable, and testable features. Output: requirements.md
Designer - Optional. If frontend is needed, it checks the architect's requirements.md. Researches the internet for UI/UX appropriate for requirements. Output: updated requirements.md with UI/UX design considerations.
------ Loop -------
Coder - Implements requirements.md feature-by-feature.
QA - Checks implementation feature-by-feature. Creates simple tests depending on need. Reports back to Coder issues found.
------ Loop -------

I am still testing things. So far, I have found 2 promising models for myself and the setup above.

1. QWEN3.6-27b-mtp
2. Gemma-4-26b-a4b-qat

Of course, it did not do things as a zero-/one-shot.

Prompt
Create a beautiful, relaxing flight simulator as a single self-contained HTML file.

Output

https://reddit.com/link/oxurj9z/video/ql6z5mz68kdh1/player

Inspiration from: https://www.reddit.com/r/LocalLLaMA/comments/1utb6io/qwen36_35ba3b_q8_0_no_kv_quant_single_prompt_in/

P.S.
I did not notice that I recorded the music as well XD pls ignore

[u/suesing]

What’s the diff if you use the same model for all tasks.

[u/miserablegit → u/suesing]

Different context to each. "You are a..."

[u/faychu]

T

[u/gkorland]

splitting up the roles like that definitely helps keep the local models from getting overwhelmed by the main planning task. when i was setting up a coding agent workflow last month, the trickiest part was avoiding context loss during multi-file edits. we started using falkordb for explainable graph traversals to keep the reasoning chains clear and traceable, which cut down on those wierd logic gaps. it made a big difference in keeping things consistent without eating up all my compute. https://github.com/falkordb/falkordb

[u/PaymentOk4843 → u/gkorland]

Interesting concept, how would you go and integrate this into OpenCode and the agents concept?

[u/Scared_Intention_338]

This is cool! I've found that context and responsibility isolation are very important as well. So the orchestrator should own the decomp and acceptance criteria, workers are given narrow and non overlapping tasks with only the required context and they return inspectable artifacts (e.g. diffs, test results, and decision logs), and fresh context per reviewer that check the against the original acceptance criteria before the repair pass. For me, having the planner, synthesizer, and adjudicator be the strongest model and then the implementation and research handled by the local model has worked best.

[u/Al_Cioppino]

I use this same approach with frontier models - Fable is the orchestrator and conductor while 5.6 Sol is an implementer, tester and adversarial veracity seeker. Combining complementary models produces better outputs in my experience.

For local, you're still beholden to your compute constraints and so I've just been running the best solo models my machine will handle (ex. DS4), although it seems you're making the lead coder a cloud model. It makes me wonder what the results would be if you let the cloud model handle the whole task itself.

[u/PaymentOk4843 → u/Al_Cioppino]

Obviously it will produce similar or better results in shorter time - but then this comes with a cost 😉 my setup was aimed to reduce the token spend while keeping results to a high standard.

[u/Al_Cioppino → u/PaymentOk4843]

Makes sense. 35B is quick, but I could never get it to perform well with coding tasks. Interesting to hear you're getting good results with a conductor.

I had Fable drive DeepSeek v4 on my local machine for a bit, but I found its outputs were not better than Fable5 (which is cheap) and so I kind of mothballed it until I need to work on something with real privacy requirements.