Muse-Glimmer 30B vs Qwen3.8 27B — both "local agent models", one distilled, one native

Two things happened close together in August 2026: Meta Superintelligence Labs released Muse-Glimmer 30B on the 10th, and Alibaba’s Qwen team released Qwen3.8-27B on the 14th. Both are open-weight, both Apache 2.0, both dense, both multimodal, both pitched primarily at “running agents locally” — and they are close enough in size that any feature table lining them up ends with two nearly identical columns of ticks. None of those tables are useful.

The difference is not in the feature table. It is in the two release notes, one sentence each.

Muse-Glimmer:

Trained on Muse Spark’s outputs using logit distillation — transferring agentic reasoning from a much larger teacher model.

Qwen3.8:

Built on the architectural foundation of Qwen3.5, bringing a Qwen-Max-class model to open release for the first time.

One is a capability that was compressed into a smaller model. The other is a capability that grew in place. That difference propagates all the way down to the architecture, the context length, the speed story, and when you should pick which.

How much to trust the numbers first

The core of this comparison is benchmark scores, so one thing has to be said before any table is read:

Both model cards include the other model in their own benchmark tables, each evaluated under the harness the vendor chose.

Qwen’s card carries a “Muse Glimmer-30B” column: 51.2 on SWE-bench Pro against Qwen’s 61.7, 65.9 on OSWorld-Verified against 84.3. Meta’s card carries a “Qwen3.6-27B” column (note: the previous generation, not 3.8): Qwen3.6 scores 77.2 against Muse’s 76.0 on SWE-bench Verified, and 75.6 against 65.9 on OSWorld — Muse loses.

Each side picked the comparison and the evaluation setup that flatters it: Qwen matches its current generation against Meta’s model; Meta matches its model against Qwen’s previous generation; harness, temperature and context window are each side’s own. This is not fabrication — both footnoted their setups plainly — but it means any cross-table comparison is comparing evaluation setups as much as models.

So the rule used in this article: relative gaps within one table are readable; absolute values read across tables should be discounted. The vendors’ own headline numbers (Meta’s 76.0, Qwen’s 61.7) are cited only as “what that vendor claims.” The only directly comparable items are those both sides ran under a public harness — SWE-bench Pro under the Claude Code harness is the one where the numbers line up.

Architecture: one pure-attention, one hybrid

This is the lowest-level disagreement, and the key to everything else.

Muse-Glimmer-30B is a textbook dense causal Transformer: 52 layers, hidden 6656, a repeating [Local, Local, Local, Global] attention pattern, 2048 sliding window, GQA at 16:1. Vision runs through a separate frozen ~1.8B-parameter ViT-G/14 perception encoder. The LM is 29.6B.

Qwen3.8-27B is hybrid: 64 layers in which 3 of every 4 use Gated DeltaNet (linear attention) and only 1 uses real Gated Attention. Vision is fused into the language model (listed as the qwen3_5 architecture on HF, loaded via AutoModelForMultimodalLM) with no separate encoder. It also carries an MTP head (multi-token prediction) — speculative decoding was baked into the training.

The practical consequences:

• The hybrid architecture is cheaper at long context. DeltaNet’s linear attention means a 262K context does not pay a quadratic cost per token at inference. Qwen supports 262,144 natively, extensible to 1M with YaRN; Muse-Glimmer is listed at 131,072+ with no official extension path.
• The pure-attention architecture is more “standard”. Every inference framework already knows it. Muse-Glimmer’s llama.cpp, MLX and ExecuTorch support was promised at release; Qwen3.8’s hybrid path requires frameworks to support DeltaNet, and while vLLM / SGLang / TokenSpeed all ship recipes, the coverage is still spreading.
• The MTP head and the DFlash drafter are the same idea done two ways. Qwen trained speculative capability into the main model — the community has already unlocked a +33–39% decode speedup with one llama.cpp flag. Meta ships a separate 5-layer DFlash drafter that proposes a whole block of 16 tokens per forward pass; official measurements show 3.1× on an RTX 5090 and 1.8× on an M5 Max. One is “in the model”, the other is “next to the model”, and which one wins depends on which your serving stack recognises.

