AI Blog

Muse Glimmer Ships Two Agentic Numbers, and the Wrong One Is in the Headline

Meta's 30B open-weights agent model scores 76.0 on SWE-Bench Verified and 24% on τ³-Banking. Five of its six headline numbers measure a model alone against a machine-checkable goal; the sixth measures it working with a person against a written policy — and that is the axis an always-on local assistant lives on.

By Agentic AI Wiki 10 min read

Meta's new open-weights agent model scores 76.0 on SWE-Bench Verified and 24% on τ³-Banking, and both numbers are filed under "agentic". The gap is not a bad harness or an unlucky run — it separates an agent working alone against a test suite from an agent working with a person against a written policy, and only the second one describes the always-on local assistant this model was built for. Read the low number before you plan a laptop deployment.

What shipped

Meta Superintelligence Labs released Muse Glimmer in the second week of August 2026: 30 billion parameters, Apache 2.0, distilled down from a larger internal Muse system and shaped specifically for agent loops rather than chat. It is the company's most consequential open-weights release in a while, and the interesting part is not the licence.

PropertyMuse Glimmer 30BWhy it matters for an agent
Shape 2B ViT-style perception encoder feeding a 28B text decoder; dense, not a mixture of experts. Dense means memory tracks the full parameter count, which is the right trade when you own the GPU rather than rent it. See mixture of experts.
Context 128K tokens. Enough for a long tool loop, not enough to stop budgeting it.
Deployment Compressed to roughly 4-bit, with block-level speculative decoding; runs on one consumer GPU or a Mac, no network call. Both choices buy latency, not quality — see below.
Licence Apache 2.0, weights on Hugging Face. No acceptable-use rider, no user-count trigger. You can ship it inside a product.

The headline scores are strong and were reported across a spread of agentic evaluations rather than the usual chat leaderboards. That spread is what makes the release worth reading carefully, because the scores do not agree with each other.

Muse Glimmer 30B reported benchmark scores Horizontal bar chart of six reported scores. AIME 2026 at 94.7, SWE-Bench Verified at 76.0, MCP-Atlas at 75.5, DeepSearch QA at 74.6 and SWE-Bench Pro at 51.2 are all solo, machine-checkable tasks. Tau-3 Banking, the one benchmark with a simulated user and a written policy, sits far below the rest at 24. Muse Glimmer 30B — reported scores (%) 20 40 60 80 100 AIME 2026 94.7 SWE-Bench Verified 76.0 MCP-Atlas 75.5 DeepSearch QA 74.6 SWE-Bench Pro 51.2 τ³-Banking 24 Solo task, machine-checkable goal Simulated user, written policy, pass^k scoring
Five numbers cluster. One does not, and it is the one that looks most like a household assistant's day.

Five of these measure the same thing

AIME, SWE-Bench Verified, SWE-Bench Pro, MCP-Atlas and DeepSearch QA look like five different capabilities. Structurally they are one: a model alone in an environment, pursuing a goal that a program can check. Nobody interrupts. Nobody changes their mind at turn four. There is no rulebook the model is expected to have read and to keep obeying while being talked out of it.

τ³-Bench is the exception on the list. It is the third generation of Sierra's tool-agent-user benchmark, and its whole design point is to put a second party in the loop: the agent talks to a simulated customer, calls domain APIs, and is scored against a policy manual it must follow throughout. Policy adherence is a first-class metric, not a footnote, and the leaderboard reports pass^k — success on the same task k times running — rather than best-of-k. Banking is its newest and hardest domain.

What each benchmark family actually tests Three columns comparing SWE-Bench Verified, MCP-Atlas and DeepSearch QA, and tau-3 Banking across three rows: who else is in the loop, what decides success, and what a failure looks like. Only the third column puts a person and a policy document inside the task. IN THE LOOP SUCCESS IS FAILS AS SWE-Bench Verified MCP-Atlas · DeepSearch QA τ³-Banking A repository and a hidden test suite. Tools and documents. No second party. A simulated customer and a policy manual. The tests pass. Binary, automatic. The answer matches a known ground truth. The right end state and no rule broken. A red test. Visible immediately. A wrong answer, fluently stated. A satisfied customer and a violated rule.
The third column is the only one where a satisfied user and a broken rule can happen in the same conversation.

That difference does real work. On SWE-Bench a failure is a red test — loud, immediate, and cheap. On τ³-Banking a failure can be a customer who hangs up happy after the agent waived a fee it had no authority to waive. The first kind of failure your CI catches. The second kind you find in an audit, or you do not find at all. It is the same asymmetry described in trajectory and process evaluation: outcome-only scoring cannot see a rule broken on the way to a good outcome.

The 24 is not Meta's problem alone

The reflex on seeing 24% is to conclude Meta cut a corner. The comparison points argue otherwise. In the same reported bracket, Gemini 3.5 Flash-Lite sits at 18% and Qwen3.6 27B at 17% — Muse Glimmer is ahead of its class, and the class is at the bottom of the chart. Meanwhile the frontier of τ³-Bench overall runs in the low seventies, and even those systems are reported to hold up in retail and airline while dropping sharply in banking.

