Muse Glimmer 30B: Meta's Apache 2.0 agent model that fits in 24-32 GB

Meta released Muse Glimmer on August 10 under Apache 2.0, and it is the first Meta open-weight release I would run as an agent rather than a chat model. It is a 30B multimodal model distilled from Muse Spark, with its own perception encoder, and Meta built it explicitly for autonomous agent tasks: multi-step reasoning, tool use and failure recovery. The scores Meta calls category-best are MCP Atlas 75.5, SWE-Bench Pro 51.2, AIME 2026 94.7 and Charxiv 78.8. The number that matters more for this site is a memory footprint: with a Q4_K_M GGUF plus a DFlash speculative-decoding drafter, it fits in 24-32 GB and holds latency inside an agent loop with no cloud call.

What shipped

BF16 weights for anyone with the memory. GGUF k-quants for llama.cpp-based runtimes. ExecuTorch builds for on-device deployment. On Apple Silicon there is both an Ollama path and an MLX path, so the same weights can be benchmarked on the two runtimes that matter on a Mac. The DFlash drafter is the part I would not skip: it is what keeps a 30B model's decode rate acceptable when the agent is generating tool calls in a loop.

MCP Atlas deserves a second look: it measures tool use through the Model Context Protocol, the interface you will actually use. SWE-Bench Pro at 51.2 from a 30B model is a number that two years ago only cloud models hit.

Why a local agent changes the bill

An agent is a loop, and a loop multiplies tokens. A single coding task can run thirty to a hundred model calls, most of them re-reading the same context. In the cloud every one of those calls is metered. On a Mac with 32 GB or more, the marginal cost of the hundredth call is electricity. That is the whole argument for local agents; until now the models that fit were not reliable enough at tool use.

The cheapest token in an agent loop is the one that never leaves the machine, and Muse Glimmer is the first Apache 2.0 model that makes that loop credible on one Mac.

Memory is the constraint to plan around. Using the rules from sizing unified memory on a Mac: a 30B model at 4-bit is roughly 17-18 GB of weights, the drafter adds around a gigabyte, and the KV cache grows with context. That is why Meta's own number is a range, 24 GB for short agent contexts and 32 GB when you want the loop to carry a real repository around.

What to benchmark before you trust it

Vendor scores say the model can do the task, not whether it can do it on your hardware at a speed your loop tolerates. Run these first.

• Decode tok/s, MLX versus GGUF, same prompt, same quantization, median of three runs with a cooldown between them.
• 4-bit versus BF16 quality on a fixed set of your own tool-call prompts. Measure argument correctness, not just whether it called a tool.
• The DFlash drafter under an agent loop, not on a single long generation. Acceptance rate drops when the output is short, structured tool calls, and that is exactly what an agent emits.
• Failure recovery: feed it a tool error on purpose and count how many steps it takes to route around it. This is the capability Meta advertises and the one most local models lack.
• MCP tool use locally through the Ollama function calling path, with the real MCP servers you run, not a toy.

Run those five and you will know within an afternoon whether Muse Glimmer replaces a cloud model for your agent tier, or only for the cheap steps in it.

The honest gap

Every benchmark above is Meta's own, and category-best is Meta's framing. The 24-32 GB fit and the in-loop latency claims come from the release, not from my machine, and I have not yet run the MLX and GGUF paths side by side on an M4 Max. The multimodal side has no local throughput numbers at all in what I have seen. Treat this as a model worth an afternoon of measurement, not a model you switch to on the strength of the announcement.