Meta released the weights for a ~29.6B dense multimodal model built for agentic work, under Apache 2.0, on 10 August 2026. Quantized to roughly 4 bits it fits in under 20 GB, which puts a tool-using, screenshot-reading agent on one consumer GPU or a Mac. It is not a frontier model and Meta does not claim it is. It is the first genuinely capable agent model most teams can run without sending a byte to anyone. This is our engineering read on the spec, the evals, the hardware bill, and where it does and does not belong.
Meta shipped these weights under a standard permissive licence, not the bespoke Llama Community Licence it used for years. That means commercial use, fine-tuning, distillation, and redistribution without asking anyone, and without an acceptable-use rider your legal team has to read twice. For a buyer, that is the single most consequential line in the release.
Meta trained and evaluated Glimmer for end-to-end task completion: precise tool calls against real schemas, multi-step reasoning, diagnosing its own failures and recovering, and reading screenshots and documents as part of the loop. The benchmark set reflects that. It leads its size class on MCP Atlas (75.5 vs 54.2 for Gemma4-31B) and on the agentic suites, not on trivia.
Full precision needs 55 GB or more. Meta's calibrated 4-bit quantization pulls the language model under 20 GB, which leaves room for the KV cache, the vision encoder, and the drafter inside a 24 or 32 GB envelope. An RTX 5090, an M4 or M5 Max Mac. A bundled DFlash speculative-decoding drafter adds 3.1x decode speed on the 5090 and 1.5x on an M4 Max.
Meta benchmarked Glimmer against Gemma4-31B and Qwen3.6-27B, and it wins across that set. It did not benchmark against the closed frontier, and neither should you when you set expectations. On SWE-Bench Pro it scores 51.2, ahead of Gemma4's 36.9 but barely ahead of Qwen3.6's 50.2. This is a strong local model, not a frontier replacement.
Zuckerberg used the launch to commit to opening the weights of Muse Spark 1.2, the frontier model from Meta Superintelligence Labs, and to a governance change giving independent directors approval over model-release safety criteria. No date, no licence, no artifacts. Plan around Glimmer, which exists. Treat Spark 1.2 as a thing to watch.
The developer side. Everything you need to size an integration before you download 30 gigabytes. Figures come from Meta's research post and the Hugging Face model card at launch.
| Parameters | ~29.6B total, dense (not a Mixture-of-Experts). Roughly 28B text decoder plus a 1.8B vision encoder. |
|---|---|
| Decoder | 52 layers. Three sliding-window attention layers (2,048 tokens) to one full-attention layer, repeated 13 times. |
| Attention | Gated grouped-query attention, 16 query heads per key-value head, with Q-K normalisation and extra query scaling. |
| Vision encoder | 2B ViT-style Perception Encoder. 50 layers, 2D RoPE, 4x pixel shuffle on image tokens. Video up to 96 frames at 2 fps. No audio. |
| Context | 131,072 tokens per the model card. Serving stacks often default lower, so set it explicitly rather than inheriting a 32k default. |
| Modalities | Text and interleaved images or video frames in, text out. Native object-detection output format. |
| Languages | 100+ supported. Benchmark coverage is English-heavy, so validate your locales yourself. |
| Knowledge cutoff | 4 January 2026. |
| Licence | Apache 2.0. Commercial use, modification, and redistribution permitted, attribution and licence notice required. |
| Artifacts | BF16 full precision, K-Quant-Dynamic and K-Quant-17GB (roughly 4-bit, calibrated by Meta), plus Muse-Glimmer-30B-assistant, the DFlash drafter. |
| Speculative decoding | The DFlash drafter proposes up to 15 tokens per step at block size 16. Supported in transformers and llama.cpp. Biggest wins on structured and code output. |
| Tool use | Native function calling with structured JSON, multimodal tool calls, controllable reasoning effort. Works with Claw-style and Hermes-style scaffolds, and with the OpenClaw gateway. |
| Runtimes | Transformers day one. llama.cpp, MLX, ExecuTorch, vLLM (transformers backend), SGLang, Ollama, LM Studio, Unsloth. OpenAI-compatible surface across most of them. |
| Hosted options | Together AI, Fireworks AI, and OpenRouter named as launch partners. No public Glimmer per-token rate at launch. |
| Fine-tuning | One H100 80GB is enough for LoRA. Full fine-tune wants 8x H100. PyTorch TorchTitan supported for custom tuning. |
| Safety | Evaluated under Meta's Advanced AI Scaling Framework. Reported moderate or lower risk on chemical and biological, cyber, and loss-of-control domains. |
The vLLM path at launch runs through the transformers backend rather than custom CUDA kernels, so early throughput on a server deployment will trail what the same hardware eventually delivers. If you are sizing a fleet, benchmark after the kernels land rather than budgeting off day-one numbers.
The testing side. Meta compared Glimmer against the two models it actually competes with: Gemma4-31B and Qwen3.6-27B. Read that framing carefully, because it is the honest one. Glimmer wins its size class, and the margins are widest exactly where Meta aimed, on agentic tool use and long-context retrieval. It is much closer to Qwen on raw coding and reasoning than the headline suggests.
| Capability | Muse Glimmer 30B | Gemma4-31B | Qwen3.6-27B |
|---|---|---|---|
Tool use MCP Atlas multi-step MCP orchestration | 75.5 +21.3 pts vs Gemma4 | 54.2 | 62.5 |
Agentic search DeepSearch QA | 74.6 +12.9 pts vs Gemma4 | 61.7 | 71.1 |
Agentic suite WildClawBench | 47.6 +10 pts vs Gemma4 | 37.6 | 43.2 |
General agents GAIA2 | 43.3 +6.9 pts vs Gemma4 | 36.4 | 40.0 |
Agentic coding SWE-Bench Pro the closest race in the set | 51.2 +14.3 pts vs Gemma4 | 36.9 | 50.2 |
Scientific coding SciCode | 43.6 +0.2 pts vs Gemma4 | 43.4 | 39.8 |
Chart and figure reasoning Charxiv Reasoning all three effectively tied | 78.8 +1.1 pts vs Gemma4 | 77.7 | 78.4 |
Math AIME 2026 | 94.7 +5.5 pts vs Gemma4 | 89.2 | 94.1 |
Long-context reasoning AA-LCR the widest margin in the set | 80.0 +11.7 pts vs Gemma4 | 68.3 | 73.3 |
Long-context retrieval Beam 128K | 65.1 +6.9 pts vs Gemma4 | 58.2 | 63.0 |
Figures are Meta's, published at launch, and used for orientation only. Two things worth naming. First, the comparison set is deliberate: Gemma4-31B and Qwen3.6-27B are the local peers, and no closed frontier model appears in it. Second, the coding, chart-reasoning, and math rows are close races against Qwen, so a headline like "beats Qwen on most benchmarks" is true and also does not tell you which one is better for your task. We re-run evals on customer tasks before recommending any model, and for a local model we run them on the quantization you will actually deploy, not on BF16.
The part most model pages skip. An open-weight model is only useful at the memory footprint you can afford, and the quantization you pick changes both the bill and the behaviour. Meta shipped calibrated 4-bit artifacts precisely so this table has a good answer. Speed figures below are Meta's reported decode speedups from the bundled DFlash drafter, against standard token-by-token generation on the same machine.
| Configuration | Artifact | Memory | Speed | Our read |
|---|---|---|---|---|
RTX 5090 (32 GB) | K-Quant-17GB | Under 20 GB, with headroom for KV cache, encoder, and drafter | 3.1x decode with DFlash | The reference target. This is the configuration the release was designed around, and the one to benchmark against first. |
Mac, M5 Max | K-Quant-17GB via MLX | 32 GB unified memory is comfortable | 1.8x decode with DFlash | The always-on developer machine case. Slower than the 5090, and it costs you nothing extra because the laptop is already bought. |
Mac, M4 Max | K-Quant-17GB via MLX | 32 GB unified memory | 1.5x decode with DFlash | Still workable. Budget more latency per step, which matters on long agent loops more than on single completions. |
24 GB consumer GPU | K-Quant-17GB | Tight. The 17 GB weights fit, the KV cache is the constraint | Drafter helps, context length hurts | Viable if you cap context. Do not assume the full 131k window fits alongside the weights on a 24 GB card. |
Full precision serving | BF16 | 55 GB or more | Baseline | An 80 GB datacentre card. Worth it only if you are measuring the quantization gap or serving many concurrent sessions. |
Fine-tuning | LoRA, or full | 1x H100 80GB for LoRA, 8x H100 for a full fine-tune | n/a | LoRA on a single card is the realistic path for most teams. Apache 2.0 means the resulting adapter is yours with no licence question. |
Meta reports minimal degradation on agentic tasks from the 4-bit quantization, and we take that seriously enough to test rather than to assume. Quantization damage does not show up evenly: it tends to surface first in long tool chains and strict schema adherence, which is exactly the workload this model is for. Our eval pass runs against the deployed artifact, not the full-precision one. AMD, Arm, Dell, Intel, and Nvidia have optimisation support in flight, so the hardware picture at the end of 2026 will be better than this table.
The impact side. What actually changes for an engineering team. Two comparisons matter: Glimmer against the local model it replaces, and against the hosted frontier model you are probably calling today. The honest summary is that Glimmer does not compete with a hosted frontier model on capability. It competes on a different axis entirely, which is whether the work has to leave your machine at all.
| Dimension | vs your current local model | vs a hosted frontier model |
|---|---|---|
Agentic workflows | +21.3 on MCP Atlas and +10.0 on WildClawBench against Gemma4-31B, and a clear lead over Qwen3.6-27B on the agent suites. The gap is largest on multi-step tool orchestration, which is the thing local models have been worst at. | A hosted frontier model still wins on hard, long-horizon work. Glimmer's case is the long tail of small agent steps: classification, extraction, routing, screenshot reading, first-pass drafting. Those steps are most of the token volume and none of the difficulty. |
Data boundary | Same as any local model, but now with an agent-grade capability behind it. The reason to run locally stops being cost and starts being that the model is finally good enough at the job. | This is the whole argument. Nothing leaves the machine. No DPA, no subprocessor list, no residency exception, no vendor retention window. For regulated, air-gapped, or on-device work, that is a capability a hosted API structurally cannot offer. |
Cost structure | No per-token bill either way. The difference is that Glimmer's quality now justifies the operational overhead you were already carrying. | Fixed instead of variable. You pay for hardware you may already own, and marginal inference is free. On a high-volume, low-difficulty workload that inverts the economics. On a low-volume one it does not, and a hosted API stays cheaper. |
Latency | The DFlash drafter is the real gain: 3.1x decode on an RTX 5090, 1.8x on an M5 Max. Speculative decoding shipped in the box rather than as a research note. | No network hop, no queue, no rate limit, no provider incident. Local p99 is boring in a way hosted p99 is not. Raw tokens per second will still trail a well-provisioned hosted endpoint. |
Licence and control | Apache 2.0 rather than a bespoke community licence. Fine-tune it, distil it, ship it inside a product, redistribute the weights. No acceptable-use rider, no user-count threshold, no branding clause. | You can pin a version forever. No deprecation notice, no silent model update changing your eval scores overnight, no pricing change. For audited pipelines that must attest to exactly which weights produced an output, this is the difference between possible and impossible. |
Operational burden | Roughly the same, and that is the point. If you already run a local model, swapping in Glimmer is a download and an eval pass. | Real, and it does not disappear. You now own quantization choices, memory budgeting, context limits, runtime upgrades, and the fact that a 30B model will confidently do the wrong thing on tasks a frontier model handles. Route accordingly. |
Inside a Kensink build, Glimmer is a routing option behind the same abstraction as Claude, GPT, and Kimi. The agent picks the model per step by difficulty, data sensitivity, and cost at runtime. The interesting pattern this release enables is a split loop: the local model handles the high-volume, low-difficulty, privacy-sensitive steps, and escalates the hard ones to a hosted frontier model. That was not practical with the previous generation of local models. It is now.
Meta spent years shipping open weights under its own licence, with an acceptable-use policy, a monthly-active-user threshold, and a branding clause. Glimmer drops all of that for a standard OSI-approved permissive licence. Commercial use, modification, distillation, and redistribution are permitted outright. For anyone who has had a licence review stall a Llama deployment, this is the change that matters most.
The architecture side. Nearly every large open release of the last two years has been a sparse MoE, which is efficient to serve at scale and awkward to run on one machine, because you still need memory for all the experts. Glimmer is a dense ~29.6B model, which is exactly the right shape for a single-GPU target. It is a deliberate choice against the prevailing fashion, made for the deployment story.
52 decoder layers alternating three sliding-window layers (2,048 tokens) to one full-attention layer, thirteen times over, with gated grouped-query attention at 16 query heads per key-value head. The practical consequence is that the KV cache stays affordable at long context on consumer memory, which is what makes a 131k window meaningful on a 32 GB machine rather than theoretical.
A 2B ViT-style encoder with 2D RoPE handles images, screenshots, charts, documents, and video up to 96 frames at 2 fps. Pixel shuffle cuts image tokens 4x after processing, which keeps multimodal prompts from eating the context budget. There is no audio path. For agents that read a UI and act on it, the seeing and the reasoning are one model and one process.
The implementation side. Meta published a separate drafter model, Muse-Glimmer-30B-assistant, that proposes up to 15 tokens per step at block size 16. Reported decode speedups are 3.1x on an RTX 5090, 1.8x on an M5 Max, and 1.5x on an M4 Max, with the largest gains on structured and code output. Supported in transformers and llama.cpp. Most releases leave this to the community. This one does not.
K-Quant-Dynamic and K-Quant-17GB are Meta's own calibrated artifacts, not community conversions. That matters because quantization quality varies wildly by calibration set, and a bad 4-bit conversion silently degrades exactly the schema adherence and long-chain reliability an agent depends on. Starting from a vendor-calibrated artifact removes one large variable from your eval.
Reasoning depth is selectable per call rather than always on or always off. On a local model this is a direct latency and battery control, not a billing one. The engineering job is routing effort by step difficulty inside the agent loop, so the cheap steps stay fast and the hard ones get the tokens they need.
Transformers works immediately. llama.cpp, MLX, ExecuTorch, vLLM, SGLang, Ollama, LM Studio, and Unsloth are supported or landing, with Together AI, Fireworks AI, and OpenRouter named as hosted partners. The one caveat is that vLLM runs through the transformers backend at launch rather than custom kernels, so server-side throughput will improve later.
Glimmer is trained for Claw-style and Hermes-style tool formats and works with the OpenClaw gateway. Behind our vendor-neutral provider layer it exposes an OpenAI-compatible surface through most runtimes, so adding it beside Claude and GPT is a config change plus an eval pass, not a rewrite.
There is no per-token price to quote, which is the interesting part. An open-weight local model moves the cost from a variable line to a fixed one, and that change is worth more than any per-million-token comparison. Below is the honest version of both sides.
Meta has published open weights for years, always under its own Llama Community Licence, with an acceptable-use policy, a 700-million-monthly-user threshold, and a naming clause. Every one of those is a question a legal team has to answer before a deployment. Apache 2.0 answers all of them in advance. If the Muse line stays on this licence, it changes the default posture for anyone who has fought that review, independent of whether Glimmer is the best 30B model on any given week.
The data-boundary argument is genuine: no DPA, no subprocessor list, no retention window, no residency exception. What you take on instead is operational. Quantization choice, memory budgeting, context caps, runtime upgrades, and the fact that a 30B model will do the wrong thing confidently on tasks a frontier model handles. Teams that treat local inference as free tend to discover the cost in month three. We size that trade against your actual volume and sensitivity, rather than defaulting either way.
Glimmer beats Gemma4-31B and Qwen3.6-27B across Meta's published set, and that is a fair claim about a fair peer group. It is not a claim about the frontier, and Meta did not make one. On coding, chart reasoning, and math the margin over Qwen is inside a point or two, which is close enough that your workload decides it, not the table. Anyone quoting "beats Qwen on most benchmarks" as a capability verdict is over-reading a set of close races.
Alongside the release, Meta said it would put a governance structure in place giving independent directors approval over the safety criteria for model releases, and reported that Glimmer was evaluated under its Advanced AI Scaling Framework at moderate or lower risk across chemical and biological, cyber, and loss-of-control domains. That is a more serious commitment than most open releases carry. It is also a promise about future behaviour with no track record behind it yet. Worth crediting, not worth banking on.
Zuckerberg committed to opening the weights of Muse Spark 1.2, Meta's most advanced model. As of the Glimmer launch there was no date, no licence, and no artifact list, only a stated intention within weeks. That would be a genuinely significant release if it lands under Apache 2.0. Until it does, it is a roadmap item. We plan builds around weights that exist and we tell clients plainly which is which.
Not for the hard steps. For the long tail: classification, extraction, routing, screenshot reading, first-pass drafting. Those are most of the token volume and none of the difficulty, and until now the local option was not reliable enough at tool calling to trust with them. The MCP Atlas and WildClawBench margins are where that changed, and they are the numbers we would test first.
The pattern this release enables is a two-tier agent: Glimmer handles the high-volume, low-difficulty, privacy-sensitive steps locally, and escalates the genuinely hard ones to a hosted frontier model. That is a routing problem behind a thin abstraction, which is how we build anyway. Teams that try to replace a frontier model outright with a 30B local one will be disappointed, and it will not be the model's fault.
You will deploy the 4-bit artifact, so that is what the eval suite should run against. Quantization damage concentrates in long tool chains and strict schema adherence, which is precisely this model's job. Meta's calibrated artifacts are a good starting point and they are not a substitute for measuring on your tasks. This is the single most common mistake we see in local-model deployments.
Apache 2.0 means a fine-tune on your proprietary data is unambiguously yours, a distilled smaller model is permitted, and shipping weights inside a customer's on-premise install raises no licence question. Those are architectural options the Llama Community Licence made expensive to reason about. When we scope an on-device or air-gapped build now, this changes what is on the table.
Every model we integrate runs through the same operating system. Three pillars, sixteen layers, one Compound Growth Loop. The methodology that keeps AI work from rotting after the first ship.
Read the K-FrameworkDirect API integration with the model. No LangChain, no orchestration vendor, no agent framework built on quicksand. Typed contracts, the same way we wire up Postgres.
An eval suite built from your real tasks gates every prompt and model change. Quality is measured before it ships, not vibed in a demo.
Governance, audit, and oversight wired in from day one. Who called what, with which prompt version, at what cost. Your auditors get answers, not screenshots.
A model in production without observability is roulette. We instrument every integration so engineering and finance can see the same numbers, and so a regression at 3am surfaces before a customer opens a ticket.
Tokens in, tokens out, dollars spent. Sliced by feature, tenant, and route. Budgets enforced where it matters.
Real distributions, not averages. We know which routes are slow, and why.
The same eval suite that gates a release runs continuously in production. A regression on real traffic surfaces fast.
PII scrubbed at the proxy, shipped to your SIEM. Retention controls match your compliance window.
Dashboards your team owns, not ours. At handoff you get the queries, the alerts, and the runbook. We are not in the path to read your metrics.
