Meta released Muse Glimmer on 10 August: roughly 29.6 billion parameters including the vision encoder, Apache 2.0, and quantized small enough to run inference on a machine with 24 to 32GB of memory [1]. Half a million downloads in the first month [1]. For anyone who has wanted an agent loop that never leaves the building, this is the most consequential release of the summer, and the licence is doing as much work as the weights.
It is also a model whose architecture rewards about ten minutes of reading before you plan anything around it.
What you actually get
The headline specifications, from the model card [1]:
| Property | Value |
|---|---|
| Parameters | ~29.6B including vision encoder |
| Architecture | Dense causal transformer, not mixture of experts |
| Perception encoder | ViT-G/14, ~1.8B parameters, up to 4,096 visual tokens per image |
| Context length | 131,072+ |
| Licence | Apache 2.0 |
| Quantized variants | BF16 full precision, plus K-Quant-Dynamic and K-Quant-17GB |
| Languages | Trained on data from 100+ languages |
The agentic benchmark results are genuinely strong for the size class: MCP Atlas 75.5%, DeepSearch QA 74.6%, SWE-Bench Pro 51.2%, AIME 2026 94.7%, with Charxiv Reasoning at 78.8% and OmniDocBench at 75.8% on the multimodal side [1]. Meta describes the model as built for end-to-end task completion, reliable tool use, multi-step reasoning and failure recovery, and it lists compatibility with agent harnesses including OpenClaw and Hermes Agent [1].
Worth knowing what those numbers are being measured against. Meta positioned the model against Gemma 4 31B and Qwen 3.6 27B across agentic, coding, multimodal, safety and reasoning suites, and the differentiator it claims is not raw score but superior multi-step tool reliability and failure recovery [3]. That is the right comparison set: this is a fight for the 30B open-weight slot, not a challenge to frontier hosted models.
The compression figure is also worth holding onto. Uncompressed, the weights are around 55GB. Dynamic 4-bit quantization brings that to roughly 17 to 20GB, which is what puts it inside a 24 to 32GB envelope [3]. Almost two thirds of the model is quantization, and that is the engineering that turned a datacenter artifact into something that runs on a workstation.
Failure recovery is the claim worth weighting most heavily. Benchmarks measure whether a model can do the task. Agent loops break on what happens when a tool returns something unexpected, and a model that retries sensibly is worth more in production than one that scores two points higher and gives up.
Dense, not mixture of experts, and that is a choice
Every one of those 29.6 billion parameters activates on every forward pass. There is no routing to a smaller active subset.
The tradeoff is worth stating plainly, because most recent releases at this size went the other way. A mixture-of-experts model of the same total size uses less compute per token, which usually means cheaper and faster. A dense model uses all of it, which means more compute per token and more predictable latency, because there is no routing decision whose cost varies with the input.
For a chat product, MoE usually wins. For an agent making many short tool calls in sequence, predictable per-call latency compounds into a predictable loop time, and loop time is the thing users feel. Dense is a defensible choice here rather than an oversight, and it also makes the memory story simpler, since you cannot avoid holding the whole model anyway.
The part to read twice
The model card describes the attention pattern as "Local, Local, Local, Global" repeating, with a 2048 sliding window and gated attention [1], alongside that 131,072+ context length.
Those two facts sit next to each other and they qualify each other. Three of every four attention layers see a 2048-token sliding window, not the full context. Only the fourth layer attends globally. The 131K figure is real, and it is not the same thing as 131K of uniformly available attention at every layer.
This is a completely standard and sensible efficiency design, and it is a large part of how a 30B model fits the memory budget it fits. The reason to know about it is that agent workloads have an unusual context shape. A long agent trajectory is not a document. It is a sequence where something decided 40,000 tokens ago, a constraint the user set at the very start, has to keep governing behaviour at step ninety. Those long-range dependencies are exactly what passes through the global layers only.
The practical consequence: if your agent depends on an instruction staying live across a long trajectory, do not rely on the context window alone to carry it. Restate the constraint, or keep it in a structure the agent re-reads, rather than trusting that something said at position 200 still exerts full force at position 60,000. That is good practice with any long-context model. With this attention pattern it is not optional.
Yesterday's piece on multi-agent authorization found the same thing empirically from a different direction: the constraint gets lost at the handoff, and re-anchoring to the original request beats hoping it propagates.
Two different deployment stories share one model name
Here is where the coverage blurs, and separating it will save someone a bad capacity plan.
The consumer story. Quantized to under 20GB, running on a 24 to 32GB device, an M4 or M5 Max Mac or an RTX 5090, with DFlash speculative decoding giving up to a 3.1x throughput increase on the 5090 and 1.5x to 1.8x on Apple Silicon [1]. This is the "your agent does not leave the building" story, and it is the one that makes the release matter.
The datacenter story. NVIDIA measured over 20,000 tokens per second per GPU on Blackwell Ultra at BF16 and NVF4 precision, with a single GPU holding the full model and leaving room for large KV cache buffers [2]. NVIDIA lists deployment across NIM containers, SGLang and vLLM, and tested across RTX 5090, DGX Spark, DGX Station and Jetson [2].
Both are true. They are not the same product. A number measured on Blackwell Ultra tells you nothing useful about what your laptop will do, and the throughput gap between those two environments is orders of magnitude, not percentages. When you see a tokens-per-second figure for this model, check which machine produced it before you put it in a plan.
The genuinely interesting bit is that the same weights span that range at all, from Jetson to Blackwell Ultra [2]. That is what Apache 2.0 plus a dense 30B buys you: one model you can prototype on locally and deploy on real hardware without changing model, vendor or licence terms.
Why the licence is the story
Strip out the benchmarks and the release still matters, because Apache 2.0 permits commercial use, modification and redistribution without the conditions that come attached to most open-weight releases at this tier.
For agent work specifically, that changes three things. You can run the model somewhere your data is not permitted to leave, which is the blocker in most regulated environments and no amount of benchmark improvement solves it. You can fine-tune it and ship the result. And your per-token cost becomes hardware you already own rather than an invoice that follows your loop count.
That last one connects to something published here yesterday. Hosted Flash-class pricing is scheduled to double on 1 January 2027, and agent loops are output-heavy, so they absorb per-token increases badly. A capable local model under a permissive licence is the structural answer to that exposure, and it is available now rather than as a promise.
Not for free, to be clear. You trade the token bill for hardware, electricity, an inference stack to operate, and a model that will not match frontier hosted models on the hardest tasks. The 51.2% on SWE-Bench Pro is a real number and it is not a frontier number [1]. The question is not whether local matches hosted. It is whether local is now good enough for the specific loop you are running, and for a large class of tool-calling, document-processing and internal-automation work, 75.5% on MCP Atlas suggests it is [1].
What I would do with it
Test it on your failure cases, not your happy path. The claim that distinguishes this model in its size class is failure recovery [1]. That is only visible in a test where the tool returns an error, a malformed payload or an empty result. Every model looks capable when the tools work.
Measure on the hardware you will actually deploy. Given the spread between a Jetson and a Blackwell Ultra [2], no published throughput figure substitutes for a measurement on your own box, and the quantization variant you choose changes the answer again.
Design the prompt for the attention pattern. Restate long-lived constraints periodically. Keep the governing instruction close to where the decision is made rather than only at the top of a 100,000-token trajectory.
Read the model card before the coverage. Nearly everything above came from the card itself, which took a few minutes. The trade write-ups were accurate, but they led on parameter count and price framing, and the attention pattern that shapes how you should structure an agent prompt was not in any of them.
References
[1] Meta — meta-models/Muse-Glimmer-30B model card. Article
[2] Rajath Narasimha and Sachin Beldona, NVIDIA — Run Local Agentic AI Workflows with Meta's Muse Glimmer on NVIDIA. Article
[3] Olimpiu Pop, InfoQ — Meta Open-Sources Muse Glimmer: a 30B Local Agentic Model Optimised for On-Device Execution. Article