Meta's Muse Glimmer fits in 20GB. The permission model does not.

Meta has released Muse Glimmer, a 30-billion-parameter "agentic" model distributed under Apache 2.0 ^[1]. The point of interest is not the parameter count but the product it implies: an always-on assistant that, to be useful, wants deep access to contacts, email, calendar and the rest of a user's digital life ^[2], running entirely on consumer hardware ^[3].

Take the licence seriously first. According to the dev.to writeup on the release ^[20], Meta was for years read as one of the engines of the open-weights ecosystem before its strategy turned more opaque, with closed models and restricted distributions ^[4]. Apache 2.0 restores something concrete: you can integrate, redistribute and ship products with less legal ambiguity than under the more restrictive source-available licences ^[5], which for a product team means less lock-in and lower variable cost than an API ^[18].

The engineering is a stack of three known tricks aimed at one number. Muse Glimmer was distilled from a larger closed model, Muse Spark, using logit distillation, so the student imitates the teacher's token-by-token probability distributions rather than only its final answers ^[6]. A dense 30B at full precision would need tens of gigabytes ^[8]; the stated quantization target is a footprint around 20GB instead of over 55GB ^[7], roughly a 64 percent cut, or about 2.75x smaller ^[15]. That works out to about 5.3 bits per weight ^[16]. The writeup is blunt that this is often the difference between a model that will not start and one that actually runs on a 24GB card, at the cost of slightly lower quality and more sensitivity on certain classes of prompt ^[9]. Speculative decoding does the rest: a small model proposes a block of tokens, the large one verifies the block in a single pass and discards the bad guesses, buying throughput without much quality loss ^[10].

Now do the arithmetic an operator has to do. Twenty gigabytes of weights on a 24GB card leaves about 4GB ^[17] for the KV cache, the context, and the draft model that speculative decoding requires you to keep resident ^[10]. "Runs on consumer hardware" is doing real work in that sentence.

The harder problem is the one the writeup names correctly: deep access is not a feature, it is a trust model. The experiences users call magic - useful mail summaries, automatic follow-ups, contextual reminders - require reading and indexing mail and attachments, calendar metadata, an address book with relationships between people, and the ability to act: draft, send, create events, update tickets ^[14]. That forces an app architecture with granular scopes, revocation and auditing, secure storage for embedding caches and indexed files and logs, an explicit boundary between assistant and user for irreversible actions, and defences against prompt injection and data exfiltration ^[12]. Moving inference local reduces exposure to third parties but does not remove the risk; it relocates it ^[13].

On that last point the source is thin in a way worth stating: it says the cited prompt-injection results show a non-trivial share of attacks succeeding, without giving the figure in the text available ^[11]. For a model whose selling point is tool use across browser, mail and file system, that number is the benchmark that matters, and it is the one not yet in hand.