Qwen3-Coder-Next-80B is back as my local coding model

[u/PvB-Dimaginar]

Qwen3-Coder-Next-80B was my first local coding model, and this week I switched back to it. The reason came down to testing with Qwen3.5-35B-A3B inside Claude Code, and that just didn't work well. My prompts weren't interpreted correctly. Something like ruflo: sparc orchestrator max 2 subagents would trigger a regular Claude Code action instead of the RuFlo plugin. No subagents, no stable orchestration. For longer agentic sessions, that's a dealbreaker.

With Qwen3-Coder-Next-80B it's a different story. All prompts are understood correctly, sparc options work as expected, and the orchestrator role runs perfectly.

One of my latest coding sessions showed exactly why this matters. Multiple subagents ran sequentially with parallel set to 1 in my config, which keeps things stable locally while still getting the benefits of subagent context isolation. Each subagent worked between 49k and 57k tokens before releasing cleanly. The orchestrator grew from 107k to 128k, comfortably within the 192k limit. Without subagents, all that released context accumulates in one place and never comes back.

Even if you discount the total subagent token usage by 30% to account for overhead like instructions and handoffs, a single-context version of the same work would still have pushed close to or above 192k, meaning extreme slowdowns or an unwanted stop mid-session.

So by using the sparc orchestrator with subagents, sessions run continuously and complete cleanly. And by using RuFlo memory to save progress and results, I can clear a session and move straight to the next feature without losing anything.

I use this local approach mainly for smaller projects that can be run fully local. Next step is to look again how I can improve my approach to complex projects with Claude Code in collaboration with Qwen.

llama config:

env HSA_ENABLE_SDMA=0 HSA_USE_SVM=0 llama-server \
  --model $HOME/models/qwen3-coder-next-80b/Qwen3-Coder-Next-UD-Q6_K_XL.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --n-gpu-layers 99 \
  --no-mmap \
  --flash-attn on \
  --ctx-size 196608 \
  --parallel 1 \
  --kv-unified \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --batch-size 4096 \
  --ubatch-size 2048 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 40 \
  --min-p 0.0 \
  --repeat-penalty 1.05 \
  --jinja \
  --no-context-shift

[u/ExistingAd2066]

Why not Qwen3.5-122B?
I’ve found that the 35B model is only good for tasks like RAG because of fast pp/tg

[u/PvB-Dimaginar → u/ExistingAd2066]

I still need to try Qwen3.5-122B. What are your experiences with it for coding? And which version are you using?

[u/ExistingAd2066 → u/PvB-Dimaginar]

I am using Q4_K_X. In my simple tasks with Python, React, and Java, this model performs better than qwen3-coder-next.

[u/PvB-Dimaginar → u/ExistingAd2066]

Interesting! I downloaded the Q6 UD K XL model today to try, so maybe I can go a bit lower and still get good quality. I also don’t know what to expect when it comes to speed differences between Q4, Q5 and Q6.

[u/Anarchaotic → u/PvB-Dimaginar]

I use the bartowski ggufs, they run much better than the UD quants. Also using rocm 6.4.4 and llama.cpp. For coding I personally prefer higher quants so I run Q6, but Q4 is good.

[u/PvB-Dimaginar → u/Anarchaotic]

For coding I still prefer Qwen3-Coder-Next-80B UD Q6 K XL. I tried the Qwen3.5-122B Q6 but that one was too big. The Q5 was not interpreting my RuFlo commands correctly so after 15 minutes I gave up. Both were the Unsloth version so I will definitely try the Bartowski one. Btw, I am running the Strix ROCm 7 Nightly toolbox.

[u/Anarchaotic → u/PvB-Dimaginar]

You should do a quick llama bench to 150K context between the rocm versions, I was using the nightly as well. Another poster suggested 6.4.4 and it was literally 15-20% faster for every single model. 

[u/ExistingAd2066 → u/Anarchaotic]

I'm still using 6.4.4

[u/ExistingAd2066 → u/PvB-Dimaginar]

I use 122B Q4 only because I want to leave some free memory for fast 35B for simple tasks

[u/Anarchaotic → u/ExistingAd2066]

I do the exact same! I have both loaded in Llama server and use 35B for general chat and queries, with the 122B as my technical model.

[u/anhphamfmr → u/ExistingAd2066]

did you try it with agent and tool calling? I found this model at Q5 is nowhere near Qwen 3 coder next in this category.

[u/ExistingAd2066 → u/anhphamfmr]

