Meta Muse Spark Open Explained: 816B Open-Weight MoE Benchmarks, Hardware Math and License (2026)

If you saw the headline numbers for Meta's newest release, 816 billion parameters, a one million token context window, and a reported 1 TB of RAM to run it, you probably asked the same practical question most engineers asked: is this a model I can actually use, or a press release I can only admire? On October 15, 2026, Meta published Muse Spark Open, its first open-weight model in the Muse family, with weights on Hugging Face, a license of its own, and a launch partnership with Apple that centers on running the model on Mac Studios [1][2]. Four days later, most coverage still repeats the announcement. This post goes through the model card, the Hugging Face launch write-up, Meta's developer pages, and the independent reporting to answer the questions you need before spending money: what the architecture really is, how the benchmarks compare with the open-weight models you already know, how much memory each quantization needs (with the arithmetic shown), how to run it with vLLM, SGLang, llama.cpp, MLX or OpenRouter, and which clauses of the license can bite you.

If you have followed Meta's Muse releases, this is a different angle from our earlier coverage. We already wrote about Muse Wonder's benchmarks, pricing and active memory, the 30B Muse Glimmer agent model that runs on one GPU, the Muse Spark 1.3 contributor tier, and why Meta ended Llama. Here the focus is the open weights themselves and the engineering decisions around them.

TL;DR: Muse Spark Open in Ten Facts

• It is a sparse mixture-of-experts model with about 816B total parameters and about 42B active per token, 62 layers, and 256 experts per layer with 8 routed per token [1][11].
• The context window is up to 1,048,576 tokens, shared across text, images, audio and video, and the output is text only [1].
• Meta positions it for agentic coding and long-horizon software tasks and calls it the most capable US open-weight model to date [1][2].
• On Meta's own table it leads the listed open models on MCP-Atlas (89.2) and JobBench (61.8) but trails GLM 5.3 and Kimi K3 on Terminal-Bench 2.1 and DeepSWE 1.1 [7].
• Its Artificial Analysis Intelligence Index figure is 39 (Meta-reported), against 45 for GLM 5.3 and 44 for Kimi K3, and VentureBeat could not find an independent listing at launch [7][8].
• The BF16 checkpoint is roughly 1.5 to 1.65 TB depending on whether you count safetensors or the docs, and the NVFP4 checkpoint is about 530 to 537 GB [1][5][11].
• A full 1M-token KV cache adds about 266 GB on top of the weights in BF16 [1].
• The Apple route is two 512 GB M5 Ultra Mac Studios or four 256 GB ones, linked with Thunderbolt 5 and RDMA, which Engadget reports at roughly $38,000 for the four-unit version [5][6].
• The Muse Model License allows commercial use and fine-tuning but adds an attribution rule, a $20M revenue trigger for model-as-a-service businesses, and bans on military and critical infrastructure use [7][9].
• Hosted access is available from Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI, with Together and OpenRouter listings at $1.25 per million input tokens and $4.25 per million output tokens [8][12].

Step 1: What Muse Spark Open Actually Is

Muse Spark Open is the open-weight sibling of Meta's hosted Muse Spark line. Meta's developer page describes it as derived from the Muse Spark model released in August, with additional safety post-training so that it behaves more robustly as a standalone model without a provider's system guardrails around it [4]. That detail matters because the whole value of open weights is that nobody is standing between your prompt and the model, so the safety behavior has to live in the weights.

The model card lists the intended use cases plainly: multi-step reasoning, end-to-end agentic task completion, coding agents, tool use, multimodal reasoning, synthetic data generation, and LLM-as-a-judge evaluation [7]. TechCrunch adds the product context, noting that Meta paired the release with Muse Code, its AI coding terminal, and showed agentic workflows on a Mastodon client covering bug fixes, new features and a full build, plus a DaVinci Resolve demo that reviews and crops footage [2]. The Hugging Face write-up shows two further demonstrations: a Three.js 3D asset generator driven by the Pi coding agent on a 2-bit build, and a browser agent that sees only screenshots, prior actions, a system prompt and the URL, with no DOM access [1].

It helps to place it relative to the models Meta already shipped. Muse Glimmer is a 30B dense model with a smaller footprint and shares Muse Spark Open's tokenizer and vocabulary [1]. Muse Wonder is the hosted frontier model. Muse Spark Open sits between them in purpose: it is the largest set of Meta weights you can actually download, which makes it the only one of the three that you can fine-tune, distill and host yourself. The New Stack framed the launch as Meta's answer to China's best open-weight models [3], and Engadget quotes Meta's argument that the United States should not let Chinese labs lead in open AI [6]. For context, we have already covered several of those rivals in depth: Kimi K3, GLM-5.3, Qwen3.8-Max, and the Western alternatives Thinking Machines' Inkling, NVIDIA's Nemotron 3 Ultra, Mistral Large 4 and Reflection AI's Beam.

Open weight versus open source

The most common mistake in early coverage is calling this an open-source model. The license is Meta's own Muse Model License, which the model card and developer page both name, and which grants broad rights but is not an OSI-approved license [4][7]. The practical meaning: you can download, run, fine-tune, distill, merge and sell products built on it, but you accept conditions that Apache 2.0 or MIT would not impose. Step 7 covers those conditions clause by clause. Access to the weights on Hugging Face is also gated, and VentureBeat reports that the form asks for a full legal name, date of birth and organization name with corporate identifiers, and cannot be edited after submission [8]. If you work in a regulated environment, put that on your checklist before you plan a pipeline around a download.

Step 2: Inside the Architecture

The Hugging Face launch post is unusually specific about the architecture, which makes it possible to reason about the model instead of guessing [1]. The following numbers all come from that write-up unless noted.

The transformer backbone

The model has 62 layers and a hidden dimension of 8192. Attention uses grouped-query attention with 128 query heads and 16 key-value heads at 64 dimensions per head, plus several stabilizers: an output gate, output normalization, QK-norm and a learned residual gate. Input embeddings and the output layer are separate matrices of about 1.66B parameters each, so the embedding tables alone account for roughly 3.3B parameters that never touch the expert routing.

