---
title: "Meta releases a 30-billion-parameter AI model built for laptops"
description: "Meta's Muse Glimmer is a 30B-parameter open-weights model built to run on consumer hardware. How quantization and speculative decoding made it fit."
dek: "Muse Glimmer is designed to run entirely on a well-specified personal computer, with no cloud connection. Two engineering tricks — compression and guesswork — are what make that possible, and the people already running it report a gap between the claims and the desk."
published_at: "2026-08-13T17:39:41.902Z"
updated_at: "2026-08-13T17:39:41.902Z"
tags:
  - "AI"
  - "Consumer"
  - "Infrastructure"
source_url: "https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model"
source_domain: "research.meta.ai"
canonical: "https://hex37.com/meta-releases-30-billion-parameter-ai-model-built-for-laptops"
---

When you ask an AI assistant to sort through your calendar, draft a reply or fix a broken piece of code, the request almost always leaves the machine in front of you. It travels to a data centre, is processed on hardware worth more than a car, and comes back. The convenience is real and so is the dependency: no connection, no assistant. The question a growing amount of engineering effort is now pointed at is whether that trip is necessary — whether a model capable enough to actually do things on your behalf can live on a computer you already own.

Meta Superintelligence Labs has [published its answer](https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model) in the form of Muse Glimmer, a model with 30 billion parameters — the internal numerical settings a [neural network](https://en.wikipedia.org/wiki/Neural_network) adjusts during training, and the rough measure of how much it has absorbed. The weights are [open source](https://en.wikipedia.org/wiki/Open-source_software) under a permissive licence, downloadable by anyone, and the pitch is specific: this is meant to run on a Mac or a PC with a single consumer graphics card, doing the kind of continuous background work that until now has meant a monthly subscription and a network connection.

## Why the capable models stayed in the data centre

The models that are good at this sort of work — reasoning through a problem, writing and debugging code, calling external tools like a calendar or a file system and stringing the results together — are good at it because they are large. A [large language model](https://en.wikipedia.org/wiki/Large_language_model) learns those behaviours as statistical patterns across an enormous amount of text, and more parameters generally means more of them. But every one of those parameters has to be physically held in memory while the model is running. That is the hard ceiling. A [graphics processing unit](https://en.wikipedia.org/wiki/Graphics_processing_unit) in a consumer machine has a fixed amount of fast memory, and at full precision a 30-billion-parameter model needs more than 55 gigabytes of it — comfortably beyond anything sold to consumers. So the models went where the memory was, and the assistants built on them stayed tethered.

What changed the calculation was work done largely in the open, by researchers and hobbyists showing that a smaller model, if it is trained carefully enough, can get close to frontier-level performance on a narrow set of tasks. Not everything, but the things you actually want an agent to do. That result is what makes a deliberately small agent model worth building rather than simply a worse version of a big one.

## Teaching a small model what a large one already knows

Muse Glimmer was not trained from raw text alone. It was trained on the outputs of Muse Spark, Meta's much larger foundation model, using a technique called distillation: instead of only learning to predict the next word in a document, the smaller "student" model learns to reproduce the larger "teacher" model's internal probability judgements about what should come next. It inherits something of the teacher's reasoning rather than rediscovering it from scratch.

That was the first phase. A second round of training pushed the model through longer documents and heavier agent-style tasks with detailed traces of reasoning attached. A final round combined supervised examples with reinforcement learning across general, coding and agentic problems. One behaviour was trained for explicitly: when a tool call fails or returns something unexpected, the model is supposed to work out what went wrong and try again, rather than stop.

## Compressing 55 gigabytes into 20

None of that would matter if the model still needed 55 gigabytes. The fix is quantization — storing each parameter at roughly 4-bit precision instead of full precision, in effect rounding every number to a coarser scale. The language model drops below 20 gigabytes, which leaves room on a 24- or 32-gigabyte machine for everything else that has to run alongside it: the working memory that holds the current conversation, the separate encoder that lets the model read screenshots and charts, and a small helper model explained below. Meta says it checked that the compression causes minimal or no degradation on agentic tasks, which is the claim the whole exercise rests on.

Fitting is only half the problem. A local agent that takes minutes to decide its next step is not an agent, it is an interruption. Language models normally produce text one token at a time, each waiting on the last, which is painfully visible during long chains of reasoning. Muse Glimmer ships with a lightweight companion model — a "drafter" — that guesses whole blocks of tokens ahead. The main model then checks those guesses all at once, keeping the correct ones and fixing the rest. Because every token is still verified by the full model, the output is identical to what slow generation would have produced; it simply arrives faster. Meta has also made the model work with the tools developers already use to run models locally, since a model that requires a bespoke setup is a model nobody adopts.

So the answer to the memory problem and the answer to the speed problem are separate pieces of engineering, and neither would have been sufficient alone. A model that fits but crawls is a demo; a fast model that does not fit is irrelevant. Local agents become plausible only at the point where both are solved at once, on top of a model small enough to have been worth shrinking in the first place.

## What it does on an actual desk

Plausible is not the same as delivered. People running the model on real machines report a picture noticeably rougher than the launch material. One person running it on an older Mac mini with 32 gigabytes of memory got good results and found it slow enough that the recommended workflow was to give it a task and go outside for a while. The hardware floor is also a real cost: several people point out that 32 to 64 gigabytes of memory is not a given, and that a 64-gigabyte laptop of the right generation runs past €4,000 in Germany. That is a different kind of barrier from the one Meta removed.

The trained-for failure recovery drew the sharpest criticism. Someone who ran the model at full precision on a machine with 120 gigabytes of memory — no compression involved — handed it deliberately broken code and watched it loop, each pass digging further into a wrong theory, eventually debating whether an unusual compiler was to blame. Whatever the benchmarks measure, that is not what recovery looks like in use. And those hoping to squeeze the model smaller still should be cautious: people experimenting with more aggressive compression, below 3 bits per parameter, have yet to report results worth using.

The technical barrier to running a capable agent on your own hardware has genuinely moved. Whether anyone moves with it is a separate question. Cloud services update themselves, are supported by vendors, and cost nothing up front. Local models ask you to buy the memory, manage the files and keep up with the ecosystem yourself. Removing the reason people could not run models locally is not the same as giving them a reason to.