Meta Muse Spark Open: 816B Open Weights, Licence, Hardware

Meta released Muse Spark Open on October 15, 2026. Its launch post calls it "the open weights version of Muse Spark", the frontier model behind Meta's hosted Muse products. The weights are an 816-billion-parameter mixture-of-experts transformer with about 42 billion parameters active per token, a one-million-token context, and text, image, video and audio input with text output. They ship under the Muse Model License, which requires a "Built with Muse Spark Open" notice in any product that uses them and a separate written agreement from model-as-a-service providers above $20 million in revenue.

Two things make this a post rather than a row in our October release tracker. The first is scale: Hugging Face's write-up calls it "the most capable US open-weights model to date", and the smallest official checkpoint is still about 530 GB, with the model card asking for at least 700 GB of VRAM to run it. The second is the licence, which is short, specific, and friendlier to most businesses than its revenue clause first suggests. A company building an internal coding agent on these weights owes Meta an attribution line and nothing else.

Everything below comes from Meta's launch post, Meta's model card on Hugging Face and Hugging Face's own technical write-up, all read on October 16. Where the three disagree on a number, each figure is attributed to its source rather than averaged. We have not run the model. The benchmark comparison against Kimi K3 and GLM 5.3 lives in a companion post; this one is about whether you can use it, run it and call it.

The launch post is signed by ten members of Meta Superintelligence Labs and is written for people who deploy models, not for people who read about them. Most of its length is serving recipes: SGLang and vLLM flags, a TensorRT-LLM configuration for a four-GPU Blackwell node, quantised builds from AMD and Intel, and fine-tuning paths through TorchTitan, NVIDIA NeMo, Hugging Face TRL and two hosted providers. It positions the model for agentic work, naming coding agents and customer-service agents as the intended jobs.

What this release is not: a new model. Muse Spark was already available as a hosted service through Meta's own products, and our evaluation of Meta's Muse agent access and pricing covers that side. The news is that the weights are now yours to download, which changes who can run it, what it costs and what you owe Meta. It is also a different animal from Meta's 30-billion Glimmer release in August, a dense model distilled from Muse Spark and shipped under Apache 2.0 for local agent work; we covered that in our Muse Glimmer post. Glimmer is the model for one machine. Spark Open is the one you run on a rack.

A mixture-of-experts model keeps all of its parameters in memory but uses only a fraction of them for each token. Hugging Face's write-up gives the shape: 62 layers, 256 experts per layer, eight experts chosen per token, with the experts holding about 97% of the weights. The 42 billion active parameters set the compute cost per token, which is why the model can be fast on hardware that fits it. The 816 billion total set the memory cost, which is why so little hardware fits it. As Hugging Face puts it, "All 256 experts stay in memory, so deployment needs the memory of an 816B-parameter model".

The multimodal input runs through a separate 1.8-billion-parameter perception encoder, per Hugging Face, and audio is tokenised at one token per 80 milliseconds, so a ten-second clip costs 125 tokens. Output is text only. There is no image or speech generation here, and a team expecting a multimodal assistant should read "image, video and audio in" as understanding, not production.

That last row is the one capacity planners miss. Hugging Face computes about 250 KB of key-value cache per token in BF16, which is roughly 266 GB for a full one-million-token context. A deployment sized to hold the 530 GB NVFP4 weights and nothing else cannot serve the context the model advertises. Hugging Face's vLLM example sets a 128K serving context (--max-model-len 131072). The failure case is a team that benchmarks a long-document workflow on a hosted API, then self-hosts on the minimum GPU count and finds the same prompts rejected.

The Muse Model License, in the version headed "Muse Spark Open" and dated October 15, 2026, has two clauses that matter to a buyer. The first is attribution: a licensee must prominently display the words "Built with Muse Spark Open" in the product's user interface, documentation, website or settings menu. That applies to every product, at every size, including internal tools, since documentation or a settings menu also satisfies it. The second is a revenue trigger that applies only to model-as-a-service businesses: a provider whose aggregate gross revenue exceeds $20 million in any consecutive twelve months must notify Meta and sign a separate written agreement before offering the model as a service.

The exemptions are the useful part. The licence states that internal use, research, and commercial activity that is not model-as-a-service fall outside the trigger, and so does using the model as a component that powers features of your own product. A $200 million software company that embeds Muse Spark Open in its own support agent owes attribution and nothing more. A $25 million inference host that sells tokens from the weights needs Meta's signature. The card also states the model is not intended for anyone under 18, which matters for consumer products. Our open-weight licence audit compares this shape against Kimi K3's, GLM 5.3's and the Apache and MIT releases.

The failure case is an agency one. A studio builds a client's customer-facing assistant on the weights and ships it with the client's branding and no notice. The licence does not care that the client's revenue is below any threshold; the attribution clause has no threshold. Put the line in the settings menu before launch, and put it in the statement of work so the client knows it is there.

