I gave Qwen 3.6 a real coding task on my RTX 5080, and now I barely open Claude

Published Aug 8, 2026, 6:00 AM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. My previous experience with running local AI models taught me to keep my expectations modest. I'd mostly deferred to them for simple stuff that I didn't want to send to the cloud: autocomplete in VS Code, boilerplate generation, and easy tasks that are hard to screw up. For a while, I thought that was about as good as it gets for running AI at home. A coding task I recently handed off to Qwen3.6 challenged my assumption that local AI wasn't suited to more complex jobs. I was asking for a Python script, which I'd normally prompt Claude to tackle, but wanted to see how the new coding model would handle it. A robust script came back in just over three minutes, and that's on an RTX 5080, a Ryzen 7 9800X3D, and 32GB of RAM. I'm sure Claude would have delivered it faster, but a little waiting was worth it to keep nothing from leaving my machine or my wallet. How can a 16GB card run a 35B model? Sparse models changed the math for consumer hardware Qwen3.6 came out in April in two variants, 27B and 35B-A3B, both under an Apache 2.0 license, and featuring a 256K context window. 35B is a Mixture of Experts model, which means that although it has 35 billion parameters in total, only about 3 billion of them activate for any given token, while the rest sit idle. And that's exactly why the model can work on my card. The model's download size is roughly 24GB, yet my 5080 has only 16GB of VRAM to fit it. Getting it up and running only took me a few minutes, not counting the time I spent waiting for the download to complete. All I did was open PowerShell, install Ollama, pull the model, and set two parameters to optimize performance: winget install ollama ollama pull qwen3.6:35b ollama run qwen3.6:35b --verbose /set parameter num_ctx 65536 /set parameter temperature 0.6 There's a lot more configuration you could do to optimize this model for any particular system, but this is the route I took to get things set up quickly and easily. The first parameter setting is an increased context window, because Ollama's is too small for a task that produces a few hundred lines of code. The other setting comes directly from Qwen as the recommended one for precise coding work. From there, Ollama handles everything else. Generation ran at 68.93 tokens per second, which surprised me because it's faster than I've gotten out of some other models half this size. I was keeping an eye on Task Manager to see how much the coding task bogged down my system: About 11GB sat in my system RAM, my CPU hovered around 50% usage, and GPU usage stayed at about 30% the entire time. Since I'm running an MoE model, the GPU spends a lot of time waiting for expert weights to be loaded from RAM, which is why usage stayed pretty low. Without a doubt, my 9800X3D and DDR5 made things run a lot faster, and anyone on an older system would notice a much slower result. The task I'd normally hand off to Claude A file organizer is a good test for gauging performance I asked for a Python script that organizes a messy directory of files. I wanted it to sort files into subfolders by type, group them by the year they were last modified, run a checksum comparison to catch duplicates, and put those duplicates into their own folder. On top of that, I requested a --dry-run flag that prints every intended move without touching anything, automatic renaming when a filename already exists at the destination, skipping files already in the right place, and a summary of moves, skips, and errors at the end. Some of that is trivial, like sorting by file type. The more complex requirements, like checksum comparisons, collision handling, and skip logic, are where I'd expect a lighter model to come up short, and I probably wouldn't find out the script doesn't work until I go to test it, since the model usually lies about its success. Qwen3.6 produced 10,785 tokens of output in about two and a half minutes, but a decent chunk of that was the model reasoning through the problem before writing any code, since it's a hybrid thinking model. I was happy to find that the script worked exactly as I'd requested, without needing any further back-and-forth. The real run matched the dry run, and sorted everything correctly. It also caught the identical copies I'd planted and renamed files as needed instead of overwriting them. When I ran it a second time on the already-organized folder, the script did nothing, which is exactly what it should do. Every requirement made it into the script on the first attempt. Qwen3.6 writes fast and reads slow Feeding it a codebase is a different experience The 10.4 tokens-per-second prefill rate I got in my test is the real limitation. My prompt was only 198 tokens, so handing the model a 20,000-token codebase would've left me waiting a good half hour for the response to even start. Short prompts that don't require the model to understand any pre-existing code will yield far better results. For a prompt about a project that spans an entire repository, I'd still consult Claude if I need an answer within a few minutes. When I look at what I typically send Claude, most of it is stuff that Qwen 3.6 could handle. It's especially good for single-file utilities and one-off scripts that have clear requirements, which is exactly what my test showcased. Local models won't beat cloud models outright. But there's definitely a good percentage of my work that can now go to a local model instead of Claude, and it's a much higher share than last year. Local models are gradually catching up A year ago, this same prompt would've gotten me something half-usable, and I would've ended up using Claude to help me fix it. Now it gets me a script that runs correctly the first time, and it all works on my gaming GPU. The heavy stuff still goes to Claude, and that probably won't change anytime soon. Nevertheless, I'm reaching for it a lot less than I used to.