The expert layout

Every layer holds 256 experts and the router selects 8 of them per token. Each expert is a feed-forward block that projects 8192 to 4096 and back to 8192. Experts hold about 97% of all parameters. That single fact drives most of the practical decisions later in this post. Because 97% of the weights are experts, quantizing the experts aggressively shrinks the model nearly in proportion to the bit width, and Meta's own NVFP4 checkpoint quantizes only the experts and leaves the rest in higher precision [5]. It also explains why the active parameter count (about 42B) is so much smaller than the total: per token, each layer touches 8 of 256 experts, which is 1 in 32 of the expert weights, plus the always-on attention, norm and embedding weights.

Here is the part that is easy to miss. Active parameters determine how fast each token is computed, but total parameters determine whether the model fits in memory at all. A sparse model gives you the arithmetic cost of a 42B model with the memory bill of an 816B one. That is exactly why this model is cheap to serve from a data center that already owns the memory and awkward to run on a desktop that does not.

The perception stack

Muse Spark Open accepts text, images, audio and video and produces text [1][11]. The vision path uses a 1.8B parameter perception encoder with 50 layers, hidden size 1536 and 14 by 14 patches, using full attention every fourth layer and sparse attention elsewhere. Video goes through the same encoder as images, sampled at 2 frames per second by default and capped at 96 frames, though the sampling rate is adjustable. Audio is tokenized at one token per 80 ms, which is 12.5 tokens per second, so a 10 second clip costs 125 tokens. The audio path expects mono 24 kHz input. All of these modalities draw from the same 1,048,576 token window.

A worked example shows why that matters for planning. A 60 second screen recording at the default 2 FPS would yield 120 frames, but the cap of 96 frames means the sampling will have to be lowered or the clip split. A 10 minute meeting recording adds about 7,500 audio tokens (600 seconds at 12.5 tokens per second) before any transcript or video is counted. These are small compared with a million tokens, but they add up in long-horizon agent sessions that keep screenshots in context.

Reasoning effort

The chat template exposes a reasoning_effort setting with four levels, low, medium, high and xhigh, which the Hugging Face post maps to budgets of 16, 64, 256 and 512, and the default is xhigh. Reasoning cannot be fully turned off. The model card recommends temperature 1.0, top_p 1.0 and top_k disabled, and says to use high or xhigh for complex tasks [7]. The benchmark column that Meta labels "xhigh" is therefore the default configuration, not a special setting you have to unlock, but it also means your latency and token bill at default settings reflect a model that is thinking at its maximum budget. For simple extraction or classification calls, dropping to low is the first optimization to try.

The chat template uses Harmony-style channels (self, commentary and user), a format first introduced by gpt-oss, and Meta's developer page says the commentary channel lets the model state its intent before it acts, which is useful for logging and for human confirmation of risky agent steps [1][4].

KV cache: the number that decides your context length

The Hugging Face write-up gives 126,976 cached values per token. You can reproduce that from the attention config: 16 KV heads times 64 dimensions times 2 (keys and values) is 2,048 values per layer, and 62 layers gives 126,976. At 2 bytes per value in BF16 that is 253,952 bytes, about 254 KB per token. At the full 1,048,576 tokens the cache is about 266 GB, matching the figure in the launch post [1].

The takeaway is that long context is a second memory budget stacked on the weights. A deployment that fits the weights comfortably can still fail when several sessions each want a 400K token repository in context. Hugging Face's own recipes show the trade: its vLLM example caps the context at 131,072 tokens, and its Inference Endpoints recipe uses 8 RTX Pro 6000 cards for 131,072 context or 8 H200 cards for the full 1,048,576 [1]. For a deeper look at tricks that speed up decoding on models like this, see our explainer on speculative decoding, which matters here because Meta ships draft models for the launch.

Step 3: Benchmarks Against Open-Weight Rivals

Every number in this section comes from Meta's model card table, which compares Muse Spark Open at xhigh against Inkling, Nemotron 3 Ultra, Beam, Mistral Large 4, Qwen3.8-2.4T-A95B, GLM 5.3 and Kimi K3 [7]. Treat them as vendor-reported: VentureBeat notes that Meta's 39 on the Artificial Analysis Intelligence Index is its own figure and that it could not verify an independent listing at launch [8]. The model card says the full methodology lives in a separate research report, and the benchmarks are run with each model's preferred harness for some coding tasks, which makes cross-model comparisons less clean than they look.

Agentic and general results

Read the agentic table as a statement about what Meta optimized. Muse Spark Open takes the top score on MCP-Atlas at 89.2 and on JobBench at 61.8, narrowly ahead of GLM 5.3 at 61.4, and it scores 72.8 on Toolathlon Verified, essentially level with Qwen3.8 (72.5) and GLM 5.3 (73.0) and behind Kimi K3 (76.5) [7]. It is far ahead of the two models Meta singles out in its launch messaging. Against Inkling, it scores 61.8 versus 31.1 on JobBench and 89.2 versus 76.0 on MCP-Atlas, and against Nemotron 3 Ultra it scores 61.8 versus 27.2 and 89.2 versus 63.1 [7]. If your question is "does this beat Inkling and Nemotron 3 Ultra," the table says yes by wide margins. If your question is "does it beat the best Chinese open-weight models," the answer depends on the task.

The weak spot is GDPVal-AA v2, where it scores 1401 against 1653 for GLM 5.3, 1613 for Qwen3.8 and 1537 for Kimi K3 [7]. That benchmark is an Elo-style measure of economically valuable professional work, and the gap is large enough that you should test your own document-heavy workflows before assuming the agentic lead carries over.

Coding results

