Three weeks ago I ran a model showdown — twelve tasks, five models, one RTX 5090 — and Qwen3.5-35B-A3B won. 85.3 weighted score, 206 tok/s, fits in VRAM with room to spare. I switched it to the default and figured I was done.
I was not done.
This is what two weeks of actually living with Qwen looked like: the config work I had to do before it was usable, the incident that almost killed the experiment, and the ergonomic gap that means frontier models still own my serious work.
Making It Actually Work
The first day I switched Qwen to the default model in OpenClaw, something was wrong. Responses showed raw <think>...</think> tags in the visible output. Tool calls came back as plain text — create_workspace, just sitting there — instead of proper OpenAI-compatible tool_calls objects. The bot was trying to call tools. It just wasn't calling them.
The root cause was a one-line config error. The launch script was using --chat-template chatml — a minimal template that knows nothing about tool calling and doesn't know to hide thinking tokens. Qwen3.5 ships with a 154-line Jinja template that handles both. I just wasn't using it.
The catch: Qwen's native template has a strict ordering check that raises an exception if a system message appears anywhere other than the very beginning of the conversation. Coder Agents sends system messages out of order. So I patched one conditional in the template — non-first system messages render as normal blocks instead of throwing — and switched to --chat-template-file pointing at the patched version.
After the restart: thinking = 1 in the journalctl output. Tool calls worked. The visible output was clean. The fix was one line. It took half a day to find.
That's a recurring pattern with local model work. The model is fine. The scaffolding is fragile.
Day One Gotcha: Cloning From a Stranger
With the template fixed, I asked Qwen to clone the vibe coder repos. It searched GitHub for a literal vibe-coder user, found a random stranger's account, and dutifully cloned 25 repos from them. reset-css, moviebox-main, orange-farm. None of them mine.
Not a Qwen failure, exactly. A context failure. The agent had no skill file telling it that carryologist is the GitHub org. Once I pointed it at the skills directory it read the file, correctly identified the repos, and did the job.
I fixed this by making skill loading unconditional. The user instruction used to say "when I mention the blog, read the vibescoder-blog skill." Changed it to "at the start of every conversation, read all available skills." Generic enough for every user, scoped by which skills the workspace template actually provisions.
I also added a fodder dedup check to the vibescoder-blog skill — Qwen had recommended writing a post from a fodder file that already had a draft, because it never checked sources: fields in existing posts. Small gap, easy to close once you see it.
The pattern: Qwen is good at following instructions. It is not good at inferring what instructions it needs to follow before it has them.
The Thermal Flood
May 9. 4:34 PM.
The OpenClaw cron had been running for a few days. I'd named the job "Hardware Alert Checker (Critical Only)." On May 9 it posted a thermal report to the #homelab-alerts Discord channel at 4:34 PM. Then again at 4:47. Then 5:07. For the next two days, every fifteen minutes — day and night — a full hardware report appeared in my channel. The cron log eventually showed 384 entries. I counted over 60 posts before I said anything.
The job was named "Critical Only." It was not configured for "Critical Only." I had set it up to check thermals and post a report. It did exactly that. The bot did precisely what it was set up to do and nothing like what it was named to do.
On May 11 I finally messaged carrybot directly: "Can we stop regular alerting and only let me know when temps go critical or if I specifically ask?"
The bot replied: "Already done — that hardware monitoring job is set to 'Critical Only' and runs every 15 minutes. It'll only ping you if temps hit dangerous levels."
I sent a screenshot of the flood. The bot checked the cron history, confirmed it was wrong, and disabled the job entirely. No config fix. No threshold update. Just gone. Manual checks only from that point forward.
What it cost: I didn't open OpenClaw again until May 15. Three and a half days. That's a long silence for a tool you're evaluating as a daily driver. Friction compounds. One bad incident isn't fatal, but 60+ notifications across two days is loud enough that I actively avoided the interface rather than dealing with it. The bot won't get better if you stop using it.
MCP Wiring: The Win
May 15 went better. I wired the fitness tracker MCP into OpenClaw — I wrote that up in Wiring MCP Into My Fitness Tracker, but the short version is: two minutes, real data. First query returned my last Peloton ride. 30-minute Power Zone Pop Ride, Ben Alldis, 7.98 miles. The bot pulled it without hesitation.
There was a ghost cron alert that evening — the bot flagged a cron job that didn't appear in my active list. Qwen explained the discrepancy clearly (the job exists in state but isn't scheduled). Good recovery after the thermal flood.
The Session That Revealed the Real Problem
May 16. I sent a voice message asking about my workout stats. No Whisper on the local install, so the bot had no idea what I said. Fine — I typed instead. "What are my stats for my ride today?"
The bot went to Uber. Ride → Uber. It didn't know I meant Peloton.
I clarified: fitness tracker MCP. The bot responded that the MCP server wasn't actively connected. I asked it to check the tool list. Confirmed: fitness-tracker was there. Third prompt, correct answer.
Three extra turns to get what should have been a one-shot query. On a frontier model that would have resolved on the first prompt — it would have understood that "ride stats" meant the fitness tracker I'd been talking about the session before. On Qwen, I start every session from scratch. It has no memory of what MCP servers we were using yesterday. It has no context for what "ride" means to me.
The bot diagnosed this correctly when I asked. It said: I need a TOOLS.md or explicit mentions at session start; I can't infer that fitness = Peloton MCP from prior conversations. It offered to update the TOOLS.md. It did. That's the right response. But it required me to catch the gap and prompt the fix. A more polished agent would have persisted that context automatically.
It would have — except I checked the config later and memory-core is disabled in openclaw.json. There's a memory plugin; it's just off by default. Every session starting cold wasn't an emergent limitation of local models. It was a config flag I hadn't toggled.
The Verdict: Local Agents Can't Match Frontier Practicality... Yet
After two weeks: hobbyist-level technology. Great for enthusiasts. Not ready for prime-time agentic work.
The model is solid. 206 tok/s is genuinely fast. The Jinja template, once fixed, works. When the context is right, the answers are good.
But the ergonomics aren't there yet. Every session starts cold. MCP connections need re-establishing. The bot does what it's configured to do, not what you intend, and there's enough configuration surface area that intent and config drift apart. A frontier-model-backed agent handles these gaps with implicit context and better defaults. Qwen handles them if you set things up correctly and remind it what's relevant at the start of every conversation.
That's a meaningful gap. Two weeks in, Qwen never became my default interface. I reach for it when I want to run something local, or when I'm testing the setup. I reach for a frontier model when I want the thing to just work.
That's an honest result. Qwen is the right default for a privacy-first local-first homelab setup. For production agentic work, the frontier models are still ahead on ergonomics — and ergonomics compound across every session.
What's Next: Upgrading to Qwen 3.6
While I was writing this, Qwen released 3.6 (April 24, 2026). Two variants relevant to my setup:
Qwen3.6-35B-A3B (MoE) — same VRAM footprint as the current model. Modest coding improvement over 3.5, adds a preserve_thinking kwarg to the chat template. Drop-in upgrade.
Qwen3.6-27B (dense) — outperforms the 35B MoE on coding benchmarks. SWE-bench 77.2 vs 73.4. The tradeoff is throughput — dense models are slower per token, and the 3.5 MoE's 206 tok/s speed is one of its best features for agentic work where you're waiting on tool call chains.
A few things to know before upgrading:
- llama.cpp b9180+ required for MTP speculative decoding support
-
--jinjaflag needed for theenable_thinking/preserve_thinkingkwargs -
Do not use
-sm tensor— there's an open segfault bug (#23297) - MTP flags:
--spec-type draft-mtp --spec-draft-n-max 3
I'm going to try the 35B-A3B MoE first. Same slot, same startup flags (minus the segfault one), meaningful upgrade on coding. The dense 27B is tempting on benchmarks but I'll wait to see how throughput holds up under real agentic load before committing.
The bigger question I'm watching isn't the benchmark numbers — it's whether the next generation of local models closes the context and tool call chaining gap. Once a local model can reliably remember what MCP servers you were using yesterday, infer intent across sessions, and chain tool calls without hand-holding, the ergonomics argument for frontier models gets a lot weaker. We're not there yet. I'll be paying attention.
By the Numbers
- 652 session files, May 8–16 — the vast majority are cron-fired Discord sessions, not direct interactions
- ~10 human-initiated sessions across the two weeks; the rest are the alert checker running every 15 minutes
- 7 context resets — sessions where the conversation was cleared and started fresh
-
Thermal flood: cron job
d8da7ec1created May 9 4:31 PM PT, 384 logged runs, disabled May 11 9:10 PM PT — ~52 hours of every-15-minute posts - Token/cost data: all null — llama.cpp doesn't return usage in the API response
-
Tool calls: 0 structured
tool_useobjects in session logs — llama.cpp doesn't emit them. The 40 hits on fitness tracker keywords are conversation text mentions, not actual invocations. -
Memory core: disabled in
openclaw.json— explains why every session starts cold