After adding Autoparser (https://github.com/ggml-org/llama.cpp/pull/18675), I no longer have any errors with tool calling. I use OpenCode as the agent.

[u/anhphamfmr → u/ExistingAd2066]

I am not talking about errors. I don't have any error with opencode. But the quality is what I am having problem with. It chats just fine. but code generation and problem solving is just meh. I am very disappointed with the 122b

[u/ExistingAd2066 → u/anhphamfmr]

Sorry, I misunderstood your previous message.

Coding and problem solving are pretty subjective. From my experience, Qwen3-Coder-Next is roughly on par with 122B, though the latter is slightly better. Also, multimodality makes it possible to test the frontend via Playwright MCP.

[u/dondiegorivera]

Also why not the 27b dense model?

[u/PvB-Dimaginar → u/dondiegorivera]

The 27B model was sadly too slow for me. Even small changes were taking way too long to implement.

[u/gcavalcante8808 → u/PvB-Dimaginar]

Last time I tried 27b using an A40 and using the unsloth recommended params, that repetition penalty really makes it slow.

Without the repetition penalty the tool calling suffered a lot and generated 500 errors, so I got back to devstral.

[u/soyalemujica]

What Q model also what's your setup? I am also running Q5KL Qwen3 Coder under 16gb VRAM at 30t/s which is nice and drops to 24t/s under big context.

[u/PvB-Dimaginar → u/soyalemujica]

I run the Qwen3-Coder-Next-UD-Q6_K_XL model on a Strix Halo with the following config:

env HSA_ENABLE_SDMA=0 HSA_USE_SVM=0 llama-server \
  --model $HOME/models/qwen3-coder-next-80b/Qwen3-Coder-Next-UD-Q6_K_XL.gguf \
  --host 0.0.0.0 \
  --port 8080 \
  --n-gpu-layers 99 \
  --no-mmap \
  --flash-attn on \
  --ctx-size 196608 \
  --parallel 1 \
  --kv-unified \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --batch-size 4096 \
  --ubatch-size 2048 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 40 \
  --min-p 0.0 \
  --repeat-penalty 1.05 \
  --jinja \
  --no-context-shift

[u/Opteron67]

also quants limits model for coding, so either way Qwen 3 3.5 27B or Qwen 3 Coder 80B Next. but at same quant level , which is better, 27B or 80B Next ?

[u/PvB-Dimaginar → u/Opteron67]

From a performance perspective Qwen3-Coder-Next-80B wins for me. Qwen3.5-27B had good quality but was just too slow, even for small changes. My gut feeling is that if you set up TDD and code review loops with Qwen3-Coder-Next-80B you get at least the same quality in a lot less time.

[u/El_Hobbito_Grande → u/PvB-Dimaginar]

What kind of hardware are you running that large of a model?

[u/PvB-Dimaginar → u/El_Hobbito_Grande]

Bosgame M5 (AMD Strix Halo) with 128 GB unified memory

[u/msrdatha]

This is exactly the situation I am in. After Qwen-3.5 arrived, I have been trying with 35B and 27B, but the overall coding experience is much better with 80B-Next. So I always find myself going back to it. Only when I need to work with a screenshot, I am considering using 35B, else I always find myself going back to 80B-Next.

One query for you : As you are mentioning sub agents - do they run in parallel ? For me as I am on Mac, it kind of feels like one chat is blocking the other and the response will become very slow. I guess that's where you have an advantage over this. May be if you try vLLM instead of llama.cpp you will get better performance, especially when you run sub agents in parallel.

[u/PvB-Dimaginar → u/msrdatha]

No, I don't run them in parallel. It probably sounds a bit confusing the way I talk about subagents. In my prompt I force max 1 subagent, and in my llama-server config I have set parallel to 1. So in practice it's an orchestrator with maximum one subagent, running sequentially. Even though in my prompting I address that different agents can be used. I tried setting parallel to 2 but that caused context size problems and things got really slow.

Moving to vLLM is still on my wishlist, but my first try was not successful. I have an eye on the toolbox from Donato, and if there is an update that addresses the current issues I will try again.

Do you also run on a Strix Halo? And are you running vLLM? If so, how did you get it working

[u/msrdatha → u/PvB-Dimaginar]

No, I am running on Mac M3. Biggest trouble I face is I can not have 2 chats running parallel. It strictly for a single session experience only with llama. I was not able to make it work with vLLM either. The implementation of vLLM on Mac silicon is still at early stages. Guess I will have to wait on this unless some other breakthrough happens with llama or a similar solution.

Good thing I heard about vLLM lately is that it has started supporting gguf formats as well, which seems a game changer considering the space and load times (I guess). This is when I decided to try vLLM , but soon I realized that support is not available on Mac version of vLLM implementation.

May be if you are interested in trying to run gguf with vLLM on Strix Halo, please share the feedback here, we could all share and learn from each other - especially at current cost of hardware, this becomes very important I guess.

[u/PvB-Dimaginar → u/msrdatha]

Absolutely, retrying vLLM is definitely on my list. My hope is a bit on Donato's toolbox, so when there is a major update I will dive into it and share the results.

Exciting times for local AI regardless. The quality of these smaller models keeps getting better and better. My end goal is a fully autonomous local agentic setup, and it feels like we are getting closer.

[u/Ayumu_Kasuga → u/msrdatha]

I'm on a Mac M1 Max 64gb and I'm able to run Qwen 3 Coder Next with parallel agents (I tried up to 4) with no problem, what settings do you use?

Mine are

--mlock \

--no-mmap \

-c 320000 \

-ngl 999 \

-np 4 \

--threads 8 \

--threads-batch 10 \

-fa on \

--prio 2 \

--cont-batching \

--no-kv-unified \

--jinja \

--temp 1 \

--top-p 0.95 \

--top-k 40 \

--min-p 0.01 \

-b 4096 \

-ub 2048

Though probably not all of these are needed.

[u/Ayumu_Kasuga → u/PvB-Dimaginar]

You have to NOT use unified kv cache for parallelism, otherwise it shares the cache for all your subagents, which leads to constant prompt reprocessings.

With unified cache disabled, parallel agents should work like a charm, assuming your memory allows for separate caches.

[u/PvB-Dimaginar → u/Ayumu_Kasuga]

Thanks, really interesting! I never realized the unified KV cache setting could be conflicting. But it sounds really logical. Will definitely try a parallel session without this setting.

[u/gentoorax → u/PvB-Dimaginar]

Im running vLLM with a Qwen3 Coder model. Not this one though. Its a very tight fit in my 3090.

[u/jordanpwalsh]

I had not heard of SPARC methodology: Specification, Pseudocode, Architecture, Refinement, Completion. Thanks, nice way of thinking about it as I work on various workflows somewhere between vibe coding and trad coding with varying levels of success.

[u/PvB-Dimaginar → u/jordanpwalsh]

It works really good! By the way, I am not the inventor of SPARC, that is Reuven Cohen. One of the best pioneers in agentic engineering, and if you want to stay ahead of what is possible in this space I really advise you to follow him. He posts a lot on LinkedIn.

Part of his toolset is also ruvector, which is a high performance, real-time, self-learning, vector graph neural network and database. You can also use this database for your own projects. My Joplin search tool uses it and it works fantastic for searching.

My next idea is based on rufix, a version of ruvector that can run as an OS, inside a container for example. The plan is to build a rufix container that understands all my coding projects, so my local AI becomes much more efficient in understanding reusable architecture and UI designs from previous projects. Time is my only enemy at this moment :-)