For a model marketed for coding, the coding table is the honest part of the story. On Terminal-Bench 2.1 with the Terminus 2 agent, Muse Spark Open scores 76.4, behind Qwen3.8 (82.0), GLM 5.3 (83.9) and Kimi K3 (85.0), and also behind Beam's 80.1 [7]. On DeepSWE 1.1 it scores 60 against 67 for GLM 5.3 and 68 for Kimi K3, while Mistral Large 4 posts 62 and Beam 44 [7]. SciCode is closer: 58.5 against 59.0 and 59.5. The pattern across independent coverage matches: the i-scoop analysis concludes that it leads on tool use and office tasks but trails on coding [10].

That does not make it a poor coding model. A score of 76.4 on Terminal-Bench 2.1 is 21.3 points above Inkling's 55.1 and 22.5 above Nemotron 3 Ultra's 53.9 [7]. What it means is that Meta's claim of being built for agentic coding should be read as "strong at planning, tool selection and long sessions" rather than "best raw bug-fixing score among open models." Early adopter comments on Meta's page point the same direction: Factory said it consistently selected the right next tool and kept responses compact, and Ollama pointed to strong tool calling and long-context behavior including parallel calls with structured outputs [5]. For a broader view of how to read coding leaderboards skeptically, our guide to SWE-bench, LiveCodeBench and contamination applies directly.

Multimodal, knowledge and safety results

Multimodal is where the comparison with Kimi K3 gets interesting. Muse Spark Open leads on ZeroBench with tools (50.0 versus 41.0), SimpleVQA (73.6 versus 71.9) and IntPhys2 (68.3 versus 60.3), while Kimi K3 leads on BabyVision (85.7 versus 80.2), WorldVQA (51.0 versus 49.4) and VideoMMEv2 (65.4 versus 61.5) [7]. Most competing columns are blank for these benchmarks, so the multimodal table is really a two-horse race with Inkling as the baseline.

Two numbers stand out for a different reason. On HLE-Diamond without tools it scores 26.1, the best in the table, and on AA Omniscience, which penalizes confident guessing, it scores 25 against 20 for Kimi K3 and 14 for GLM 5.3 [7]. A model that knows when it does not know is valuable in agent loops, because wrong tool arguments produced with confidence are more expensive than a request for clarification. On safety, the StrongREJECT v2 adaptive jailbreak score is 0.5 (lower is better) against 62.9 to 86.4 for the other open models listed [7]. That is consistent with Meta's statement about added safety post-training, and it is also a reminder that a more refusal-prone model can frustrate legitimate security research or red-team workflows. Test it on your own prompts.

The overall index

On the Artificial Analysis Intelligence Index, Meta lists 39 for Muse Spark Open, 26 for Inkling and 23 for Nemotron 3 Ultra, with GLM 5.3 at 45, Kimi K3 at 44, Qwen3.8 at 40 and Mistral Large 4 at 38 [7]. VentureBeat also lists independent entries for MiMo-V2.6-Pro at 46 and GLM-5.3-Flash at 42 [8]. In plain terms, it is the strongest US open-weight model on this index, near the middle of the large open pack, and below the top Chinese open models. Where the 6 point gap to GLM 5.3 matters depends on whether your workload looks more like MCP-Atlas (where it leads) or Terminal-Bench (where it trails).

Step 4: The Hardware Math for Running It Locally

This is the section that determines whether the model is relevant to you at all. The rule is simple: weight memory is parameters times bits per weight divided by eight, then you add the KV cache, then you add runtime overhead and headroom for the operating system.

Worked calculation

Start with 816B parameters.

• BF16 uses 16 bits per weight, so 816e9 times 2 bytes is 1,632 GB, about 1.63 TB. Meta's docs list the BF16 checkpoint at about 1.65 TB and the Hugging Face post says about 1.5 TB in safetensors, so the figure depends on which count you use [1][11]. The model card says BF16 needs about 2 TB once you include runtime overhead [7].
• A naive 8-bit build would be 816 GB. A naive 4-bit build would be 408 GB. A naive 3-bit build would be 306 GB. A naive 2-bit build would be 204 GB.
• Real quantizations do not hit those naive numbers because the attention weights, embeddings and norms stay at higher precision and quantization formats store scales. You can back out the effective bits per weight from reported sizes. The llama.cpp 2-bit build uses 304 GB, which is 304e9 times 8 divided by 816e9, about 2.98 bits per weight [1]. The MLX 3-bit build uses about 344 GB while running, about 3.37 bits per weight [1]. Meta's NVFP4 checkpoint is about 537 GB, about 5.26 bits per weight, which is higher than 4.5 bits (FP4 plus block scales) because the non-expert 3% of weights stays in higher precision [5][11].

As a sanity check on the NVFP4 figure: 97% of 816B is about 792B expert weights. At roughly 4.5 bits each that is about 445 GB, and the remaining 24B or so at 16 bits adds about 49 GB, for a total of about 494 GB. The published checkpoint at about 530 to 537 GB is a little larger than this estimate, probably because of extra scale metadata and other tensors, so use the published number for planning and the estimate only for intuition.

Does it fit? Four Macs, two Macs, one Mac

Meta's headline configuration is two M5 Ultra Mac Studios with 512 GB of unified memory each, described as behaving like one machine with a terabyte of unified memory, linked by Thunderbolt 5 with RDMA and split with MLX tensor parallelism so that only small intermediate results cross the cable [5][6]. Engadget adds that four 256 GB machines also work, at roughly $38,000 for the set, while Apple has not announced pricing or a ship date for the 512 GB model, which is expected in late October [6]. VentureBeat takes a different route to a cost reference: Apple lists a 256 GB M5 Ultra with 1 TB SSD at $10,799, so four would total $43,196 before tax and accessories [8]. The two figures disagree by more than $5,000, so treat anything between $38,000 and $44,000 as the realistic range for the four-machine build until you price your own configuration.