So there are two effects stacked, and they should not be conflated. Banking is hard for everyone: more rules, more of them conditional, more places where the helpful action and the permitted action diverge. And small models are disproportionately bad at exactly this, because holding a long policy document in working attention across a dozen conversational turns while a user pushes back is a long-context discipline problem, not a knowledge problem — the effective-context failure described in effective context vs advertised, arriving under adversarial social pressure.

Which means the number to watch as local models improve is not SWE-Bench. Coding scores have been climbing on distillation alone. Policy adherence under multi-turn pressure has not moved nearly as fast, and it is the axis that gates every consumer assistant that touches money, health records or someone else's account.

What the engineering tells you Meta believes

Two shipping decisions are more informative than the benchmark table. Muse Glimmer is quantized to roughly 4 bits and it carries block-level speculative decoding. Neither improves quality; quantization costs a little and speculative decoding is provably output-neutral. Both buy per-token latency.

That is the correct obsession for an agent model and an unusual one to make this visible. A chat model pays its latency once per answer. An agent pays it once per step, and a modest task is ten to thirty steps, so a 200-millisecond difference in time-to-first-token becomes seconds of wall clock the user watches. Meta optimised the multiplier, not the multiplicand. Speculative decoding also has a known catch worth remembering before you assume the laptop numbers transfer: it trades extra compute for lower latency, so it wins on an idle personal GPU and quietly loses throughput on a busy shared one.

The 2B perception encoder points the same way. On-device agents spend their time reading screens, receipts and PDFs, not describing photographs. A small encoder bolted to a large decoder is a bet that the vision work is mostly transcription.

Where a 30B local agent actually earns its keep

Where a 30B local agent model sits in a hybrid loop A device boundary contains the harness, a local 30B model, and an on-device index. Two arrows leave the boundary: tool calls to third-party APIs, and an escalation path to a frontier model for policy-bound or multi-turn work. The diagram marks the tool egress as the path that leaves the device even when the model does not. DEVICE BOUNDARY Harness — the loop, the tool router, the policy checks you wrote yourself Muse Glimmer 30B — 4-bit, speculative decode Classify · extract · draft · summarise · route Every step that must not wait on a network On-device index Mail, notes, files Session state Never leaves disk Escalation gate — does this step bind the user to a rule, a spend, or another person? Third-party tool APIs Calendar, mail, payments, search — your data leaves here, model or not Frontier model, on demand Multi-turn service dialogue, policy adherence, anything irreversible EGRESS
The model stops at the device boundary. Your data does not — the tools are still on the network.

Split the work by whether a rule binds the outcome. Classification, extraction, drafting, summarising, routing and the read half of any tool loop are all things a 30B model does well and a local one does instantly and free — that is the case small and local models has always made, and Muse Glimmer strengthens it. Anything that commits the user to a policy, a payment or another person goes over the escalation gate to a frontier model, or to a person. Same architecture as a cascade, with the router being a static rule rather than a difficulty estimate; see model routing and cascades for why static usually beats clever here.

Two roles are underrated and this model is well shaped for both. It is a good local judge for cheap pre-filtering before you spend a frontier call on evaluation, and it is a good local pre-classifier that decides whether a request needs the network at all — which is the single highest-leverage thing you can put in front of a metered API.

And the caveat that gets skipped in every "runs on your device" launch: a local model is not a local system. The moment your agent calls a calendar, a mail provider or a payment API, the user's data crosses the boundary in a request the model never sees the other side of. Running inference locally removes one egress path and leaves the rest exactly where they were. That is a configuration problem, and it is the subject of egress control for agents, not a property you get from the weights.

FAQ

Is Muse Glimmer good enough to replace a frontier model in my agent?

For the code-shaped and retrieval-shaped parts of the loop, plausibly yes — the reported SWE-Bench Verified and DeepSearch QA numbers are in serious territory for 30B. For multi-turn work bound by a written policy, the reported τ³-Banking score says no, and no prompt will close a gap of that size.

Why does a model score 94.7 on AIME and 24 on a customer-service benchmark?

Because they are not the same skill. AIME is a single hard question with a checkable answer and no second party. τ³-Banking is a dozen easy turns in which the agent must keep obeying a rulebook while a simulated customer pushes for an exception. Reasoning depth does not buy policy discipline.

Does Apache 2.0 actually matter here?

It matters more than the benchmark spread for anyone shipping a product. A permissive licence with no acceptable-use rider and no user-count trigger means the weights can be embedded, fine-tuned and redistributed without a legal review per release, which is the practical difference between an experiment and a dependency.

What should I measure before trusting a local agent model?

Your own policy-adherence rate over multi-turn transcripts, scored pass^k rather than best-of-k, on the rules you actually enforce. A published benchmark tells you the class of model is capable; only your suite tells you the model holds your rules. See reading agent benchmarks.

Further reading

On this wiki:

Sources: