Meta released an open-weight model called Muse Glimmer this week under an Apache 2.0 license. The weights are published: anyone can download them and run them on their own hardware, with no per-request bill and no documents leaving their network.
It is a 30-billion-parameter dense model with a 128,000-token context window and native image reading. We ran it on a server-class machine in our office, but with roughly 22 gigabytes of memory, This could conceivably be run on high-end desktop gaming hardware with relative ease.
It is the most capable thing we have measured. It is also not going anywhere near a client yet, and both of those are worth explaining.
The scores
We run every candidate model through the same internal scoring harness before it touches client work. Muse Glimmer scored 100. A clean sweep, every category, no defects anywhere. It is the first model that has ever done that here.
For comparison, the two models we currently run in production scored 97 and 99 on the same scenarios. Both are good, reliable and run in production environments for our client. Neither had ever come through without missing something.
The margin on quality is a few points. What made this result unusual was the absence of failure modes, including on the category we consider hardest: catching a subtly wrong instruction rather than passing it through. Every other model we run misses some of those.
What we did with a perfect score
Our immediate reaction was that the perfect score was too good to be true. We went back and made the benchmark harder, on the reasoning that a test nothing has ever passed and something just aced is a test worth re-examining.
Three things changed:
- Repeat trials. Every high-consequence task now runs five times against each candidate, scored on the worst result rather than the average.
- Reliability as its own verdict. Quality, speed and reliability are now three separate results we do not blend into a single number.
- New scenario types. Adversarial inputs that try to manipulate the model, cases where the correct action is to do nothing, and cases where a confident wrong answer costs more than an admission of uncertainty.
What the harder tests showed
On that expansion i've requirement and difficulty, it held. The complex, judgement-heavy work stayed its strongest area under every test we added. Something that is quite profound in our extensive testing over the last 24 hours is that: we never caught it being wrong. When it produced an answer, the answer was good. The only "failures" were runs that stalled.
Then we gave it real work
Benchmarks are proxies, they're indicators of possible success but you need to actually put a model to work to really see if it stands up. So we also put it into an internal side project we built for our own use. Real work, on our own systems, But still contained in a controlled environment failures or issues can be closely examined before putting it into a client facing production environment.
The job was assembling a long structured document: selecting items from a reference collection we already held in a database, putting them in a defensible order, and explaining each choice in a line. Across two runs it produced 56 usable rows out of 56, with nothing rejected, and no fabricated content in the output at all.
That last number deserves an asterisk, because it is more a property of how we built the thing than of the model. The model was never allowed to produce the content itself, only pointers to it. It emitted identifiers and a rationale; a deterministic parser then resolved every identifier against the real records, and anything that failed to resolve would have been thrown out with a reason attached.
We constructed this specifically around hallucination concerns. The worst a hallucination can do in that design is produce a pointer that gets discarded. It cannot invent a record, because the actual content is never on the model's output path — it is joined in afterwards from the database. Ask a model to write the document instead, and a fabricated entry is indistinguishable from a real one without checking every line by hand.
That pattern is the genuinely portable lesson here, and it works with any model: have it choose and order things you already have, resolve its answers against your own data, and reject what does not resolve. You get its judgement without its capacity to invent the underlying facts. A useful test of whether you have drawn that boundary correctly: hand a reviewer the rejected list and see whether it means anything. If a fabrication would have been silently plausible rather than loudly rejected, the boundary is in the wrong place.
Two runs is two runs, and this was one task in one domain. It is encouraging, not a reliability guarantee.
Configuration is still a live variable
We are not certain the model is the cause of the stalls, and we would rather say so than imply more confidence than we have. It is a week old, the tooling for running it is younger, and we have already hit two configuration traps.
The speed helper is not optional. Muse Glimmer ships alongside a small companion model that accelerates generation, presented in the documentation as an optimization. Without it we measured about 10 tokens per second and tasks failed outright. With it, 17 to 23 tokens per second sustained in real use. Meta reports a 3.1× gain from that component on a consumer graphics card; we measured roughly 2.4× on a server class graphics card which performs significantly higher than consumer graphics cards.
It thinks in the response. The model writes its reasoning into a separate field before its actual answer. Our first smoke test asked it to reply with one short sentence and came back apparently empty — because it had spent 143 tokens of internal reasoning to produce a six-word reply, and the limit we had set cut it off before it got to the answer. A caller that reads the wrong field, or budgets tokens for the reply rather than the thinking, will conclude a working model is broken.
Both of those were the difference between failing and passing, and neither was obvious. It also gives us a plainer candidate explanation for the stalls: at roughly 20 tokens per second, a long structured response takes minutes rather than seconds, and response time scales with output length. Some of what we recorded as a stall may simply be a ceiling set too low for how this model works. We have not finished separating "slow" from "unreliable," and we are not going to guess.
Where it is running
On our own infrastructure, doing our own internal work, where we watch every run.
Not in any client environment, and not behind any client-facing process. That is our standard practice rather than a reaction to this model: a new model runs on our own systems for months, not days, before it becomes a candidate for anything a client depends on. Benchmarks cannot produce the evidence we need to confirm using them in a client facing production environment. That requires rigorous real world use which is why we have it run on internal projects where failure can happen.
Two 30-billion-parameter models can differ by 20× in speed
Here is every roughly-30-billion-parameter model we have benchmarked, with the median time to complete one realistic task:
- Muse Glimmer — 30B, dense — quality 100, median 93 seconds
- Gemma 4 31B — 31.3B, dense — quality 100, median 214 seconds
- Qwen3-Coder 30B — 30.5B, mixture-of-experts — quality 97, median 11 seconds
- Qwen3 30B-A3B — 30.5B, mixture-of-experts — quality 86, median 9 seconds
- Nemotron 3 Nano — 31.6B, mixture-of-experts — quality 70, median 21 seconds
All are advertised as ~30 billion parameter models. The fastest is more than twenty times quicker than the slowest. Parameter count predicted almost nothing.
Architecture did. A dense model uses all thirty billion parameters to produce every word. A mixture-of-experts model has thirty billion on paper but routes each word through a fraction of them — roughly three billion in the Qwen models. That single distinction sorted the results cleanly: both dense models were slow and both scored 100; all three mixture-of-experts models were fast, with quality ranging from 97 down to 70.
Against the other dense model in its class, Muse Glimmer is about 2.3× faster at identical quality, which makes it the most efficient dense model of this size we have tested.
The one prediction we will make, clearly labelled as ours rather than as a finding: we expect mixture-of-experts to be the winning approach for models that run locally. On the memory and power budget of a machine in an office, spending every parameter on every word is expensive in a way a datacenter does not feel. A dense model just posted the best score we have ever recorded, so this is not a claim that dense is inferior — it is a claim about which approach we think the hardware will favour over time.
Why open weights matter for a business
With a hosted API you are billed per request, your documents travel to a third party, and the model underneath you can be changed or retired on a schedule you do not control. Businesses have already been through that: a version deprecated, and a workflow behaving differently the next morning.
An open-weight model is a file. Once deployed it behaves the same tomorrow as today. Costs are fixed infrastructure rather than metered usage, so they do not climb with volume. Records stay in a private environment, and nothing external can deprecate it out from under a process your staff depends on.
For years now, open models were noticeably worse than hosted ones. On the business-shaped tasks we measure, that gap is now closed. Along with Gemma, there are two US-made, openly licensed models a business can download and run on its own equipment.
You do not need to buy any of this
Specialized hardware is expensive, and for most small and mid-size businesses, buying a machine and staffing someone to maintain it is a poor trade.
We buy, run and maintain the infrastructure and deploy workflows on top of it. You get predictable operating costs and a private processing environment without the capital outlay or the maintenance burden — and we are the ones who spend months testing a new model, on our own applications, before any of your work touches it.
Where data residency is not negotiable — regulated records, contractual obligations, an internal policy that does not permit certain information to leave your equipment — we will deploy and maintain the same workflows on hardware you own. The software is identical; only the location changes.
The short version
Muse Glimmer is an exciting development. A freely downloadable model, running on a single office machine, just posted the best scores we have ever recorded — and on the first real job we gave it, it produced 56 usable results out of 56 with nothing fabricated. The ceiling on what a business can run on its own equipment went up this week.
It is also slow, it stalled on a repeat trial, and we have not finished working out how much of that is the model versus how we have it configured. That is why it is doing our work and not yours. Those two things are both true, and neither cancels the other.
If you want to understand where this fits in your operation, read about how we approach AI implementation, or see how we test these models before recommending anything. If you would rather talk it through, get in touch.