Now apply the math. Four 256 GB machines give 1,024 GB total. A 3-bit MLX build at about 344 GB leaves about 680 GB for the KV cache, which can hold the full 266 GB cache at 1M tokens with room to spare, though macOS reserves part of unified memory and a cluster has per-node overhead. The 4-bit MLX build is not listed with a measured size, but if it follows the 4.4 bits per weight typical of such formats the estimate is about 450 GB, leaving roughly 570 GB. A single 512 GB machine runs the 3-bit build at 344 GB and leaves about 168 GB, which supports a context of roughly 600K tokens at BF16 KV cache by the same arithmetic (168 GB divided by 254 KB per token), before OS overhead. In practice plan for a lower number, perhaps 300K to 400K tokens, until you measure it.

The script below reproduces every number in this section so you can swap in your own context length, quantization and machine count.

python
/code
# Memory planner for Muse Spark Open (numbers from the Hugging Face launch post and model card)
PARAMS = 816e9
ACTIVE = 42e9
KV_PER_TOKEN = 126_976 * 2  # cached values per token x 2 bytes (BF16) = 253,952 bytes

def weights_gb(bits_per_weight):
    return PARAMS * bits_per_weight / 8 / 1e9

def kv_gb(tokens):
    return KV_PER_TOKEN * tokens / 1e9

def decode_ceiling(bits_per_weight, bandwidth_gbs):
    # Upper bound on tokens/s if every token reads the active weights once.
    return bandwidth_gbs / (ACTIVE * bits_per_weight / 8 / 1e9)

for name, bpw in [("BF16", 16), ("naive 8-bit", 8), ("MLX 3-bit (measured)", 3.37), ("llama.cpp 2-bit (measured)", 2.98)]:
    print(f"{name:28s} weights {weights_gb(bpw):7.0f} GB")

for ctx in (131_072, 262_144, 524_288, 1_048_576):
    print(f"context {ctx:>9,d} -> KV cache {kv_gb(ctx):6.1f} GB")

budget = 1024  # four 256 GB Mac Studios
need = weights_gb(3.37) + kv_gb(1_048_576)
print(f"3-bit weights + full 1M KV cache = {need:.0f} GB of {budget} GB, headroom {budget - need:.0f} GB")
print(f"Effective bandwidth implied by 21 tok/s at 3.37 bpw: {21 * ACTIVE * 3.37 / 8 / 1e9:.0f} GB/s")

What speed to expect

Hugging Face tested the MLX 3-bit build on a Mac M3 Ultra with 512 GB: about 344 GB used, 225 tokens per second of prefill and 21 tokens per second of generation on a 1024 token prompt with 128 generated tokens. The llama.cpp imatrix 2-bit build on the same machine ran at 18 tokens per second using 304 GB [1]. Those are M3 Ultra numbers, not M5 Ultra, and VentureBeat notes that the launch gave no measured token rate for the paired M5 setup [8].

You can sanity check those figures with a bandwidth model. Decoding reads the active weights once per token. At 3.37 bits per weight, 42B active parameters is about 17.7 GB per token, and 21 tokens per second means roughly 372 GB/s of effective weight traffic. That is plausible against the several-hundred GB/s class of memory bandwidth in Ultra chips, and it implies decode speed is bounded by memory bandwidth and not by compute. The same logic predicts that a 4-bit build would be a bit slower per token than a 3-bit build on the same machine, and that a faster-memory chip like the M5 Ultra should improve the number, though by how much has not been published. Prefill is compute-bound, so 225 tokens per second means a 100K token prompt takes about 7.4 minutes to ingest on that machine (100,000 divided by 225 is about 444 seconds). For agentic coding where you load a repository once and iterate, that cost is paid once per session, but it also tells you that interactive use of the full million tokens on a desktop will feel slow.

Meta's quantization tests also come with a caveat: i-scoop notes that quality loss at 2-bit and 3-bit compression is unmeasured [10]. The benchmark table above was run on Meta's native checkpoints, so a 2-bit local build is a different model in practice. Evaluate it on your own tasks.

Data center hardware

Outside Apple silicon, the supported configurations are straightforward. NVFP4 runs on a single node of four Blackwell GPUs (the Hugging Face SGLang example uses four GB300 GPUs), and the model card states a minimum of 700 GB of accelerator memory for NVFP4 and about 2 TB for BF16, which Meta's docs say serves on eight GPUs such as 8 times B300 [1][7][11]. The Hugging Face BF16 Transformers recipe uses 4 nodes of 8 H200 GPUs with tensor parallelism of 32 [1]. AMD ships FP8 and MXFP4 quantizations for MI355X and MI350X, and Intel lists an MXFP4 build for four 160 GB Crescent Island cards and a GPTQ INT4 build for Xeon 6 offline inference [5].

When buying hardware beats renting

Here is a straightforward break-even calculation. At $43,196 for four 256 GB Mac Studios and a hosted price of $4.25 per million output tokens plus $1.25 per million input tokens [8][12], a team that spends $500 per month on the hosted API would take about 86 months to recover the hardware cost, ignoring electricity, ignoring resale value, and ignoring the engineering time to maintain a cluster. The numbers shift if you need privacy, offline operation, or many parallel agents, but for plain cost reasons the hosted API wins unless you are running billions of tokens per month. The other reason to buy hardware is control: fine-tuned weights, no data leaving your network, and no dependency on a provider's rate limits.

Step 5: How to Run It: vLLM, SGLang, llama.cpp, MLX and Hosted APIs

The commands below follow the launch documentation. Check the flags against the versions you install, because the speculative decoding options and the muse parser names are new.

Download the weights

Request access on the Hugging Face model page first, since the repository is gated [8]. Then authenticate and download. The collection is meta-models/muse-spark-open, and the main checkpoints are the BF16 repo, the NVFP4 repo for Blackwell, a GGUF repo with Q2_K, Q4_K_S and Q8 files, and 3-bit and 4-bit MLX conversions from the mlx-community organization [1].

bash
/code
# Install the Hugging Face CLI and log in (the repo is gated: request access on the model page first)
pip install -U "huggingface_hub[cli]"
huggingface-cli login