Three sources give three sets of numbers, and they do not quite agree. Meta's launch post puts the BF16 checkpoint at about 1.6 TB and the NVFP4 checkpoint at about 530 GB, and says NVFP4 runs on four Blackwell Ultra GPUs or eight H200s. Meta's model card states minimums the other way round, as VRAM: at least 700 GB for NVFP4 and at least 2 TB for BF16, which leaves room for the cache and activations. Hugging Face measures the BF16 safetensors at about 1.5 TB and runs the BF16 reference across four nodes of eight H200s, 32 GPUs in all. Read the smaller figures as file sizes and the larger ones as what you need to own.

Below the official checkpoints sit partner and community builds. AMD published an FP8 build for its MI355X and an MXFP4 build for the MI350X and MI355X, with the FP8 build matching BF16 on GSM8K by AMD's measurement. Intel published an MXFP4 build for four 160 GB Crescent Island cards and a weight-only INT4 build for Xeon CPUs. Unsloth's GGUF quantisations go down to roughly 2-bit, and Meta says the smallest fits in about 300 GB of combined RAM and VRAM. Our hardware-matching guide for open-weight coding models explains what a 2-bit quantisation costs in output quality; the short version is that the number of parameters stays on the box and the model inside it changes.

The line from the launch post that will travel furthest is about Apple hardware. Meta describes running the NVFP4 checkpoint through MLX on two M5 Ultra Mac Studios with 512 GB of unified memory each, or four with 256 GB each, connected over Thunderbolt 5 with RDMA. The model card repeats that the model is optimised for two M5 Ultra Mac Studios. The sentence Meta attaches to it is a claim about the field, and we print it as Meta's:

Two readings. "Desktop" here means about a terabyte of unified memory across two or four machines on one desk, which is a different purchase from a workstation. "US" is doing work in that sentence too: the companion comparison shows Kimi K3 and GLM 5.3, both Chinese releases, ahead on several of Meta's own benchmark rows. Hugging Face's write-up gives the only independent local figures we have: a 2-bit llama.cpp quantisation at 18 tokens per second using 304 GB on a single 512 GB M3 Ultra, and an oMLX 3-bit build at about 21 tokens per second in 344 GB. Those are previous-generation Apple numbers on heavily quantised weights, and they are the floor, not the experience Meta is describing.

Our M5 Ultra Mac Studio economics post prices the two-machine configuration against a year of hosted tokens. The failure case is the one it warns about: buying the hardware for a demo and finding that a single long-context session consumes most of the memory the weights left free.

Most teams will never download the weights, and the launch is arranged so they do not have to. Meta lists seven hosted inference providers on day one: Baseten, Fireworks AI, Groq in limited preview, Modal, Nebius, OpenRouter and Together AI, the last with a stated 99.9% service level. The model also appears in three cloud catalogues, Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry. Meta's launch post gives no price of its own for the model and does not list it on Meta's API.

The one route quote we can cite is OpenRouter's. On October 16 the meta/muse-spark-open route listed $1.25 per million input tokens, $4.25 per million output tokens and $0.15 per million cached input tokens, with a 1,048,576 token context. That is identical to the route for Meta's hosted Muse Spark 1.3, which is a routing quote and not a statement that the two models cost the same to serve. A route price can change without notice and differs by provider behind it; treat it as a number to confirm on the day you buy.

The model card is unusually direct about how to call the model. Sampling is temperature 1.0, top-p 1.0 and top-k disabled. Reasoning effort has four levels, low, medium, high and xhigh, with xhigh as the card's default, and the card recommends high or xhigh for complex problem solving, coding and agentic tasks. The Hugging Face Transformers example in Meta's launch post, by contrast, sets effort to low, and OpenRouter's route exposes the same parameter with its own default. Three doors, three defaults.

Why it matters: every benchmark figure Meta publishes for this model was run at xhigh. A team that evaluates through a host at the host's default and finds the model weaker than advertised has tested a different configuration, not disproved the card. The example is the simplest possible one. Send the same coding task at low and at xhigh, compare the token counts and the answers, and decide which you are paying for before the agent runs ten thousand times. The failure case is a cost one in the other direction: an agent left at xhigh on a high-volume, low-stakes task burns output tokens at $4.25 per million on reasoning nobody reads.

Two of Meta's own benchmark rows frame the fit, and they point in different directions. On MCP-Atlas, a tool-use suite, Meta reports Muse Spark Open at 89.2 against 82.3 for Kimi K3 and 84.2 for GLM 5.3. On Terminal-Bench 2.1 with the Terminus 2 agent, Meta reports 76.4 against 85.0 and 83.9. Both are Meta's runs on Meta's harness choices, with Muse at xhigh and the others at their maximum settings. Read together they say: strong at calling tools, behind the two Chinese open models at terminal work. The full fourteen-row table is in the companion comparison.

If your team is deciding whether an open-weight coding agent belongs in your own account or behind a hosted route, the licence reading, the capacity arithmetic and the effort-level benchmark are all work our AI transformation team runs, including the comparison against the models you already pay for.