Evidence at a glance
Open Weights Do Not Mean a Low Barrier
On October 15, 2026, Meta released Muse Spark Open, an open-weight model in the Muse family aimed at coding, agent workflows, and multi-step reasoning. It uses a mixture-of-experts architecture, accepts text, images, audio, and video, and produces text. Meta describes it as built for developer tasks such as understanding codebases, making multi-file refactors, debugging over long sessions, and calling tools.
The release is worth a technical leader’s attention because it exposes a substantial gap between being open and being practical to run. Teams can download the weights and attempt self-hosting, but that does not mean the training data and full training process are also public, or that an ordinary single machine can serve the model. Meta also positions it among the most capable US open-weight models to date. That is a product claim, not an independently established benchmark result in the available material, and should not be treated as one.
MoE Saves Computation, Not Weight Storage
To understand the deployment cost, separate total parameters from active parameters. Muse Spark Open has approximately 816 billion parameters, with about 42 billion active for each token. Each layer of the language model contains 256 experts, and a router selects eight to participate in computing a given token. The experts account for about 97 percent of the total parameters. Sparse routing therefore reduces the computation performed per token, but it does not remove the weights belonging to the other experts.
That is the central trade-off: all experts must remain in memory, even though only a subset is used for each token. Put differently, 42 billion describes the per-token computation scale, not the model capacity required for deployment. The BF16 weights occupy about 1.5 terabytes. MoE does not turn that storage requirement into the cost of a 42-billion-parameter model. A team that estimates its GPU needs from active parameters alone will misjudge the deployment budget.
Different Deployment Paths Solve Different Problems
Meta’s deployment examples show the practical limits imposed by the model’s size. The BF16 weights can run across four nodes, each with eight H200 GPUs, using tensor parallelism. NVFP4 is a 4-bit version intended for NVIDIA Blackwell GPUs. Meta says its accuracy loss is negligible and documents a path using a single B200 node. Lower precision reduces the storage burden, but this is not a universal compression method independent of GPU generation.
Inference frameworks are not model-shrinking tools either. Meta provides self-hosting recipes for llama.cpp, vLLM, and SGLang. The research material also mentions hosted services, an Apple MLX adaptation, and an official demonstration on two M5 Ultra Mac Studios. These options reduce integration and configuration friction, but they have different requirements. A desktop demonstration does not establish that every desktop can run the model, and an inference framework cannot make the complete set of expert weights disappear.
A Million-Token Window Is Also a Resource Budget
Muse Spark Open has a context limit of 1,048,576 tokens, and text, images, video, and audio all enter the same language-model context. A perception encoder converts images and video frames into tokens, while a separate audio encoder processes audio. The supplied material gives an audio rate of about 12.5 tokens per second and says video is sampled by default at two frames per second, up to 96 frames. Multimodal capability is therefore not simply a recognition module attached at the side. The inputs themselves consume context budget.
A long window also carries runtime costs. At BF16, the KV cache for a full context is about 266 GB and may compete with model weights for GPU memory. For a coding agent, code excerpts, tool results, screenshots, voice notes, and conversation history all draw on shared resources. A million-token limit means the model can accept a very long input. It does not mean that putting every work artifact into context at once is an efficient strategy.
Turn Capability Claims into Workflow Tests
Meta describes Muse Spark Open as an agentic model that can plan, act, observe, and self-correct. It also highlights the ability to work on code while examining screenshots, voice notes, or screen recordings. For development teams, that combination suggests a direction worth testing: bring codebase analysis, extended debugging, and multimodal evidence into a single tool-calling workflow rather than connecting separate, unrelated models. But a feature description does not prove reliable completion of tasks in a real repository.
Evaluation should account for quality, latency, and resource use together. Beyond whether a coding task is completed, record the memory required for the full weights, context and KV-cache use, multimodal prefill cost, and failures or recovery during tool calls. The material also says reasoning strength can be adjusted but cannot be turned off, so teams should check whether lower settings meet their task requirements. If a team lacks substantial multi-node resources or has no need for a long-running multimodal workflow, the control offered by open weights may not outweigh the cost of operating them. The sensible approach is to test the model in a clearly bounded workflow, not to substitute parameter counts or launch positioning for evaluation.