# NVFP4 checkpoint (about 530 to 537 GB), for Blackwell GPUs
huggingface-cli download meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --local-dir ./muse-spark-open-nvfp4

# BF16 checkpoint (about 1.5 to 1.65 TB): make sure the disk has room first
df -h .
huggingface-cli download meta-models/Muse-Spark-Open-816B-A42B --local-dir ./muse-spark-open-bf16

SGLang on a four-GPU Blackwell node

The Meta developer page gives an SGLang recipe with DFlash speculative decoding. The RadixArk draft model reportedly gives 3.7 times single-request throughput and 2.9 times at 16 concurrent requests on AMD MI355X with unchanged accuracy, averaging 6.4 accepted draft tokens per step [5]. Those are vendor-reported numbers on one platform, so measure on your own hardware.

bash
/code
# SGLang on a four-GPU Blackwell node with DFlash speculative decoding (flags from Meta's launch page)
sglang serve \
  --model-path meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tp-size 4 --ep-size 4 \
  --quantization modelopt_fp4 \
  --moe-runner-backend flashinfer_trtllm \
  --mem-fraction-static 0.8 \
  --host 0.0.0.0 --port 30000 \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path RadixArk/Muse-Spark-Open-DFlash2 \
  --speculative-draft-attention-backend fa4 \
  --speculative-num-draft-tokens 8 \
  --reasoning-parser muse \
  --tool-call-parser muse

vLLM on Blackwell

vLLM supports the NVFP4 checkpoint on Blackwell GPUs with expert parallelism. Hugging Face notes that its vLLM example supports text and images only, while Meta's page lists a DSpark speculative decoder from Inferact that proposes up to 7 tokens per pass and uses adaptive verification so speedups hold as batch size grows [1][5]. The muse parsers are required for reasoning and tool calls to come back in the right fields.

bash
/code
# vLLM on Blackwell with expert parallelism and DSpark speculative decoding
VLLM_USE_RUST_FRONTEND=1 \
vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --max-model-len 131072 \
  --reasoning-parser muse \
  --tool-call-parser muse \
  --enable-auto-tool-choice \
  --speculative-config '{"method":"dspark","model":"Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7}'
# Raise --max-model-len toward 1048576 only after checking the KV cache fits in memory.

Calling the local server from Python

Both servers expose an OpenAI-compatible API, so the same client code works against your own machine, Together, Fireworks or OpenRouter, and only the base URL, key and model name change. The example below sends a tool-calling request, which is the case that matters for agentic coding.

python
/code
# Works against a local vLLM/SGLang server, Together, Fireworks or OpenRouter: change base_url, key and model.
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed-locally")

tools = [{
    "type": "function",
    "function": {
        "name": "run_tests",
        "description": "Run the project's test suite and return failures.",
        "parameters": {
            "type": "object",
            "properties": {"path": {"type": "string", "description": "Directory or file to test"}},
            "required": ["path"],
        },
    },
}]

resp = client.chat.completions.create(
    model="meta-models/Muse-Spark-Open-816B-A42B-NVFP4",
    messages=[
        {"role": "system", "content": "You are a careful coding agent. Explain your intent before each tool call."},
        {"role": "user", "content": "The auth tests are failing. Find out why."},
    ],
    tools=tools,
    temperature=1.0,   # model card recommendation
    top_p=1.0,
    extra_body={"reasoning_effort": "high"},  # field name may differ by server; check the reasoning token counts
)
msg = resp.choices[0].message
print(msg.content)
print(msg.tool_calls)

The Hugging Face post notes an inconsistency worth knowing about: its tool-calling example uses a field named reasoning_strength while other examples use reasoning_effort, and its Inference Endpoints example passes enable_thinking false even though reasoning cannot be disabled [1]. A numeric level can also be set by adding a line such as "Reasoning strength: 1" to the system prompt. Until the field names settle, log what each server actually honors by comparing the reasoning token counts it returns.

llama.cpp and Unsloth on a high-memory machine

For a single large-memory workstation, the GGUF route is the simplest. Hugging Face tested the Q2_K build on an M3 Ultra, and Meta's page also lists Unsloth Dynamic GGUF quantizations starting at UD-Q2_K_XL, with about 300 GB of combined RAM and VRAM cited in one place and a 256 GB setup in another, so confirm the numbers for your own file [1][5].

bash
/code
# llama.cpp: 2-bit build (about 304 GB, tested at 18 tokens/s on a 512 GB M3 Ultra)
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q2_K

# Larger quality-first option from the same repo
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q4_K_S

# Unsloth Dynamic GGUF
unsloth run --model unsloth/Muse-Spark-Open-816B-A42B-GGUF:UD-Q2_K_XL

MLX on one or more Macs

MLX support is available through mlx-lm and the oMLX project, with 3-bit (oQ3e) and 4-bit (oQ4e) conversions published by mlx-community, and the Hugging Face post says even 3-bit needs more than 256 GB of RAM [1]. For the two-machine setup, Meta says MLX tensor parallelism splits every layer across the machines over Thunderbolt 5 with RDMA [5]. The distributed launch syntax comes from MLX's own documentation, so the sketch below shows the single-machine server and marks where the cluster launcher goes.

bash
/code
# MLX on a single 512 GB Mac Studio: 3-bit build (about 344 GB in use)
pip install -U mlx-lm
mlx_lm.server --model mlx-community/Muse-Spark-Open-816B-A42B-oQ3e --port 8080

# 4-bit build for a two-machine or four-machine cluster (tensor parallel over Thunderbolt 5 RDMA).
# Use MLX's distributed launcher with a hostfile; see the MLX distributed docs for the exact flags.
# mlx.launch --hostfile hosts.json -- mlx_lm.server --model mlx-community/Muse-Spark-Open-816B-A42B-oQ4e

Hosted APIs and OpenRouter

