Running a model on your own computer is often framed as a tradeoff between privacy and capability. Small models fit on the device, while more ambitious agents that can inspect images, write code, and use tools across long tasks still seem to belong in a data center.

Muse Glimmer 30B, released by Meta under the Apache 2.0 license, tries to narrow that gap. It is a dense, multimodal 29.6-billion-parameter model with a context length of at least 131,072 tokens, designed for agent tasks on consumer hardware. Its smallest published quantization is about 17 GB, while the complete setup is intended to fit the weights, cache, visual encoder, and speculative decoder within a 24 GB memory envelope.

The release arrived with initial support in Ollama 0.32.7, currently limited to its MLX engine on Apple Silicon. Within the same window, the architecture landed in Transformers and gained llama.cpp support. This is more than another weight file becoming downloadable. It is a test of how quickly an agent-focused model can cross the layers required to become runnable.

What fits inside 24 GB

Glimmer accepts interleaved text and images and produces text. A dedicated visual encoder lets it interpret screenshots, charts, and documents, while the main transformer handles reasoning, function calls, and code generation. For a local agent, that combination matters more than any isolated score: the screen no longer has to be sent through a separate perception service.

Fitting almost 30 billion parameters on consumer hardware requires compression. Meta provides two quantizations at roughly four-bit precision. According to the model card, the 24 GB variant loses 1% on the average accuracy across 15 evaluations compared with full precision. This is a vendor measurement, not a guarantee for every workload. It still makes the engineering bargain explicit: memory use falls sharply in exchange for a measured loss on a defined test set.

The second technique is speculative decoding. A companion DFlash model proposes blocks of 16 tokens, and the main model verifies those proposals in parallel. Instead of drafting one word before considering the next, the system receives a short draft and approves or corrects several pieces at once.

In Meta’s published tests, that combination reached 233.4 tokens per second on an RTX 5090, up from 74.9 without speculation. On a MacBook M4 Max, it moved from 23.7 to 37.8 tokens per second. The measurements use batch size 1, greedy decoding, and a vendor-selected request set. They demonstrate the mechanism, but they do not promise the same speed in another application.

A model becomes a product only when its surroundings can receive it

Open weights are not enough. A runtime must recognize the architecture, load its quantization, place images in the token stream, and coordinate the main model with the speculative drafter.

Ollama 0.32.7 initially does that work on Apple Silicon. The change that added images to its MLX runner reveals the hidden complexity: visual references must be included in cache keys, image features should be encoded only when prefill reaches them, and the same positional state must reach both the target model and the speculative draft model. Local multimodality is also a scheduling and cache-consistency problem.

Transformers and llama.cpp incorporated the architecture only hours after the weights appeared. That shortens the distance between “the model exists” and “developers can try it through familiar tools.” Merged code, however, is not the same as mature support on every platform. Ollama itself calls the current availability initial and says NVIDIA, AMD, and broader platform optimizations are still to come.

In practical terms, a Mac with enough memory can already test the model in coding applications and local assistants through Ollama. Users on other hardware should check the actual runtime version, quantization, and available backend instead of reading a general announcement as universal compatibility.

Local does not automatically mean safe

Keeping execution off a cloud service reduces an important class of data exposure. It also enables offline use and can keep sensitive documents on the device. Those properties matter, but they do not answer the harder question: what happens when the model receives authority to act?

Glimmer’s model card recommends human confirmation for irreversible actions and additional system-level safeguards. Its own results explain why. In Meta’s Siren AgentDojo evaluation, the model retained 94.2 utility but showed a 28.4% attack success rate. The comparison Gemma4-31B scored 25.6%. Glimmer therefore combines strong task execution with resistance that remains far from sufficient for automatic trust when it encounters malicious instructions.

That limitation does not invalidate the model’s purpose; it makes the boundary tangible. A local agent still reads external content, launches programs, accesses files, and may operate authenticated sessions. If a page, document, or tool result tries to redirect its behavior, the absence of a connection to the model provider does not prevent local harm.

The practical consequence is not to grant more autonomy merely because the weights fit on a laptop. It is to build a local stack in which the operator controls the model, data, and execution while preserving least privilege, tool isolation, verifiable records, and confirmation before irreversible effects.

The boundary moved

Muse Glimmer shows that a substantial multimodal model, tuned for tool use and failure recovery, can leave the data center and reach a computer with 24 or 32 GB. Its rapid integration into open runtimes also shows that the ecosystem has learned to shorten the path from weights to useful execution.

But compressing intelligence does not compress responsibility. As the local agent becomes more capable, the discussion can no longer end with “the data stayed on the device.” The decisive question is which parts of that device the agent can reach, and who confirms what cannot be undone.