Context and thinking control

	Muse-Glimmer 30B	Qwen3.8 27B
Context	131,072+	262,144 native, extensible to 1,000,000 with YaRN
Vision	Separate ViT-G/14 encoder (~1.8B, frozen)	Fused into the LM (native vision-language, incl. video)
Thinking switch	System-prompt convention: Reasoning strength: low / medium / high / xhigh	API parameter reasoning_effort: xhigh (default) / medium / low
Multi-turn reasoning retention	—	preserve_thinking, on by default, keeps thinking blocks across turns
Knowledge cutoff	January 4, 2026	Not stated
Languages	Trained on 100+ languages	201 languages and dialects (Qwen3.5-lineage claim, carried into 3.8)

preserve_thinking is the one Qwen-side feature worth a sentence on its own. In multi-turn agent work it lets the model see its own reasoning from earlier turns, and the official documentation pairs it with a sober caveat: lower reasoning effort does not always reduce total task time — each turn answers faster, but shallower analysis causes more failures and retries, raising total latency and token spend. That is the kind of documentation you can only write after the knob exists and has been used. On this axis the two projects are not at the same maturity: Meta’s Reasoning strength is a convention you write into the system prompt; Qwen’s is a first-class API parameter understood by the serving frameworks.

Benchmarks: reading gaps inside one table

The official table from Qwen’s model card (released 2026-08), with the Muse-Glimmer column evaluated by the Qwen team:

Benchmark (harness in footnote)	Qwen3.8-27B	Muse-Glimmer-30B
Terminal Bench 2.1 (Terminus)	73.0	51.7
SWE-bench Pro (Claude Code harness)	61.7	51.2
IFBench	79.5	77.0
GPQA Diamond	89.2	83.5
HLE	30.8	22.0
OSWorld-Verified	84.3	65.9
OmniDocBench 1.5	91.1	75.8

Within that one table the gaps are clear: under Qwen’s evaluation setup, Qwen3.8-27B leads on every comparable item, widest in agentic coding and computer use (Terminal Bench +21.3, OSWorld +18.4).

But the same reading has to work in reverse: on Meta’s card, Muse-Glimmer scores 76.0 against Qwen3.6-27B’s (the previous generation) 77.2 on SWE-bench Verified, and 65.9 against 75.6 on OSWorld. In other words, under Meta’s chosen comparison Muse is roughly level with the previous Qwen generation, and Qwen itself describes 3.8 as delivering “substantial gains” over 3.6. Which generation actually beats which has not been settled by anyone under a shared setup — which is exactly the concrete form of “discount absolute values read across tables.”

One row is worth recording on its own: Meta’s table shows Muse-Glimmer at 51.2 on SWE-bench Pro, and Qwen’s table shows 51.2 too — the same number in both tables means this item was run under the same public harness (Claude Code). It is the only coding number where the two sides line up directly. On it, Muse trails Qwen3.8 by 10.5 points and also sits slightly below Qwen3.6’s 53.5.

Local deployment: both sell 24–32GB, but differently

This is where the two models genuinely face the same buyer.

Muse-Glimmer’s official story: at roughly 4-bit quantisation the LM is under 20GB, and with the KV cache, the perception encoder and the DFlash drafter included, the whole thing fits a 24GB or 32GB envelope. Meta publishes three quantisation tiers with measured degradation: full precision (64GB VRAM), K-Quant-Dynamic (32GB, 0.2% degradation), K-Quant-17GB (24GB, 1.0%) — degradation being the mean accuracy change across 15 common benchmarks. Speed: K-Quant-17GB with the quantised drafter measured at 74.9 → 233.4 tok/s on an RTX 5090 (3.1×), 23.7 → 37.8 on an M4 Max (1.5×), 26.6 → 50.2 on an M5 Max (1.8×).