If you only want to try the model, the hosted route is the cheapest experiment. Meta's page lists 17 deployment providers including Baseten, Fireworks AI, Groq, Hugging Face, Modal, Nebius, OpenRouter, Together AI, plus AMD, AWS, Google Cloud, Intel, Microsoft, NVIDIA, SGLang, vLLM and Unsloth [4]. Details from the launch coverage: Baseten runs NVFP4 with a custom DSpark drafter and 1M context, Fireworks is pay-per-token with serverless LoRA fine-tuning, Groq is in limited preview aimed at fast multi-step agent loops, and Together offers serverless and dedicated endpoints with a 99.9% SLA [5]. Context limits vary by host: VentureBeat lists Groq at 131,072 tokens with organization approval required, and Fireworks at 1,048,576 [8].

python
/code
# Hosted trial through OpenRouter. Copy the exact model slug from the Muse Spark Open page on openrouter.ai.
import os
from openai import OpenAI

client = OpenAI(base_url="https://openrouter.ai/api/v1", api_key=os.environ["OPENROUTER_API_KEY"])
MODEL = os.environ.get("MUSE_MODEL", "meta/muse-spark-open")  # verify this slug on OpenRouter

resp = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": "Plan a refactor that splits a 2,000-line module into three files, then list the first three commands you would run."}],
    max_tokens=1500,
)
print(resp.choices[0].message.content)
print(resp.usage)

Pricing for OpenRouter is taken from a third-party tracker that was last updated October 16, 2026, so confirm the rate on OpenRouter's model page before you budget around it [12]. Artificial Analysis measured the hosted model at about 131 tokens per second with a first token after 0.73 seconds, as reported by i-scoop [10]. Compare that to Kimi K3 at $3.00 and $15.00 per million tokens and GLM 5.3 at $1.40 and $4.40 on Together, per VentureBeat's table [8].

Step 6: Agentic Coding Workflows That Match the Model's Strengths

Meta says the model was trained for agents that read a large codebase, plan a change, call tools, check results and correct failed steps [5]. Turning that into a setup that works takes a few decisions.

Use the parsers and the commentary channel

Always launch with the muse reasoning and tool-call parsers, and add auto tool choice in vLLM. Without them, tool calls come back as plain text and agent frameworks fail in confusing ways. Surface the commentary channel in your logs, because it records the model's stated intent before each action, which gives you something to audit when a long session goes wrong.

Pick reasoning effort per step

Because the default is xhigh, every call spends the largest thinking budget. A reasonable pattern is high or xhigh for planning and debugging steps, medium for edits that follow an already-approved plan, and low for formatting, summarization and routing. If your agent runs 40 tool calls per task, shaving the budget on the 30 mechanical ones is the largest latency win available without changing hardware.

Match the context strategy to the memory budget

The 1M-token window is useful for loading a whole repository or a long trace once, but the numbers above show the cost: about 254 KB of KV cache per token and prefill speeds on the order of hundreds of tokens per second on a desktop. For hosted use, keep the stable prefix (repository map, style guide, tool definitions) identical across calls so prefix caching helps, and Together lists cached input at $0.15 per million tokens against $1.25 for uncached input [8]. For local use, summarize old tool outputs instead of carrying them forever.

Keep a human in the loop for irreversible actions

The model card recommends deploying inside a broader system with guardrails, requiring human confirmation for irreversible agent actions, and not exposing raw chain-of-thought to end users [7]. This is not boilerplate for an agent that can run shell commands. Our reporting on AI agents breaking out of sandboxes shows why isolation and confirmation steps matter even when the model is well behaved.

Fine-tuning notes

Hugging Face demonstrated a TRL SFTTrainer LoRA run on 8 nodes of 8 H100 GPUs (64 in total) with fsdp_size 64 and ep_size 8, rank 16 and alpha 32 on the attention projections with experts frozen, over the first 500,000 examples of the Tulu 3 SFT mixture, taking about 2 hours at roughly 8,000 tokens per second, with mean token accuracy rising from 72% to 84% and loss falling from 1.26 to 0.57 [1]. The takeaway for planning is that even LoRA on this model needs a 64-GPU cluster. Fireworks and Together offer hosted LoRA fine-tuning if you do not own that hardware, with Fireworks supporting sequences up to 262,144 tokens [5].

Step 7: License Gotchas in the Muse Model License

The license is permissive in the ways most teams care about and restrictive in a few specific ways that surprise people. The summary below combines the model card with two independent license reviews [7][9][10]. This is not legal advice, and the full text including Exhibit A is the document to have your counsel read.

Attribution

Any product or documentation that uses the model or a Derivative must prominently display "Built with Muse Spark Open." Derivatives are defined broadly, covering models trained, fine-tuned or distilled from the software or its outputs [9]. That means if you distill Muse Spark Open into a small model and ship it, the label travels with your small model. Teams that white-label AI features should check whether a visible badge is acceptable before choosing this model over Apache or MIT alternatives.

The $20 million model-as-a-service trigger

If you or your affiliates offer access to the model to third parties through an API or similar service, and your aggregate gross revenue exceeds $20 million over any consecutive 12 months, you must notify Meta and sign a separate written agreement first. Internal use, research, non-MaaS commercial activity and using the model inside your own product are excluded [7]. The detail that trips people up is that the revenue test counts affiliates, so a startup owned by a large group inherits the group's revenue. Kimi K3 reportedly has a similar $20M model-as-a-service threshold, while GLM 5.3's Z.ai security review trigger sits at $10B in revenue [9].

Military, nuclear and critical infrastructure bans

Exhibit A prohibits use related to "Military, warfare, nuclear industries or applications, espionage" and bans activities presenting a risk of death or bodily harm, including "Operation of critical infrastructure, transportation technologies, or heavy machinery" [9]. One analysis points out that the first clause has no "operation of" qualifier, so it could reach back-office work at a nuclear-linked company, and that the license does not define critical infrastructure [9]. Another points out that the language matches sections of Llama 3's acceptable use policy [9]. The New Stack describes the license as barring military and critical infrastructure deployments, and sources differ on how far the military restriction reaches, so do not assume a defense or utilities customer is covered without reading Exhibit A [3]. The usage policy also bars malware creation, circumventing safety measures, sensitive-data inference without legal right, and deceptive uses like impersonation and fake engagement, and the model is not intended for people under 18 [7].

