I'll have to admit I was sceptical about the 30B benchmarks but after testing it over the weekend I'll have to admit it's pretty good. It needs more help in architecture related questions but for coding well defined tasks (for me primarily python) it's on par with the commercial models.
I took the time to build an agent from scratch in rust, copying a lot of ideas from claude code, and using Qwen3 Coder 30B - 3.3B does really well with it. Replicating the str_replace / text editor tools, bash tool, and todo list and a bit of prompting engineering goes really far.
I didn't do anything fancy and found it to do much better than the experience I had with codex cli and similar quality to Claude Code if I used sonnet or opus.
Honestly the cli stuff was the hardest part but I chose not to use something like crossterm.
How have you found the current experience of (async) networking in Rust? This is something which is stupidly easy out-of-the-box in Python -- semi-seriously, async/await in Python was _made_ for interacting w/ a chat completions/messages API.
(As an aside, my "ideal" language mix would be a pairing of Rust with Python, though the PyO3 interface could be improved.)
Would also love to learn more about your Rust agent + Qwen3!
I just ran a test giving the same prompt to claude, gemini, grok and qwen3 coder running locally. Qwen did great by last years standards, and was very useful in building out boilerplate code. That being said, if you looked at the code side by side with cloud hosted models, I don't think anyone would pick Qwen.
If you have 32gb of memory you are not using, it is worth running for small tasks. Otherwise, I would stick with a cloud hosted model.
At 4 bit quantization the weights only take half the RAM. You need a good chunk for context as well, but in my limited testing Qwen3-30B rand well on a single RTX 3090 (24GB VRAM).
This person keeps banging the drum of agents running on untrusted inputs doing unexpected things. The proof of concept doesn't prove anything and doesn't even have working code. It's not clear why this is classed as a markdown rendering bug when it appears cline is calling out to a remote server with the contents of an env file as parameters in a url.
edit: are you the author? You seem to post a lot from that blog and the blog author's other accounts.
Open-weights models are catching up and are now viable for many tasks.
Keep in mind that closed, proprietary models:
1) Use your data internally for training, analytics, and more - because "the data is the moat"
2) Are out of your control - one day something might work, another day it might fail because of a model update, a new "internal" system prompt, or a new guardrail that just simply blocks your task
4) Are built on the "biggest intellectual property theft" of this century, so they should be open and free ;-)
12 comments
[ 2.6 ms ] story [ 31.2 ms ] thread"What you need" only includes software requirements.
I didn't do anything fancy and found it to do much better than the experience I had with codex cli and similar quality to Claude Code if I used sonnet or opus.
Honestly the cli stuff was the hardest part but I chose not to use something like crossterm.
(As an aside, my "ideal" language mix would be a pairing of Rust with Python, though the PyO3 interface could be improved.)
Would also love to learn more about your Rust agent + Qwen3!
If you have 32gb of memory you are not using, it is worth running for small tasks. Otherwise, I would stick with a cloud hosted model.
Begs the question of long-term support, etc...
edit: are you the author? You seem to post a lot from that blog and the blog author's other accounts.
Keep in mind that closed, proprietary models:
1) Use your data internally for training, analytics, and more - because "the data is the moat"
2) Are out of your control - one day something might work, another day it might fail because of a model update, a new "internal" system prompt, or a new guardrail that just simply blocks your task
4) Are built on the "biggest intellectual property theft" of this century, so they should be open and free ;-)