Qwen3.8’s official story: no quantisation tier table, no target-hardware envelope. The model card calls it a “compact, deployment-friendly dense model” and points every deployment question at the SGLang / vLLM / TokenSpeed recipes, leaving quantisation to the community — there are already 1,035 quantised versions on HF. Official sampling parameters are split into thinking and instruct sets, and the card gives explicit output-length advice for agent work (within a 1M context: reasoning content up to 262,144 tokens, final answer up to 131,072).

Put the two stories side by side and the difference is not “which is better” but “which one finished the last mile”:

• Meta ships a complete recipe: which quant tier, which memory envelope, which tok/s, how much degradation — all official numbers. You get “it runs if you follow the card”, at the cost of having to fill in the combinations outside the recipe (an M3 Max, ROCm on Linux) yourself.
• Qwen ships a more general model: a newer architecture (hybrid attention + MTP), a longer context, a wider ecosystem (201 languages, official Qoder / Qwen Code / Qwen Studio product lines) — but the answer to “how do I run this best on my machine” is thinner in the official material than Meta’s.

Hugging Face download numbers quantify the difference: as of 2026-09-10, Qwen3.8-27B had 6.71M monthly downloads against Muse-Glimmer-30B’s 665K. Released four days apart, a 10× gap in adoption — that is the existing Qwen ecosystem (Qwen3.5 / 3.6 community momentum) working, and it is also the market’s vote on “more general” versus “more turnkey.”

Choosing

Take Muse-Glimmer 30B if your core constraint is “on one specific 24/32GB machine, it must run today, and the speed must be guaranteed” — Meta’s published quant tiers, memory envelopes and tok/s figures are the most complete official deployment contract in this category right now; if your agent handles a lot of images and no video, the separate ViT encoder path is the more battle-tested route; or if you want a local judge model with a stated knowledge cutoff (2026-01-04) and predictable behaviour — Meta lists LLM-as-a-judge as an intended use.

Take Qwen3.8 27B if your tasks need long context (262K native, 1M extensible); if your vision work includes video; if you are already inside a larger Qwen ecosystem (Qoder, Qwen Code, Qwen Studio, ModelScope); if your team needs 201 languages; or if you are willing to spend some deployment tuning time in exchange for a newer architecture with a higher capability ceiling.

Take neither if the “local” constraint does not actually hold — if you have a 24GB+ card and do not care about data leaving the machine, a current closed frontier API model beats both of these 30B-class local models. The comparison on this page is real, but it is only worth having when “offline, data stays on the machine, a single 24–32GB card” is a hard requirement.

A note on how this was written

Every architectural, context, thinking-control and deployment claim here comes from the two vendors’ own release material: Meta’s research blog (2026-08-10) and the Hugging Face model card (meta-models/Muse-Glimmer-30B); Qwen’s GitHub README and Hugging Face model card (Qwen/Qwen3.8-27B). All benchmark figures are quoted from each side’s own card, the limits of cross-table comparison are stated explicitly above, and no number in any table was converted, rescaled or interpolated.

Download counts came from the Hugging Face API on 2026-09-10 and will drift.

One easily missed fact is worth recording: Qwen’s card compares against “Muse Glimmer-30B” while Meta’s compares against “Qwen3.6-27B” — neither side published a complete, same-setup benchmark table against the other’s current generation at release. Until one of them does, both conclusions in this article — “Qwen leads across the board” and “Muse is roughly level with the previous Qwen generation” — hold only under each vendor’s own evaluation conditions.

The author has not run either model through an extended hands-on trial. Where this page makes a judgement rather than reports a fact, it reasons from the documented design decisions and official figures in the release material, and it says so.

The two illustrations are generated, not photographed. Each is compiled from a typed specification of the facts above into a self-contained interactive HTML (Archify), with the static images rendered from the same specification — so they carry no claim the text does not make.