Outputs, warranties and the EU

Meta claims no ownership of outputs, which keeps generated code and text yours [7]. The software is provided as is, and you are solely responsible for deploying your Derivatives [7]. Users in or with a principal place of business in the European region contract with Meta Platforms Ireland Limited, and elsewhere with Meta Platforms, Inc. [7]. The i-scoop analysis notes that the license has no geographic restriction on EU companies, that the model is trained on more than 100 languages without the card specifying which are strongest, and that whether this license qualifies for the EU AI Act's open-source provisions is a question for Meta as the provider [10]. If you serve European customers, test Dutch, French and German first as that analysis suggests, and compare against Mistral Large 4, which scored 38 on the same index.

Compare this with another case where a license affected deployment decisions: our write-up on MiniMax H3 covers a model you cannot legally self-host in the US, and the posts on Tencent Hy4 and Atria Dawn show how varied the rules are across large open-weight releases.

Step 8: When to Choose Muse Spark Open and When Not To

The right choice depends on the workload, the hardware you already own and your tolerance for license conditions. Here is how the options compare.

Choose Muse Spark Open when

• Your agent loops are tool-heavy. MCP-Atlas at 89.2 and Toolathlon at 72.8 are the closest public proxies for multi-tool reliability, and early adopters reported correct tool selection [5][7].
• You need multimodal input in an agent: screenshots, audio and video through one model at one context window, which most competing columns in the table do not report.
• You want a US-origin open-weight model, whether for procurement reasons or because you prefer Meta's license terms. Engadget and TechCrunch both quote Meta framing exactly this argument [2][6].
• You want a model that is calibrated about what it does not know, given its AA Omniscience result of 25.
• You already own 1 TB of unified or accelerator memory, or can rent Blackwell nodes.

Choose something else when

• Raw coding benchmark performance is the only criterion. Kimi K3 (85.0 on Terminal-Bench 2.1, 68 on DeepSWE) and GLM 5.3 (83.9 and 67) lead, and both are covered in our deep dives linked in Step 1.
• You need a model that fits on a single GPU. Muse Glimmer at 30B, or Qwen3.8-27B, run on one consumer card.
• You are building a hosted model-as-a-service business above $20M revenue, or you cannot accept an attribution label.
• Your work touches defense, nuclear or utilities, where the Exhibit A bans create real exposure.
• You need independent benchmark verification before committing, since the Artificial Analysis listing was not confirmed at launch [8].

A short decision story

Consider a 15-person software company that wants an in-house coding agent over a 2-million-line monorepo and cannot send code to a third party. They have no GPUs. The options are a four-Mac cluster at roughly $38,000 to $44,000 [6][8], a rented four-GPU Blackwell node, or a smaller model like Glimmer on one workstation. If the monorepo tasks are mostly "find the right files and call the right tools in order," Muse Spark Open's profile fits and the cluster pays off through privacy, not through token savings. If the tasks are mostly "fix this failing test," the coding table says to benchmark Kimi K3 or GLM 5.3 against it before buying. The decision hinges on a one-week bake-off on your own tasks, and hosted access through Together or OpenRouter makes that bake-off cost a few dollars per million tokens instead of a hardware order [8][12].

Common Mistakes to Avoid

• Calling it open source in documentation or marketing. The license is not OSI approved, and your legal team will care [7].
• Planning memory for the weights alone. The full-context KV cache adds about 266 GB, and the operating system and runtime need headroom [1].
• Treating a 2-bit or 3-bit local build as equivalent to Meta's benchmark numbers. The quality loss from compression is unmeasured [10].
• Leaving reasoning effort on the xhigh default for every call in an agent loop, which inflates both latency and cost.
• Forgetting the muse reasoning and tool-call parsers when serving, which breaks tool calling [5].
• Ignoring the attribution requirement when distilling into a smaller model, since Derivatives carry the label [9].
• Comparing vendor-reported scores across different harnesses. DeepSWE and SWE-Atlas-QnA use each model's preferred harness [7].
• Assuming the Apple cluster is a turnkey purchase when the 512 GB configuration had no announced price or ship date at launch [6].

Where This Fits in a Creator and Marketing Workflow

Most Miraflow readers are not running 816B models on racks of Macs, but the release still changes what is practical for content teams. A multimodal model that accepts video and audio can review footage, draft scripts and critique rough cuts, the same job TechCrunch showed in a DaVinci Resolve demo [2]. If you produce short-form video, the natural pairing is to use an agent model for scripting and review, then move to production tools: Text2Shorts on Miraflow turns a topic into vertical videos, AI Clipping finds and ranks the best moments in a long video, the YouTube Thumbnail Maker builds thumbnails, the AI image generator produces visuals, the AI music generator covers soundtrack, and the cinematic video generator handles AI scenes. You can explore all of them from the Miraflow home page. The point of a model like Muse Spark Open in that stack is orchestration: planning a content calendar, checking a script against a brief, or sorting thousands of clips, while the generation itself runs in purpose-built tools.

Best Practices for a Production Deployment

1. Start with hosted access on two providers and run your own evaluation set before you buy or rent dedicated hardware.
2. Pin the checkpoint (BF16, NVFP4 or a specific quantization) and record the exact serving flags, because the model, parsers and draft models are all new and will change.
3. Size memory as weights plus KV cache for your real maximum context times your real concurrency, plus 10 to 15% headroom as a planning habit.
4. Enable speculative decoding with the matching draft model (DFlash for SGLang, DSpark for vLLM) and verify output equivalence on your tests.
5. Put guardrails, logging of the commentary channel and human confirmation in front of irreversible agent actions [7].
6. Have counsel read Exhibit A if you work near defense, energy, transportation or heavy equipment, and track the $20M revenue trigger if you resell access.
7. Re-run the vendor benchmark claims on independent leaderboards as they appear, since the Artificial Analysis listing was unverified at launch [8].

