Skip to content
Betav0.62.0
All articles

Muse Spark Open: what an 816B open-weight coding model asks of you

Meta released weights for Muse Spark Open, an 816B mixture-of-experts model for coding agents: the hardware it needs, its license and its own benchmarks.

By The SpanDock team

6 min read

A bar diagram of the memory needed to hold Muse Spark Open: about 1.5 TB for the BF16 checkpoint, at least 700 GB of GPU memory for NVFP4, and roughly 300 to 350 GB for the 2-bit and 3-bit builds tested on a 512 GB Mac

On 15 October 2026 Meta released the weights of Muse Spark Open, a mixture-of-experts model with 816 billion parameters, 42 billion of them active per token, and a context window of one million tokens. Meta built it for coding and agentic work and calls it "the most capable US open-weight model to date". For teams that want a strong coding model they can run on their own infrastructure, for data residency, cost at scale or independence from a provider, it is a serious new option. It is also a large commitment, and the details of hardware, license and benchmarks matter more than the headline.

What Meta released

The model card describes a model that takes text, images, video and audio as input and produces text. Each of its 62 layers has 256 experts, of which a router picks 8 per token. The weights come in two formats, BF16 and NVFP4, a 4-bit format for NVIDIA Blackwell GPUs. The model is offered through several hosted inference providers, and the weights can be downloaded from Hugging Face and three cloud model catalogues.

Two practical details stand out in Hugging Face's write-up. Hugging Face says reasoning can't be turned off: the effort setting goes from low to xhigh, and xhigh is the default. And the chat template is a channel-based format that separates reasoning, commentary and the final answer, so your serving stack and agent harness need the matching reasoning and tool-call parsers.

What it takes to run

A mixture-of-experts model computes each token with a fraction of its parameters but has to hold all of them in memory. Hugging Face puts it plainly: deployment "needs the memory of an 816B-parameter model, but runs at the much faster speed of a 42B model".

SetupWhat the sources say
BF16Checkpoint about 1.5 TB; the model card asks for 2 TB of GPU memory; Hugging Face ran it in transformers across 4 nodes of 8 H200 GPUs
NVFP4At least 700 GB of GPU memory (model card); runs on one B200 node, or four GB300 GPUs with SGLang (Hugging Face)
Hosted endpointHugging Face's recipe (the NVFP4 checkpoint with SGLang) uses 8 RTX Pro 6000 GPUs at a 131,072-token context, or 8 H200 GPUs for the full million tokens
DesktopMeta says it runs on two Mac Studios with M5 Ultra; Hugging Face tested 2-bit and 3-bit builds on one 512 GB M3 Ultra at about 18 to 21 tokens a second

The long context has its own cost. By Hugging Face's arithmetic, the attention cache takes about 250 KB per token in BF16, or about 266 GB for a full one-million-token context, on top of the weights.

The sources differ in emphasis. Meta's announcement lists vLLM among the engines the model runs on, while Hugging Face describes the vLLM reference integration as supporting text and image input with the NVFP4 checkpoint on Blackwell GPUs, at a 128K serving context in its example. The desktop claim also needs reading carefully: the Mac runs use heavily quantised weights, and the model card notes that quantised inference "may show minor quality differences in edge cases". At around 20 tokens a second, a long agentic task that writes and rereads a lot of code will be slow. And Hugging Face's own file counter shows 822B parameters against Meta's 816B; the sources don't explain the difference.

The license

The weights are released under the Muse Model License, which Meta describes as having "limited commercial terms". Downloading from Hugging Face requires an access request. The license text on the model page grants broad rights, including use, modification, fine-tuning, distillation and sale, with conditions that matter for engineering teams:

  • Attribution. Every product or service that uses the model or a derivative must display "Built with Muse Spark Open" in its interface, documentation, website or settings. "Derivatives" includes any model trained, fine-tuned or distilled using the model or its outputs. If you use it to generate training data for an internal model, that model is a derivative.
  • Model-as-a-service. A licensee whose group earns more than 20 million US dollars in gross revenue in any twelve months, and offers AI models to third parties through an API or similar, must notify Meta and sign a separate agreement before offering this model that way. The clause does not apply to internal use, research, or using the model to power features of your own product that isn't a model service.
  • Usage policy. An attached policy prohibits a list of uses, including creating malicious code.

For most internal coding-agent deployments, the model-as-a-service clause won't apply, but the attribution clause and the outputs-as-derivatives definition will. Legal review should happen before, not after, a pilot turns into a platform.

What the benchmarks show

Meta's benchmark table compares Muse Spark Open with seven other open-weight models, most at their highest reasoning settings. The numbers are self-reported, and some competitors have gaps where scores weren't available. Read row by row, the picture is mixed rather than dominant:

  • It leads its comparison set on MCP-Atlas (89.2) and JobBench (61.8), two agentic benchmarks.
  • On the coding rows it trails several others. On DeepSWE 1.1 it scores 60, against 67 and 68 for GLM 5.3 and Kimi K3. On Terminal-Bench 2.1 with the Terminus 2 agent it scores 76.4, against 85.0 for Kimi K3 and 83.9 for GLM 5.3.
  • Its safety rows are where it stands furthest apart: on the two adversarial tests, where lower is better, its scores are far lower than the others'. The FORTRESS row also gives a second score (ORS) on which it is higher than most; the table doesn't define either abbreviation.

So "most capable US open-weight model" is a narrower claim than it sounds, and the qualifier carries weight: in the same table, other open-weight models score higher on the coding benchmarks a coding team would care about most. As earlier articles on Terminal-Bench 4.0 and SWE-Bench Pro Verified showed, harness and setup move these numbers a lot, so your own tasks are the test that counts. Meta's announcement also says a full evaluation report is still to come; until it is published, the model card is the most detailed public account of the safety testing.

What it means for engineering and security leaders

  • Self-hosting is now a capacity-planning question. A useful deployment means hundreds of gigabytes of GPU memory before any context. Price that against hosted inference at your real token volumes, including the reasoning tokens the model always spends.
  • Model choice and license choice are the same decision. The attribution and derivative terms follow the model into anything built from it or its outputs.
  • Guardrails stay your job. The model card recommends deploying it inside a broader system with guardrails, and human confirmation for irreversible actions in agentic use. Self-hosted, there is no provider-side filtering in front of it.

Practical takeaways

  • Trial it through a hosted provider first, on your own coding tasks, before buying or reserving hardware.
  • Set the reasoning effort deliberately (the model card recommends high or xhigh for coding and agentic tasks, low or medium for shorter answers) and measure the token cost of each.
  • Check that your serving engine supports the input types you need; the vLLM reference integration, for example, covers text and images only.
  • Send the license to legal with two questions: where the attribution must appear, and whether any planned use of outputs creates a derivative.
  • Compare it with the models you already use on the same tasks and the same harness, not on the published table.

If your tools report to SpanDock, the Models page in model proxy and budgets ranks the models your tools used by spend, tokens, calls, speed, reliability or cost per million tokens, and shows how each moved since the previous period, which gives a like-for-like view of a trial against your current models. Where a tool reports tokens but no cost, prices come from a catalogue, and you can set your own under Settings → Model prices.

Sources

  1. Meta: Introducing Muse Spark Open (15 October 2026)
  2. Hugging Face: Welcome Muse Spark Open, open-weight frontier multimodal mixture-of-experts model from Meta
  3. Muse Spark Open model card and Muse Model License (Hugging Face)
Cookie categories

Details: Cookie Policy.