Muse Glimmer is a flop
Muse Glimmer is a flop. It is the first Meta release since Llama 3.1 whose official card targets a 24 GB consumer GPU, and Meta pitches it as "built for local agentic workflows". On an RTX 3090, across fixed benchmarks and an agentic code-review loop, the numbers are bad.
The drafter proposes what the model rejects
DFlash is the release's speculative decoder, an implementation of block diffusion: the drafter writes a 16-token block and the target model verifies it in parallel. Setup is in the launch guide. On the 3090, the model throws away most of what its own drafter hands it:
| Workload | Drafted / accepted | Acceptance | Decode |
|---|---|---|---|
| Expository prose | 1,950 / 251 | 13% | 65.33 tok/s |
| Python coding | 1,741 / 394 | 23% | 96.79 tok/s |
| Arithmetic reasoning | 1,249 / 427 | 34% | 133.14 tok/s |
Counted per verification cycle instead, which credits the target's bonus token, the yield is 2.93 to 6.08 output tokens. A fixed 256-token request decodes at 113.43 tok/s, and the three workloads span 65 to 133 tok/s. Prose sits at the bottom of the acceptance range, so the drafter helps least where a text model spends most of its time. Overall, greedy outputs with and without the drafter differ on every workload tested.
Half the context of a four-month-old model
Muse Glimmer came out with a 128K context window, way too small for the time we are in. Qwen 3.6, the comparison model on Meta's scorecard, has had a 256K window since April. Four months later, Meta delivers half of that.
The model does not stop
In our custom harness, Qwen 3.6 easily figures out how to terminate the loop on its own: on one trivial code-review subtask it ran 3 turns and 30k cumulative prompt tokens, recorded its result, and stopped. Muse Glimmer ran 28 turns and 224k tokens on the same subtask: near-duplicate file searches, most returning nothing, repeated long after the answer sat in context. Told its turn budget was nearly spent, it kept searching. It recorded a result only when the harness withdrew the search tools and recording was the only call left. Whether it would ever finish without that shove is unknown. What it records reads coherently, but the model is prone to hallucinations.
On the official scorecard the agentic benchmarks look strong: MCP Atlas 75.5 versus 62.5 for Qwen3.6-27B, with similar leads across the SWE-Bench family. The prompting guide carries the catch: "Muse Glimmer routinely produces multi-thousand-token chains of thought." Multiply those chains across a loop that does not stop and a reviewed change costs roughly an order of magnitude more than with Qwen 3.6 on the same tasks.
The only way to end its runs is to force a tool call, and that means serving the model yourself. Meta's tool-calling doc, which covers the hosted API, allows only tool_choice: "auto" and returns HTTP 400 for "required" or a named function. The same page defaults parallel_tool_calls to true while the Glimmer prompting guide states the model "does not support parallel tool calls"; in practice the model makes one call per turn, so the model page is the one to trust. Meta's coding-agents guide, written around Muse Spark, describes agents that "loop until the task is complete" and says nothing about how a loop should end.
In conclusion, I wanted this model to work and the model scorecard looked intriguing, however, the results are mixed at best.