跪拜 Guibai
← Back to the summary

Alibaba's Qwen3.8-27B Brings Claude Opus-Class Coding to a Local Machine

Recently, I've noticed that while I've subscribed to more and more token plans, tokens seem increasingly insufficient.

I'm not sure if it's because I have more projects or if the token quotas from major providers have shrunk.

Anyway, I've spent no less money, but my token anxiety has only grown.

Until a few days ago, Alibaba released Qwen3.8-27B. Its official benchmarks directly challenge Claude Opus 4.6, and almost all of them were run on Claude Code. It's open-source, free to download, and costs nothing.

The hype is also massive. Within 48 hours of release, it topped the Hugging Face trending chart, hit number one on Hacker News the same day, and surpassed 10,000 downloads on LM Studio within 38 minutes of going live. On Ollama alone, it reached 360,000 downloads in 5 days. The coding tool Cline announced that just 4 days after launch, it became the most selected local model among Cline developers. CNBC and The Information also ran dedicated reports.

Hugging Face trending chart, Qwen3.8-27B ranked first

Ollama, vLLM, and SGLang all had day-0 support. Even Cloudflare immediately added it to its Workers AI model library, and AMD officially released a deployment tutorial for Ryzen AI Max. This level of reception is something I've rarely seen for an open-source model this year.

This piqued my interest, so I simply installed it on my Mac to test firsthand whether it's as good as the online reviews claim.

1. First, let's clarify what it is

Qwen3.8-27B is a 27-billion-parameter dense model. What does that mean? For every token it generates, all 27 billion parameters are activated, unlike some models that only dispatch a small team. It's open-source under the Apache 2.0 license; the weights are freely downloadable, and commercial use is free. The official tagline for this generation is 'A New Bar for Coding and Cowork,' focusing primarily on programming and office collaboration.

It also has a big brother, Qwen3.8-2.4T-A95B, with 2.4 trillion parameters, whose weights were also released this time. This is the first time Qwen has open-weighted a Max-level model. However, the open-weight version of the 2.4T model is text-only, without vision, and at that scale, ordinary people simply can't run it. The 27B is the one you can actually bring home.

It's natively multimodal, capable of understanding images and videos. The official line is that it can even comprehend hour-long videos. Note that it's about understanding, not generation; those hoping it can draw pictures can leave now.

Running bounding box detection locally, framing the pelicans in the photo

For example, in the image above, the model is asked to frame each pelican in the photo one by one, and it does so quite accurately. This capability is very valuable in agent workflows—image recognition, document reading, and writing code from screenshots are all applicable.

The native context length is 262K. Officially, a technique called YaRN can extend this to 1M. You can think of it this way: 262K is the original calibrated range from training, while 1M is like forcibly splicing an estimated scale onto the end of the ruler. It can measure, but the precision hasn't been calibrated. So, 1M is currently just a theoretical figure; in practice, what everyone achieves is 262K.

2. Why everyone is calling it the 'Local Opus 4.6'

Anyone who used Opus 4.6 at launch can empathize with its experience and cliff-like lead. So now, whenever a new model emerges in the community, the first reaction is to compare it to Opus 4.6; it's the yardstick.

The scores on the official model card are indeed frightening. But let's be clear upfront: these are all scores run by the official team themselves, so take them with a grain of salt first.

Qwen3.8-27B official text benchmark table

SWE-bench Pro 61.7, with the reference point next to it being Claude Opus 4.6 Max at 53.4. Terminal Bench 73.0, LiveCodeBench 90.3. The official line on the multimodal side isn't weak either: computer operation OSWorld-Verified 84.3, document understanding OmniDocBench 91.1. The official claim is that its overall capability surpasses its own previous-generation paid model, Qwen3.7-Plus.

Paper specs look good, but what's the actual experience? The community's consensus from testing over the past few days is fairly consistent: for daily programming and agent tasks, the gap with cloud flagships has narrowed to the point where you have to deliberately look for it to notice; for truly complex long-reasoning tasks, the cloud is still more stable. From my own testing, the model's capability is indeed decent—Chinese writing and basic programming are completely fine—but it's just slow, incomparable to cloud APIs. In a real project, waiting time is also a cost.

Third-party leaderboards are also out. Artificial Analysis's Agentic Index just included it, scoring 51 points, ranking 7th.

Artificial Analysis Agentic Index leaderboard, Qwen3.8 27B ranked 7th with 51 points

