Meta Muse Spark Open: Licence Terms, the Hardware Bill, and What Its Safety Training Promises

Meta released the weights of Muse Spark Open on October 15: 816 billion parameters, 42 billion active per token, a 1-million-token context, and input in text, images, video and audio. Meta trained it for agentic coding, calls it the most capable US open-weights model so far, and gave this version extra safety post-training so that it resists misuse better as a standalone model without system guardrails.

Three questions matter more than the headline: what the licence asks of you, what the model costs to host, and what safety training can promise once anyone can change the weights. I read the announcements, the model card, the methodology report and the licence. Every number below is reported by Meta unless I say otherwise, and I note where Meta took a row from Artificial Analysis or Scale AI. I have not run the model.

Muse Spark Open specifications

Source: model card and Hugging Face API metadata.

The checkpoint is about 6 billion parameters larger than the name, partly the 1.8-billion-parameter perception encoder. Budget from the files.

Read the Muse Model License before you build on it

The licence opens like MIT: use, modify, fine-tune, distil, redistribute and sell, free of charge. Four conditions change the picture.

• Attribution, for everyone. Every product or service that uses the model or a derivative must display "Built with Muse Spark Open" prominently, in its interface or in its documentation, website or settings. There is no size threshold.
• Derivatives include distillation. A model trained, fine-tuned or distilled from the software or its outputs carries the licence, the usage policy and the display duty. Meta lists synthetic data generation as an intended use, so this will come up.
• Hosted model services. If your group offers API access to AI models as a service and its combined gross revenue exceeds $20 million in any 12 months, you must notify Meta and sign a separate agreement first. Internal use, research, and features of your own product that is not a model service are excluded.
• The usage policy is part of the licence. Among other things, it prohibits generating malicious code and deliberately removing safety measures, and it makes a safe end-user deployment your obligation.

Sources: the Muse Model License, my posts on Kimi K3 and Qwen3.8, and the DeepSeek V4.1 Flash repository. Revenue thresholds are per 12 months.

Muse is the strictest of the four on attribution, and the only one gated on Hugging Face. The access form asks for your full legal name, date of birth, organisation and job title, and approval is manual, so every engineer and build pipeline that pulls the weights needs an approved account. The licence then allows redistribution, so the gate controls the first download, not the last.

In short, an internal coding agent needs a line in its documentation, a SaaS product needs the display line from its first release, and a hosted inference business above the threshold needs Meta's signature. I am an engineer, not a lawyer. GLM-5.2 and DeepSeek ship under MIT, which may settle it for some teams.

The hardware bill: half a node to load, much more to fill

Meta's card asks for at least 700 GB of GPU memory in NVFP4 and 2 TB in BF16. The BF16 files are 1.64 TB and the NVFP4 files 533 GB, and by my arithmetic the second figure checks out: 773.1 billion parameters at 4 bits with one scale byte per 16 weights, plus 48.8 billion kept at BF16, comes to 533.0 GB.

At 288 GB per B300, my count gives three or four GPUs for NVFP4 and one 8-GPU node for BF16. Kimi K3's published vLLM route is eight B300s, and Qwen3.8's NVFP4 recipe uses a full B300 node. Muse needs about half the hardware to load.

The context is where the bill grows. The card mentions no sliding-window layers. If every layer keeps a full cache, which the card suggests but does not state, each token costs 126,976 cached values (62 layers × 16 heads × 64 × 2): about 127 KB at FP8, or 127 GB for one session at a million tokens. By my arithmetic that is 2.7 times Qwen3.8's per-token cache, because Qwen keeps a growing cache in only a quarter of its layers.

So Meta's 700 GB leaves room for roughly one full-length FP8 session above the NVFP4 weights, before activations and overhead. I would treat it as the floor for short contexts and measure the rest.

Meta also says two M5 Ultra Mac Studios, at up to 512 GB each, can run the model through MLX, without giving a speed. The release's Helion kernels are reported at 1.03 to 3.95 times faster per kernel on NVIDIA GB300, and 3% faster end to end on AMD MI350. Plan with the second number.

Muse Spark Open benchmarks: which rows are like for like

Meta's methodology report says where each number came from, which changes how the table reads.