Conclusion

Muse Spark Open is a serious open-weight release with a clear identity: an 816B sparse MoE with 42B active parameters, a million-token window, multimodal input, a strong tool-use profile and the best score in its table on MCP-Atlas, paired with coding scores that sit below GLM 5.3 and Kimi K3 and a license that is generous for most builders but adds attribution, a $20M resale trigger and military and critical infrastructure bans [7][9]. The memory arithmetic is the real gate: roughly 537 GB for the NVFP4 checkpoint, 1.63 TB for BF16, 304 to 344 GB for 2-bit and 3-bit community builds, plus 254 KB of KV cache for every token of context [1][5].

Your next step depends on who you are. If you build agents, spend a few dollars on a hosted bake-off against Kimi K3 and GLM 5.3 using your own tasks. If you manage infrastructure, run the memory calculation in this post with your real context length and concurrency before ordering hardware. If you are in legal or procurement, read Exhibit A and the attribution clause first. And if you create content, treat models like this as the planning layer that sits next to your generation tools, and keep your visuals, shorts and thumbnails flowing through Miraflow.

Frequently Asked Questions

Is Muse Spark Open really open source?

No. It is open-weight under the Muse Model License, which allows use, modification, fine-tuning, distillation and commercial distribution but adds an attribution requirement, a model-as-a-service revenue trigger and usage bans, so it is not an OSI-approved license [7][9].

How many parameters does Muse Spark Open have?

About 816B total and about 42B active per token, with 62 layers and 256 experts per layer of which 8 are routed per token. Hugging Face lists 822B for the BF16 repo and 484B for the NVFP4 repo, which reflects how each repository counts tensors [1].

How much RAM do I need to run it?

For Meta's recommended Apple setup, about 1 TB of unified memory across two 512 GB or four 256 GB Mac Studios [5][6]. Community 2-bit and 3-bit builds were tested at 304 GB and 344 GB on a 512 GB M3 Ultra, plus extra for long contexts [1]. The NVFP4 checkpoint needs at least 700 GB of accelerator memory and BF16 needs about 2 TB [7].

How much does the Apple setup cost?

Engadget reports roughly $38,000 for four 256 GB M5 Ultra Mac Studios, while VentureBeat computes $43,196 from Apple's $10,799 list price for the 256 GB configuration, and the 512 GB model had no announced price at launch [6][8].

How big is the context window?

Up to 1,048,576 tokens, shared across text, images, audio and video. A full-length BF16 KV cache is about 266 GB [1].

Does it beat Kimi K3 and GLM 5.3?

On some agentic tasks, yes: MCP-Atlas 89.2 versus 82.3 and 84.2, and JobBench 61.8 versus 54.3 and 61.4. On Terminal-Bench 2.1 and DeepSWE 1.1 it trails both, and on the Artificial Analysis index it scores 39 versus 44 and 45 (Meta-reported) [7].

Does it beat Inkling and Nemotron 3 Ultra?

On Meta's table, yes by wide margins. For example, Terminal-Bench 2.1 is 76.4 versus 55.1 for Inkling and 53.9 for Nemotron 3 Ultra [7].

Which inference engines support it?

SGLang, vLLM, TensorRT-LLM, Hugging Face Transformers, MLX, llama.cpp and Unsloth, with verified support on NVIDIA, AMD, Intel and Apple silicon [5].

Where can I use it without owning hardware?

Baseten, Fireworks AI, Groq (limited preview), Modal, Nebius, OpenRouter and Together AI, plus model catalogs on Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry Models [5][8].

What does the hosted API cost?

Together AI lists $1.25 per million input tokens, $0.15 per million cached input tokens and $4.25 per million output tokens, and a tracker lists the same input and output rate on OpenRouter [8][12].

Can I use it commercially?

Yes, including selling products built on it, provided you show "Built with Muse Spark Open," respect the usage policy, and sign a separate agreement with Meta if you run a model-as-a-service business above $20 million in revenue [7].

Can I use it for defense or infrastructure work?

The usage policy bars military, warfare, nuclear and espionage uses and the operation of critical infrastructure, transportation technologies and heavy machinery. Sources differ on how far these clauses reach, so have counsel read Exhibit A [3][9].

Is it good for coding?

It is built for agentic coding and scores 76.4 on Terminal-Bench 2.1 and 60 on DeepSWE 1.1, well above Inkling and Nemotron 3 Ultra but below Kimi K3 and GLM 5.3 [7].

Should I run a 2-bit version?

It works for experimentation, and Hugging Face measured 18 tokens per second on an M3 Ultra, but the quality loss from heavy compression has not been measured, so validate it on your tasks before relying on it [1][10].

References

1. [1] Hugging Face Blog: Meta Muse Spark Open
2. [2] TechCrunch: Meta launches an open-weight model that runs on Macs
3. [3] The New Stack: Meta ships Muse Spark Open, its answer to China's best open-weight models
4. [4] Meta Developer: Muse Spark Open model page
5. [5] Meta Developer: Build with Muse Spark Open
6. [6] Engadget: Meta built a huge open-weight AI model for Macs, but you'll need 1TB of RAM to run it
7. [7] Hugging Face model card: meta-models/Muse-Spark-Open-816B-A42B
8. [8] VentureBeat: Meta unveils Muse Spark Open, the new top U.S. open weights model
9. [9] BERI: Meta's Muse Spark Open license bans running critical infrastructure
10. [10] i-scoop: Muse Spark Open gives Europe a US open-weight option, with strings attached
11. [11] Meta Developer: Muse Spark Open docs
12. [12] computeprices.com: Muse Spark Open on OpenRouter