What does a score of 51 mean? It's a huge jump from the previous generation Qwen3.6-27B's 28 points, and it also surpasses DeepSeek V4 Pro and GPT-5.6 Luna. But ahead of it still stand Claude Opus 5, GLM-5.3, and Grok 4.6, all at 59 points. So the accurate statement is that a local model has squeezed into the first tier of this leaderboard for the first time, but it's still far from 'beating all closed-source flagships.'

Another third-party benchmark specifically for complex agent tasks, Agents' Last Exam, has also released scores. The 27B achieved 42.9%, retaining over 80% of the level of its own flagship Qwen3.8-Max, surpassing GLM-5.2 and Seed 2.1 Pro.

Agents' Last Exam leaderboard, Qwen3.8-27B scored 42.9%

Notice what's marked under the 27B column on this chart: Claude Code. Again, Claude Code. I'll elaborate on this point in Section 5.

3. How the 27B fits into a personal computer

This is the part I find most worth discussing.

Traditional dense models use full attention in every layer. What does that mean? You can think of it as the model keeping a ledger entry for every token it reads; the longer the context, the thicker the ledger. This ledger is called the KV cache. Many models can't run long contexts not because the model itself doesn't fit, but because the ledger explodes first.

Qwen3.8-27B played a ruthless trick. Out of 64 layers, only 16 use full attention. The remaining 48 layers use a linear attention mechanism called Gated DeltaNet, which only retains a fixed-size state. It's like others keep every transaction record, while it only remembers the balance.

The effect is that the KV cache is only about a quarter of that of a traditional model of the same size. A 27B frame carrying a 262K context relies on this.

Additionally, it has built-in MTP (Multi-Token Prediction), predicting multiple tokens at once. You can think of it as having a built-in draft writer; it drafts first and then confirms, gaining a speed boost for free.

4. What kind of computer can run it

Here's the bottom line:

Mentally prepare for the speed, but don't be too pessimistic. Here are some community-tested anchor points: M4 Max running MLX 4-bit gets about 23 tok/s; M5 Max running optimized 4-bit with MTP can reach 50-60 tok/s; an RTX 5090 with MTP enabled can even surge to 90-120 tok/s. Entry-level Macs will be slower, sufficient for chat but feeling slow for long tasks.

A key variable here is MTP. The speed difference with it on or off is nearly double. On the same version tested on an RTX 5090, it jumped from 66 tok/s to 121 tok/s. The cost is that MTP consumes more VRAM, compressing the usable context. So, if you see someone reporting a very high speed, first ask if they had MTP enabled.

I myself use an M5 Max with 128GB of memory, running the 4-bit version on Ollama. My tests show about 25 tok/s, sufficient for chat and general tasks, but long tasks require patience. Memory is absolutely not an issue; it's enough to run the full 262K context.

Some might ask, how to choose between 4-bit and 8-bit? In one sentence: if you have enough memory, go 8-bit; if you find it slow, go 4-bit. 4-bit is nearly twice as fast, and the quality loss is imperceptible in daily chat, but it might occasionally falter in long reasoning tasks.

5. Paired with Claude Code, it's the complete form

This is the point I value most.

You should know that Qwen has its own official coding tools, Qwen Code and Qoder CLI, both its own children. But as mentioned at the beginning, the official benchmarks were almost all run using Claude Code. This is essentially the official team telling you who the best partner for this model is.

Integration is also simple, with native support from Ollama:

ollama pull qwen3.8:27b-mlx
ollama launch claude --model qwen3.8:27b-mlx

Ollama official model page, Applications list has Claude Code on the first line

On Ollama's official model page, the first line of the Applications list is Claude Code. Not every model gets this treatment.

Two commands, and Claude Code's backend is switched to a local model. Now, with Claude Code connected to a local model, there's absolutely no worry about account bans, no API fees, no quota anxiety. Agents can run freely, tokens can be burned freely, and the code never leaves your own home. This is what I call token freedom.

For companies where code cannot leave the internal network, this is basically the most worthwhile solution to evaluate right now.

A key experiential point upfront: when connecting it to an agent like Claude Code, what determines fluency isn't the generation speed, but the 'file-loading' speed. What does that mean? Every time the agent does a round of work, it has to re-read all previous chat history, tool results, and code snippets from beginning to end before starting. The more rounds there are, the thicker the material to re-read becomes. Short tasks chat smoothly, but after the context piles up to tens of thousands of words, the wait before each round starts becomes noticeably longer. So, when using it as a CC backend, memory bandwidth is more valuable than the tok/s number. My long-term experience after integrating it—I'll supplement this after running it for a while longer.

6. A splash of cold water

In the first week of a new model's release, take all the praise with a grain of salt. After using this model, I've already accumulated several points of dissatisfaction.

Foreign developer Simon Willison's real-world test can serve as corroboration. The default xhigh reasoning setting over-thinks madly. Asked to draw an SVG circle, it could ponder for ages on questions like 'whether to add a concentric auxiliary circle.' An SVG of a pelican riding a bicycle took a full 21 minutes of thinking, burning over twenty thousand reasoning tokens. The title of his article is literally 'Very excellent, but defaults to insane overthinking.'

Simon Willison's test article, titled 'Very excellent, but defaults to insane overthinking'

The pelican SVG and the line 'Was that worth waiting 21 minutes for? Absolutely not.'

Turning off reasoning for the same prompt, it finished in just over two minutes. So for daily use, it's recommended to adjust reasoning_effort to medium or low.

There are two more real-world feedback points from the community worth mentioning.

One is token consumption. Someone abroad tested 3.8 and the previous generation 3.6 side-by-side. Answer quality, 3.8 indeed wins, taking 9 out of 10 tasks, but the cost is that the average token consumption is almost three times that of 3.6. On one task, 3.8 thought for over 7 minutes, burning over thirty-one thousand tokens, while 3.6 submitted its answer in a minute and a half with over seven thousand tokens. Some people have already silently switched back to 3.6 after testing. This drawback is less fatal when running locally—after all, you're burning your own electricity—but if you plan to call the API and pay by volume, you need to calculate this bill carefully.

The other is the knowledge cutoff. Someone asked it when its training data ends, and it answered 2026. But when pressed for specific events after 2024, it was exposed. It doesn't know what it doesn't know; keep this in mind when using it.

Additionally, early user feedback mentions output truncation during multi-turn, long agent tasks. This awaits an official fix and more testing.

The 1M context, as mentioned earlier, is still just a PowerPoint number for now.

7. Who should get on board

Honestly, Qwen3.8-27B can't replace my main production tool yet. For real project work, I'll still open the cloud.

But its significance isn't about today. In an era where tokens are increasingly insufficient, a local model has touched the threshold of 'usable' for the first time. At this pace, a fully qualified, production-grade local model will inevitably appear sooner or later. By then, intelligence won't require a monthly subscription; it will live right inside your own computer. I don't need to elaborate on what this means for on-device AI.

Comments

Top 1 from juejin.cn, machine-translated. The original thread is authoritative.

用户015544495830

Solid write-up, especially the point in Section 5 that 'read speed is more valuable than tok/s' — only people who've actually tested it understand this. Many only focus on generation speed, but when running agents with long contexts, it chokes; the bottleneck is actually in the KV cache re-reading part. The author also explains the Gated DeltaNet approach of 'only remembering the balance, not the transaction log' clearly. Two additional real-world details that align perfectly with the article's points: 1. MTP is indeed the biggest speed variable right now. The article says it jumps from 66 to 121 tok/s on a 5090; on my RTX 4090, enabling MTP also roughly doubles the speed, but VRAM usage increases noticeably. In long-context scenarios, you have to weigh the trade-offs yourself — the line 'when you see a high speed claim, first ask if MTP was on' is too real. 2. The overthinking pitfall — tuning reasoning_effort really can save you. The default xhigh can think for 21 minutes just to draw an SVG, exactly like the Simon Willison case. For daily use with Claude Code, I recommend going straight to medium; quality doesn't drop much, and the wait time shrinks dramatically. I also agree with the conclusion in Section 4 that 'if you have enough memory, go 8bit; if it's too slow, go 4bit.' However, my personal trade-off is: for running agent long tasks, prioritize 4bit + enable MTP, because speed carries more weight in agent scenarios; for reasoning tasks that require quality, then switch to 8bit. Just a reference. The best summary is that line from the article — 'Intelligence doesn't need a monthly subscription; it lives right inside your own computer.' Although a 27B model can't yet replace a cloud production workhorse, a local model has touched the threshold of 'usable' for the first time. This signal itself matters far more than benchmark scores.