Source: Meta's model card and evaluation methodology report. Effort was xhigh for Muse and Qwen3.8, max for Kimi K3. The DeepSWE row pairs an Artificial Analysis run of Muse in Meta's own harness with each vendor's figure for the others.

Terminal-Bench 2.1 is the cleanest comparison, because every model ran in the same harness. There, Muse trails Kimi K3 by 8.6 points and Qwen3.8 by 5.6. In the harnesses their vendors chose, those two models scored 88.3 and 86.6, which is 3.3 and 4.6 points higher. Harness and run settings can be worth that much.

Muse leads on MCP-Atlas tool use and, by a long way, on resisting attacks. On agentic coding, the job it was built for, Kimi K3 and Qwen3.8 still score higher in the one common harness. Meta's claim is about US models, and the qualifier is doing some work.

What safety post-training can promise once the weights are public

StrongREJECT v2 is Meta's internal set of 202 disallowed behaviours, attacked with jailbreak libraries, adversarial developer prompts and an adaptive multi-turn attacker. Muse's attack success rate is 0.5, against 65.6 for Qwen3.8 and 66.6 for Kimi K3. Meta also reports that Muse refused 99.2% of jailbreaks on its internal cyber benchmark, where Kimi K3 refused 75.5%.

That buys something real. Open weights get deployed bare, and for a team that never adds a guard model, a checkpoint that refuses more is a safer default. The same documents show four limits.

• Modification voids the numbers. The card says its results describe the released checkpoint and should not be assumed for modified models. TorchTitan supports fine-tuning, LoRA and reinforcement learning on it from launch day. How much a LoRA run undoes is my question, not a published result.
• The licence is the only lock. The usage policy forbids removing safety measures. That is a contract term, not a technical control.
• The adaptive test is text only. StrongREJECT v2 uses text, for a model that also takes images, video and audio.
• Agentic risk has no number. The card lists destructive changes in coding-agent workflows as an evaluated area, and publishes no result.

There is a cost too. On FORTRESS, Muse refused 17.4% of benign prompts, against 2.7% for Kimi K3. Those prompts sit in sensitive domains, not ordinary coding, but they show which way the model leans. When Hugging Face investigated its July intrusion, hosted models refused the forensic work, and it ran GLM-5.2 on its own infrastructure instead.

Meta's card reaches the same conclusion: deploy the model inside a system with guardrails, require human confirmation for irreversible agentic actions, and protect internal assistant messages from manipulation. Safety training is the floor.

I took the same view in Career Rafeeq, the AI SaaS product I built, for a different kind of safety: confident wrong answers rather than misuse. It has deterministic safety nets over model output, a verdict score-floor guard and a job-description validity early exit, so model uncertainty degrades to a safe default instead of cascading into a confident wrong answer. Those guards live in code, so a different model cannot remove them, and a model swap has to pass the evaluation harness before merge. Open weights call for the same split: the training is the model being careful, and your system decides what happens when it is not.

What I would test before adopting Muse Spark Open

• Refusals on your real work. Run a week of your own coding and operations tasks, security-adjacent ones included, and count refusals.
• Your harness, not Meta's. Kimi K3 and Qwen3.8 moved by 3.3 and 4.6 points on Terminal-Bench between setups.
• Memory and precision. Measure cache use at your context sizes, and compare NVFP4 with BF16 on your own tasks.
• Safety after your fine-tune. Re-run a jailbreak and refusal suite on anything you tune. Meta's numbers stop applying there.
• The licence against your product. Decide where the attribution line goes, whether you count as a model service, and what a distilled model would inherit.

So Meta trained a model to hold up without system guardrails, then recommended, on the same card, that nobody run it without them. I agree with both halves.

Sources

• PyTorch, Muse Spark Is Now an Open-Weights Model, October 15, 2026
• Meta AI Research, Introducing Muse Spark Open, October 15, 2026
• Muse Spark Open model card and Muse Model License, October 15, 2026
• Muse Spark Open NVFP4 weights, October 15, 2026
• Meta, Muse Spark Open Evaluation Methodology, October 2026
• DeepSeek V4.1 Flash repository and MIT licence, September 10, 2026

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and model evaluation.