I am in the same boat. I have a GHCP subscription and the latest stunt they pulled saw me out of credits entirely for the month from 3 prompts on April 3, so I spent all of April playing with local models and trying to get a decent setup going. I found Qwen3.6 and, well, I am cancelling my GHCP subscription and taking them up on their refund offer.

I've thrown some pretty ridiculous tasks at Qwen3.6 35b A3B. I'm only using the quant 4 version. I've had to nudge it to fix a few things it's implemented here and there, but it always reliably gets it done. I've also paired it with Serena for RAG - which has made it an absolute unstoppable beast thanks to the memories capabilities in Serena. Seriously, this model is unbelievably impressive and punches so far above its weight that it's ridiculous.

It also outperformed Claude Sonnet 4.6 on a task yesterday, which was the final nail in the coffin for my GHCP subscription.

I went through absolute hell getting it stable and working properly, so here's a few tips for anyone that has issues with it.

1) The tool calling issues are a widely known and often complained about topic. I've gotten it 100% reliable with tool calling, and it was much easier than one would think. The model REALLY requires preserve_thinking be enabled, which does cost just a little bit more RAM up front - but it's disabled by default (no idea why). Make sure it's enabled. If using LM Studio, toggle the Preserve Thinking on under the inference options. Otherwise, set preserve_thinking = true in your jinja template.

2) The second issue I ran into with tool calling and looping with tool use even after enabling preserve_thinking was the most commonly complained about use-case: opencode. I saw that 90% of the posts about tool calling issues revolved around usage with OpenCode, so after monitoring the hell out of the logs, I noticed that every single time the tool call failed - it was at the same exact token generation count that the model would finish and hand the call off, which would fail with invalid arguments to the tool call and loop. This is because OpenCode enforces a max output token count by default, and it's configurable via your JSON config. I raised the output token count drastically, and no more tool call failures at all.

3) Do NOT quantize the KV cache with Qwen models. Firstly, the model is quite resistant to it - it isn't needed. You won't save much of any space at all. I tested this with running KV cache of quant 4, and it only saved about 200MB of memory and it hurt the performance. The model kept crashing because the memory overhead to deal with trying to quantize it at higher contexts put enough strain on my GPU that Mac OS's interactivity timer watchdog kept killing the model. There's zero need to quantize the KV cache with a Qwen model, and it will only hurt the performance.

4) If running on a Mac, make sure you're weary of the thermal status. When the GPU clusters reach about 82c, they're throttling back. This is enough to cause some lag that results in timeouts when the Interactivity Watchdog, and it will kill the model. Grab the mac fan app and set custom points for the fan. Use the GPU sensors as the sources to monitor, and set the low cool temp to 50c and the highest to 80c. The fans will begin to kick in full-force at 80c and keep it below 82, and the thermal throttling will stop.

5) Use the GGUF model if running on Mac. I know it's tempting to go with MLX because, hey, it's supposed to be optimized for Apple. The truth is you ONLY gain performance in the token generation speed, and not by that much. I do 65tok/s with GGUF, and I believe I clocked about 72 tok/s with MLX version. The issue, however, is that the prompt processing with MLX is WAY slower. The memory is also allocated on-demand and bursts. So after every task is finished, you'll see that memory drop all the way back down to no usage, and the minute you make a prompt it skyrockets back up. This means the KV Cache / token reuse is absolutely disabled, and you're re-processing every full prompt with no token reuse. This actually causes the prompt processing to not only take longer, but more importantly - it spins the GPU's up to the max the entire time it's doing this because it's making a metric shit ton of allocations during the prefill. The higher the context gets, the higher the heat gets - and the longer it holds the GPU (far more aggressively than GGUF, at that) - so the interactivity watchdog kicks in and kills the model. GGUF pre-allocates all of the memory up front, so what you see in use when the model is loaded? That's what it's going to use. IF you see memory creep while using GGUF, it's a different issue: you may have too high of a context for the memory bandwidth you have, and while the KV cache is shifting things around it may be slowed down resulting in memory creep during that process, in which case the model is likely going to be killed by the interactivity timer.

6) Batch size helps with the prompt processing speeds, but too high of a batch size holds the GPU up for longer durations during the prefill. This again in turn increases the risk of the interactivity watchdog killing the model. If you have proper thermal control, you can get away with a batch size of 2048, for example - but I'd really recommend based on my experience thus far not to exceed 512. I noticed that with 2048, I got much much much faster prompt processing times, like single-digit seconds processing times. However, not only did the thermal throttling start kicking in much faster, but the logic seemed to get dumber. It looped more with a higher batch size for some reason. My current sweet spot is 512.

7) Do NOT use Ollama. I had horrific shit performance with ollama. Seriously, I was about to give up on local models entirely because of it. Also, don't try to use vLLM - the metal backend is extremely experimental and it doesn't work well at all. (Works amazing if you're running on NVidia, though!). Use LM Studio of llama.cpp directly if you're running on mac! Also, the beauty of LM Studio is you can use it for its gorgeous and easy to navigate UI to quickly download models, and they're in a format you can just point anything else at to run. Ollama does this chunk storing that feels like container layers, and you can't just point llama.cpp or vLLM at the models, you'll have to re-download them.