How Muse Glimmer Fits an Agent on Your Device — Abstract Extraordinary

Skip to content

← Writing

18 August 2026<br>Tomas Koutsky<br>19 min read

How Muse Glimmer Fits an Agent on Your Device

The answer turns out to be a memory hierarchy disguised as a 30B Transformer.

glimmerlocal

on this page

Where the 55 GiB sits

Every fourth layer sees everything

Global attention without RoPE

Thirty-two queries, two memories

Inside one decoder block

A fifth projection inside attention

QK normalization separates semantics from temperature

Sandwich norms control what each branch writes

The vision tower is deliberately more conventional

Spatiotemporal patches make video native at the first projection

Variable resolution uses absolute and relative spatial signals

The bridge is small, but it does two critical jobs

There is no separate cross-attention stack

Embeddings and the output head

Why quantization buys unusually much on Muse Glimmer

The architecture's thesis

Source notes

Meta pitches Muse Glimmer as an agent that runs on your device: autonomous, multimodal, no cloud required. That is an engineering problem as much as a product claim: fit a capable 30B-class model, a long working history, and a perception stack into consumer hardware. The answer turns out to be a memory hierarchy disguised as a 30B Transformer.

Its model card is direct about the goal: Muse Glimmer is “purpose-built for autonomous agentic tasks on consumer hardware,” and it runs “without requiring cloud infrastructure or network access.” The promise is demanding because an agent's workload is long-lived. Hours of history and tool transcripts stay resident, screenshots and documents get reread mid-task, and all of it has to fit inside the 24 or 32 GB envelopes Meta names for its quantized releases.

Muse Glimmer is a roughly 30-billion-parameter, decoder-only multimodal model: a vision encoder, a projector, and a dense language model. In BF16 the checkpoint weighs about 55 GiB, which would overflow both of those envelopes before a single token of context, so part of the answer is easy to name: Meta ships roughly four-bit quantized variants that bring the language model below 20 GB. The compressed model still has to share the card with a 131,072-token context, a resident vision tower, and a speculative-decoding drafter, and none of them get smaller when the language model does. The rest of the answer is architectural: where the model spends memory, and what kind of information each layer carries.

Muse Glimmer is built around a deliberate division of labor. In most layers, attention is local: positioned by RoPE and bounded to a 2,048-token window. In every fourth layer, attention opens to the entire context but drops RoPE, retrieving primarily by content. Only the attention alternates; the rest of every block is identical. Thirty-two query heads provide a rich set of retrieval behaviors, while only two key/value heads are stored in the KV cache. On the visual side, a large ViT performs expensive perception once, compresses neighboring patches four-to-one, and hands the result to the language decoder as ordinary tokens.

Taken together, the parts form a hierarchical memory system:

local layers construct ordered, context-rich representations;<br>global layers search those representations over the full sequence;<br>the KV cache stores a very narrow memory trace for each active sequence.

Per-sequence state is tiny by design, so nearly all the memory a running instance needs is the model's parameters. That is why weight quantization pays off so unusually well here. Once those fixed weights are compressed, the freed memory can be turned into longer contexts, larger batches, a resident perception tower, or a speculative-decoding drafter.

Where the 55 GiB sits

Here is the breakdown, summed from the released tensor shapes:

ComponentApproximate parametersBF16 storage52 text Transformer blocks25.165B46.87 GiBInput token embedding1.345B2.50 GiBUntied language-model head1.345B2.50 GiBVision tower1.853B3.45 GiBVision-to-text bridge69.2M0.13 GiBTotal 29.777B 55.46 GiB

Because Muse Glimmer is dense, every generated token passes through all 52 text blocks. There are no routed experts waiting unused in memory. This gives predictable execution, but at low batch sizes it also makes decoding heavily dependent on repeatedly reading a very large set of weights.

Every fourth layer sees everything

The 52 text layers follow a strict repeating schedule:

There are therefore 39 sliding-attention layers and 13 full-attention layers. The local window is 2,048 tokens.

A local layer at position i can directly read only the recent interval ending at i. But local receptive fields compound with depth. Ignoring boundary effects, three stacked causal windows expose a token indirectly to roughly 1 + 3 × (2048 − 1) = 6,142 positions: 6,141 predecessors plus the token itself. The global layer that follows does not receive raw isolated tokens; it receives representations...