Qwen3.8-27B as a Local Claude Code Replacement (2026)

Four months ago we asked whether an open 27B could replace Claude Code locally, and the answer was a qualified no: Qwen3.6-27B was a capable supervised coder, but its tool-call reliability and long-context drift meant you gated every action and kept Claude as the architect. On August 14, Alibaba shipped Qwen3.8-27B — same size, same Apache 2.0 license, same 262K context — and the question deserves a full re-hearing. The weights pulled 1,400+ points on Hacker News, Unsloth's GGUF repo alone has crossed 2.7 million downloads, and this time the model arrives with benchmark rows where it beats the Claude it's compared against.

This is the honest re-examination, not the victory lap: what changed, how to wire it in, which benchmark wins survive scrutiny, the new bottleneck nobody headlines — latency — and where the hybrid line sits now.

What changed since Qwen3.6?

Here's the strangest fact about Qwen3.8-27B: architecturally, it is the same model as Qwen3.6-27B. The config files are identical — same 64 layers, same hidden dimension, same hybrid Gated DeltaNet + attention layout, same 262,144-token native context, same built-in vision encoder. Every gain came from post-training: reinforcement learning in agentic environments plus on-policy distillation. That's why llama.cpp and Ollama supported it on day one.

And the gains are not subtle. On Artificial Analysis's independent Intelligence Index, Qwen3.6-27B scored 38; Qwen3.8-27B scores 52 — a 14-point jump at identical parameter count, putting it level with GLM 5.2, GPT-5.6 Luna, and DeepSeek V4 Flash, and ahead of every open model in the 40B–150B range. For a 17GB download, that's a genuinely new situation.

Three specific changes matter for the Claude Code use case:

• Agentic post-training that shows up on agentic benchmarks. Terminal-Bench 2.1 went from 63.4 to 73.0 generation-over-generation. The 3.6 post's core complaint — malformed tool calls stalling autonomous loops — is precisely the axis this release targeted.
• Usable vision in the loop. The 3.6 had a vision encoder; the 3.8 has vision scores: 84.3 on OSWorld-Verified and 81.9 on AndroidWorld (against Opus 4.6 Max's 72.7 and 62.0 on the same card). A local agent that can read its own screenshots — verify the UI it just built, drive a browser, debug a rendering bug from a PNG — was simply not a thing you could do well on local weights before.
• New control surfaces. A reasoning_effort setting (xhigh / medium / low), a preserve_thinking flag that carries reasoning context across turns, and a trained multi-token-prediction (MTP) head for speculative decoding. All three turn out to be load-bearing for agent work, as we'll see.

How do you wire Qwen3.8 into Claude Code?

There are now three distinct paths, and the middle one didn't exist in the 3.6 era.

1. Ollama's first-party launcher (fully local). This is the two-liner:

ollama run qwen3.8   # pulls the 18GB q4_K_M default, 256K ctx, text+image
ollama launch claude --model qwen3.8

That second command starts the actual Claude Code harness backed by your local model. Ollama documents parallel launchers for OpenCode, Hermes, and OpenClaw on the same library page, so you're not locked into Anthropic's front-end.

2. QwenCloud's Anthropic-protocol endpoint (hosted halfway house). Qwen's cloud now speaks the Anthropic API protocol directly, which means Claude Code can point at hosted Qwen3.8 with no local hardware at all. The Token Plan subscriptions run $6, $18, or $68 per month (credits reset weekly), and the harness list explicitly includes Claude Code, Codex, Cline, Cursor, and OpenCode. If your motivation is cost rather than data locality, price this first — it's an order of magnitude cheaper than a Claude Max plan and skips the hardware question entirely. The tradeoff: your code goes to Alibaba's cloud instead of Anthropic's, which solves the subscription problem but not the privacy one.

3. A server you control + any harness. llama.cpp's llama-server, vLLM, or LM Studio exposing an endpoint, with OpenCode, Pi, or Cursor's local agent mode on top. This is where the serious field reports come from — a 16GB RTX 5060 Ti running a two-hour autonomous NestJS build through OpenCode, and Simon Willison driving the Pi coding agent through LM Studio. More work, more control, and the only path where the speed fixes below are fully available. Our guide to running Qwen3.8 locally covers the full setup matrix, quant table included.

How real are the benchmark wins?

The headline claim circulating on launch day was "an open 27B beats Claude Opus at coding." Our house policy is to grade that kind of claim by provenance, so here is the card, with grades. Note the comparator: Claude Opus 4.6 Max — a current-generation but not frontier Claude (Opus 5 is the frontier as of August). Every row below understates the gap to the newest Claude, exactly as the 3.6 card did against its Opus.

The honest read: across the card's twelve text rows, Qwen3.8-27B beats Opus 4.6 Max on five and loses the two that matter most for autonomous agent work — Terminal-Bench and NL2Repo. The SWE-bench Pro headline is the weakest link in the chain, and it's the one that went viral. Meanwhile the independently-verified story is arguably better than the headline: a 14-point Intelligence Index jump at constant size, with Artificial Analysis also noting the model has a strong "knows what it doesn't know" profile — weaker world knowledge than 3.6, but disciplined about not hallucinating around the gaps. That's the shape you want in a coding executor. Full benchmark tables and architecture detail live in our Qwen3.8-27B complete guide.

Why is latency the new problem?

The 3.6 post's villain was tool-call reliability. The 3.8's villain is time. Two compounding causes:

Cause one: the model overthinks by default. Qwen3.8-27B ships with reasoning_effort set to xhigh, and the results on consumer hardware are comical in the wrong way. Simon Willison's pelican-SVG test took 21 minutes and 22,276 reasoning tokens at the default setting; asked to "draw an SVG of a circle," the model delivered an unrequested animated geometric study. A corroborating M4 Pro report clocked an SVG owl at 17 minutes. In a chat window that's a quirk; in an agent loop it's fatal. Claude Code round-trips to the model dozens of times per task, and a model that meditates for minutes per turn is a broken agent, whatever its benchmarks say.

Cause two: it's token-hungry even when it isn't stuck. Artificial Analysis measured roughly 2× the tokens per completed task versus Qwen3.6 and 2.3× versus GPT-5.6 Luna Max. That's the under-reported number in every "27B matches the big models" post: it matches them partly by spending more inference.

Both problems have real fixes:

• Turn the effort down. Set reasoning_effort to medium (which is actually the model's native default — the effort levels are post-trained system-prompt sentences, and medium injects nothing) or low, and cap runaway thinking with a reasoning budget around 5,000 tokens. This was Willison's own recommendation, and it's the single highest-value config line for agent use. Keep preserve_thinking on so the reasoning the model does do carries across turns instead of being re-derived.
• Use MTP speculative decoding. The trained multi-token-prediction head is the throughput lever the 3.6 never had. Georgi Gerganov's llama.cpp invocation with the MTP draft head measured about +72% throughput over an untuned LM Studio setup; a 24GB-card deep dive sustained 50.4 t/s at a full 256K context window.
• Raise LM Studio's context. Its 8,192-token default gets consumed entirely by thinking before the answer starts. Set the full 262,144.

What throughput to expect, from crowd-sourced reports rather than vendor claims:

The dense-model physics from the 3.6 article still applies: this is a memory-bandwidth-bound 27B, "17GB fits" is not the same as "usable," and for agent work you want to be north of ~30 t/s before the loop feels alive. One update to the old advice, though: the 3.6-era "Q8 or nothing" quant floor has softened. Unsloth's dynamic quants show only 0–5% eval degradation down to UD-Q3-class, and the most impressive field report of the launch week ran on a Q3 (next section). The skeptics' counterpoint — "I don't trust a q3" — is on the record too.

What are people actually reporting?

Both directions, as always. The positive reports are more concrete than the 3.6 wave's:

• A production deployment on NVFP4 quants under vLLM reporting 99% agent-task completion — the kind of tool-call reliability number the 3.6 simply never earned (the old anecdotal figure was a 12% JSON format-error rate).
• A heavily-upvoted RTX 5090 owner: "I don't need Claude for 80%+ of my work anymore."
• The 16GB configuration that made the rounds: an RTX 5060 Ti running a UD-Q3_K_XL quant with MTP speculative decoding at ~46 t/s, driving a two-hour, million-token autonomous NestJS + MCP build through OpenCode — three prompts, no babysitting. That workload was science fiction for 16GB cards six months ago.
• Willison's overall verdict: the model drove the Pi coding agent well, the vision bounding-box work was "such a good match," and "the only thing holding this back from being a daily driver is performance."

The skeptics' case deserves airtime too, because Qwen has earned its benchmaxxing reputation. The recurring Hacker News objection: "they do not beat Opus on real-world usage — number goes up on a benchmark isn't it." And the overthinking failure mode produces genuine doom loops — agents reasoning themselves into elaborate solutions to problems nobody posed, like that animated circle. But the complaints cluster around default settings (xhigh effort, tiny contexts, no MTP), while the strongest positive reports all come from tuned setups. As with 3.6, configuration is usually why two engineers running "the same model" reach opposite conclusions.

Verdict: the hybrid line has moved

Can Qwen3.8-27B replace Claude Code outright? Against the current frontier — Opus 5, not the Opus 4.6 Max on the model card — still no. Claude keeps a real edge on terminal-driven autonomy, repo-scale reasoning under anti-gaming conditions, and hard novel problems, and it does everything faster with none of the tuning tax.

But the hybrid split we recommended in April needs redrawing. Then, the local model was a supervised reasoning layer: run plans through it, gate every tool call. Now, a tuned Qwen3.8-27B — effort on medium, reasoning budget set, MTP enabled, decent GPU — is a legitimate execution layer for well-scoped work. Route locally: implementation of planned features, test-fixing loops, refactors, frontend work with screenshot self-verification (the genuinely new capability), and anything touching code you can't send to a cloud. Keep on Claude: architecture and ambiguous specs, long unattended multi-hour runs, and the debugging sessions where a wrong answer costs you an afternoon. If you're building toward the fully self-hosted end state, our self-hosted AI coding agent guide maps that stack end to end.

The cost math stays simple, so we'll keep it light. A Claude Max plan runs ~$100+/month; electricity for a 4090-class card working hard a few hours a day is a few dollars a month, and the hardware pays back in roughly a year if you were buying a capable machine anyway. The new wrinkle is QwenCloud's $6–68/month Token Plans sitting in the middle: hosted Qwen3.8 through the Anthropic protocol costs less than the electricity argument even bothers to fight about, at the price of shipping your code to a different cloud. Pick your constraint — privacy points local, pure cost points to the Token Plan, capability still points to Claude.

FAQ

Can Qwen3.8-27B fully replace Claude Code?

Not against the current frontier. Claude still wins terminal-driven autonomy (Terminal-Bench 78.2 vs 73.0 even against the older Opus 4.6 Max) and is far faster per task. But a tuned local 3.8 can now genuinely execute well-scoped coding work unsupervised, which moves the hybrid split heavily toward local for routine volume.

Does Qwen3.8-27B really beat Claude on SWE-bench Pro?

The score is real (61.7 vs 53.4) but the comparison is compromised: Qwen re-ran its own model on a "refined" version of the benchmark while quoting Opus 4.6 Max's official number from the standard set. The independently-verified signal is stronger — Artificial Analysis scored it 52 on its Intelligence Index, up 14 points from Qwen3.6-27B at identical architecture.

How do I stop Qwen3.8 from overthinking?

Set reasoning_effort to medium or low — the xhigh default produced a 21-minute, 22,276-token think for a single SVG in Simon Willison's testing — and cap it with a reasoning budget around 5,000 tokens. Keep preserve_thinking enabled so reasoning carries across agent turns instead of being redone. Reasoning does earn its keep on complex tool-building, so don't zero it out entirely.

What hardware do I need for a usable Claude Code loop?

A single 24GB GPU (3090/4090) is the practical floor for a pleasant loop: ~39–48 t/s stock, 60–80 t/s with MTP speculative decoding enabled. A well-tuned 16GB card works with a Q3-class quant and reduced context. Macs and DGX Spark run it at 15–30 t/s — workable, not snappy. Anything bandwidth-starved (thin laptops, CPU-only) fits the 17GB file but is unusable for agent work.

Is there a middle option between local and a Claude subscription?

Yes, and it's new: QwenCloud speaks the Anthropic API protocol, so Claude Code can run against hosted Qwen3.8 on Token Plan subscriptions at $6, $18, or $68/month with weekly-resetting credits. You lose the data-locality argument but keep the harness and most of the cost savings, with zero hardware requirements.

Did the tool-call reliability problem from Qwen3.6 get fixed?

Largely, by the evidence available. There's no independent format-error measurement yet, but the agentic post-training shows up everywhere it should: Terminal-Bench jumped 9.6 points generation-over-generation, and a production deployment on vLLM reports 99% agent-task completion — against the ~12% tool-call error rate anecdotally reported for 3.6. Supervision is still wise on long runs; gating every single call no longer looks necessary.