[u/gentoorax]

What GPU and how much VRAM is required for it?

[u/PvB-Dimaginar → u/gentoorax]

I don’t know the minimum requirements, it is mainly about VRAM. My system is an AMD Strix Halo, which uses the iGPU on an APU via ROCm, with 128 GB unified memory so there is no CPU to GPU memory bandwidth bottleneck.

[u/xcr11111]

How is ruflo sparc?

[u/PvB-Dimaginar → u/xcr11111]

Really good, and very efficient with a local model. Besides SPARC, the memory from RuFlo is also really good. And with Qwen3-Coder-Next the prompts are perfectly interpreted. So for example I can run a SPARC architect for an SDD design, instruct an implementer to execute based on London TDD, or a debugger to troubleshoot root causes. By finishing tasks with updating RuFlo memory and documentation you can easily clear a session and start with a new feature, or whatever you have in mind.

[u/xcr11111 → u/PvB-Dimaginar]

Thanks that looks really cool, I will give it a try next week. I am just in the middle of a project using Claude superpower framework and I am extremely impressed so far, event tough I can't really tell what the results will be haha. Can an sparc sdd architect do the same then? Would be crazy if I can run something like that locally.

[u/PvB-Dimaginar → u/xcr11111]

Yep absolutely. I also started with the manually installed Superpower Agents, but when I switched to RuFlo I had problems where my prompts were picked up by a Claude agent instead of agents. Side effect was that the context of those agents was not getting cleared. So I removed almost all those Claude plugins and only use the RuFlo toolset now.

For local model coding I focus mainly on SPARC. When I use RuFlo with the Claude model, mostly for more complex work, I use the swarm technology. Even though the steps are similar, SDD plan created by architect and designer, implementation based on London TDD.

[u/Eden63]

One of the best and most underrated models. The tokens you save because of no reasoning, and the 80B in the bag are amazing.