Run Muse Spark Open Locally and on AWS: Mac Studio MLX, llama.cpp and Unsloth GGUF Sizes, SageMaker JumpStart, Claude Code and OpenCode Setup (Meta's 816B Open-Weight Model)

Muse Spark Open is Meta's new open-weight model, released on October 15, 2026: 816 billion parameters, about 42 billion active per token, a 1-million-token context window, text, image, video and audio in, text out, and Meta's claim of "the most capable US open-weight model to date." You can download the weights today, and this page shows you every way to run them: on a Mac, with llama.cpp or Unsloth on a workstation, on AWS through SageMaker JumpStart, and through the hosted APIs. Read this sentence before you start any download: the smallest usable file is 176 GB, the 2-bit file Unsloth recommends needs 256 GB of memory, and "runs on your desktop" means two Mac Studios with 512 GB each, linked with Thunderbolt 5. This is not a laptop model, and the AWS route, one model card and about 20 minutes, is the realistic way for most people to try it. Below: the real file sizes, the exact commands for MLX, llama.cpp, Unsloth and SageMaker, the settings, the license, and how to point Claude Code or OpenCode at it.

Ethan, a developer, builds the booking site for his friend Jake's phone repair shop. He has used Muse Glimmer, the 30B Meta model, on his own PC for small jobs. Now the big one is open, and Jake has asked the obvious question: does the 32 GB desktop in the back room run it?

New to running AI on your own machine? Our plain-English series on running AI locally explains parameters, GGUF files and quantization in about ten minutes; this page assumes none of it.

What Muse Spark Open is, in plain English

Muse Spark is the model behind Meta's Muse Code and the Meta Model API. Muse Spark Open is the version whose weights you can download, from Meta Superintelligence Labs, with extra safety training so it behaves on its own without a hosted guardrail layer. Its name tells you its shape: 816B parameters in total, A42B for the roughly 42 billion that run for each token.

It's a mixture of experts: 256 expert networks per layer across 62 layers, and for every token only 8 of them run. That's why a model this size can answer at a sensible speed, and why the memory bill is the whole 816B anyway: every expert has to be loaded, ready to be chosen. A separate 1.8B "perception encoder" handles images, video frames and audio, so the model reads screenshots, documents and recordings natively rather than through an add-on.

• Context: 1,048,576 tokens at inference.
• Input: text, images, video, audio. Output: text.
• Reasoning is always on. It thinks before it answers, with four effort levels: low, medium, high and xhigh. The default is xhigh, and the chat template refuses "none".
• Built for agents: tool calling, long multi-step tasks, whole-repository coding, computer use. Meta's own launch demo had it shipping real changes to an open-source iOS app and driving a video editor, entirely on two Macs.
• Trained on more than 100 languages.

Jake: "Glimmer was 30B and I needed 24 GB. This is 816. So I need, what, 650 GB?"

Ethan: "Full precision is 1.65 terabytes. Even the 1-bit file is 176 gigabytes. Your 32 GB desktop isn't in the conversation. The rented GPU is."

Will it run on my machine? The honest size table

Here's the catch hiding in "42B active". Speed comes from the active count; memory comes from the total. Everything in the table has to sit in RAM, VRAM or Apple unified memory while you generate, and the model's own context cache comes on top. These are the real downloads:

Unsloth's own quality numbers say where the floor is: quants below UD-IQ2_S degrade on general tasks, so that is the smallest file they recommend for agentic work, while chat-style use "works fine" on the smallest ones. UD-Q4_K_XL is the one with near-zero measured loss. So the honest ladder is: 256 GB of memory for a model you'd trust with code, 512 GB for one that is close to the original.

Memory means total memory: system RAM plus VRAM on a PC, or unified memory on a Mac. llama.cpp will page from disk when you're short, and the result is generation measured in seconds per token, which is useless for an agent. Here is what that means for real machines:

Jake: "Then who is 'runs on your desktop' for?"

Ethan: "People whose desktop is two Mac Studios with a terabyte between them. It's true, and it's a studio, not a laptop. For the shop we'll rent it by the hour."

The settings everyone gets wrong on day one

Three things are different from most open models, and all three come from Meta's own recommendations.

• Temperature 1.0, top-p 1.0, top-k disabled. Not 0.7, not 0.1. The model was evaluated at these values and the chat template expects them.
• Reasoning effort. The default is xhigh, which spends a lot of tokens thinking before the first word of the answer. For a chat or a quick question set it to low or medium; keep high or xhigh for coding and agent runs. You cannot turn reasoning off: the template rejects "none", and llama.cpp's --reasoning off leaves the output unchanged.
• Room for the answer. Because the reasoning comes first, a max_tokens of 512 can end before the answer begins. Start at 4,096 and raise it for code.

In llama.cpp the effort is set server-wide with --chat-template-kwargs '{"reasoning_effort":"low"}' or per request with a chat_template_kwargs field; in vLLM and SGLang it's the reasoning_effort request parameter; in Unsloth it's --reasoning-effort; on SageMaker the reasoning comes back in a separate reasoning_content field with its token count in usage.reasoning_tokens.

Download: the license gate and the three repositories that matter

The weights are gated on Hugging Face: sign in, open meta-models/Muse-Spark-Open-816B-A42B, read and accept the Muse Model License, and only then do downloads work. The command-line downloads need a token from your Hugging Face settings and hf auth login first. The Unsloth and ggml-org GGUF repositories carry the same license file, and the runners below pull from them directly, so you may not need the Meta repository at all unless you're using MLX, vLLM, SGLang or Transformers.

pip install -U huggingface_hub
hf auth login
# NVFP4, about 537 GB:
hf download meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --local-dir ./muse-spark-open-nvfp4
# BF16, about 1.65 TB:
hf download meta-models/Muse-Spark-Open-816B-A42B --local-dir ./muse-spark-open

Plan the disk before the download: NVFP4 needs about 537 GB free on each machine that loads it, and a half-terabyte download over a home connection is an overnight job at best. If you are heading for AWS, skip this step entirely; SageMaker JumpStart fetches the weights into the endpoint for you.

Mac Studio with MLX: the two-machine cookbook, decoded

This is the setup Meta built the launch around, and the one the "runs on your desktop" line refers to. The NVFP4 weights need about 493 GB of memory before any overhead, so the model does not fit on one Mac. MLX splits every layer across the machines, each holds half the weights, and only small intermediate results cross the link; the Thunderbolt 5 connection carries them over RDMA, which is why the macOS version matters.

What you need, exactly:

• Two Mac Studios with M5 Ultra and 512 GB of unified memory each, or four with 256 GB each. Four is faster.
• macOS 26.2 or later on every Mac (it adds the RDMA-over-Thunderbolt driver), with RDMA turned on as the MLX distributed guide describes.
• MLX 0.30.1 or later, and mlx-lm on every Mac.
• A direct Thunderbolt 5 cable between every pair of Macs; two cables per pair doubles the bandwidth.
• Passwordless SSH from the primary Mac to the others, and about 537 GB of free disk on each.

# on every Mac
pip install -U mlx-lm

# on the primary: confirm SSH works without a password
ssh mac-studio-2.local 'echo ok'
# if it prompts: ssh-keygen -t ed25519 && ssh-copy-id mac-studio-2.local

# hostfile.json lists every Mac with its Thunderbolt IPs and RDMA devices
# (mlx.distributed_config can generate it)
mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.server --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --port 8080

That starts an OpenAI-compatible server on port 8080 of the primary. mlx.launch runs the same program on every Mac over SSH; --backend jaccl picks the RDMA-over-Thunderbolt transport; the MLX_METAL_FAST_SYNCH variable is an experimental fast CPU-to-GPU synchronization that cuts the overhead between the CPU driving the link and the GPU doing the math. To test without a server, swap mlx_lm.server for mlx_lm.generate --prompt "..." --max-tokens 4096 --temp 1.0 --top-p 1.0; leave the max-tokens high, because the template reasons at xhigh by default.

Two honest footnotes. The 512 GB M5 Ultra Mac Studio was not on sale on launch day, so the two-machine version is a plan rather than a purchase for now, while the four-machine 256 GB version exists today. And the community MLX files (mlx-community/...-4bit, 462 GB, plus 3-bit and other variants) are the ones to watch if you want to shave memory below Meta's NVFP4 build.

llama.cpp: the one-command server for a 256 GB workstation

llama.cpp runs on Metal, CUDA, ROCm, Vulkan and plain CPU, and its llama serve -hf command downloads, caches and serves a model in one go. Install the prebuilt binary, then pick a quantization that fits the memory table:

curl -LsSf https://llama.app/install.sh | sh

# ggml-org ships Q4_K_S, Q8_0 and Q2_K; the default (no suffix) is the server's pick
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q2_K \
  -a muse-spark-open \
  --chat-template-kwargs '{"reasoning_effort":"low"}' \
  -np 1

Then open http://localhost:8080 for the built-in web UI, which takes images, audio and MCP tools, or call the OpenAI-compatible endpoint:

curl -s --noproxy '*' http://127.0.0.1:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"muse-spark-open","messages":[{"role":"user","content":"What is 17 * 23?"}],"temperature":1.0}'

The flags that matter: -a gives the model a short API name instead of the checkpoint path; -np 1 keeps the whole context for one request, because llama.cpp divides the context length across concurrent slots and a long-context agent wants all of it; --api-key gates the endpoint if the machine is shared. For a terminal session, llama cli -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF -c 32768, and inside it /image photo.png attaches a picture before your question. Audio goes through the same endpoint in the OpenAI input_audio shape, raw base64 with "format":"wav" or "mp3".

On Windows, building llama.cpp from the main branch for this model depended on an open pull request at launch, and Unsloth publishes prebuilt binaries at github.com/unslothai/llama.cpp as the fallback; the llama.app installer above is the simpler route on macOS and Linux. On Kali, the install script works unchanged, and a CUDA build needs the NVIDIA driver in place first.

Unsloth: the dynamic GGUFs, and a desktop app that serves Claude Code

Unsloth had day-zero access and shipped the Dynamic GGUFs in the size table, which is why its 2-bit file is the one most people with a big workstation will actually run. Unsloth Desktop (macOS, Windows, Linux) downloads the file from its Model hub tab, sets the inference parameters for you, and serves an OpenAI-compatible and Anthropic-compatible API; the same thing from the terminal is:

unsloth run \
  --model unsloth/Muse-Spark-Open-816B-A42B-GGUF:UD-Q2_K_XL \
  -H 127.0.0.1 \
  -p 8888 \
  --context-length 32768 \
  --temperature 1.0 \
  --top-p 1.0 \
  --min-p 0.0 \
  --reasoning-effort medium

Pick the file by your memory: UD-IQ2_S is Unsloth's own floor for agent work, UD-Q2_K_XL the comfortable 2-bit, UD-Q4_K_XL the one with near-original quality at 512 GB. The underlying engine is llama.cpp, so the llama-server flags for GPU layers and threads pass through, and offloading layers to system RAM is what lets a 24 GB GPU plus 256 GB of RAM count as "256 GB" in the table.

Point Claude Code, OpenCode or Codex at your local server

Whichever server you started, the model is now an OpenAI-compatible endpoint on your machine, and coding agents only need to be told where it is. The configurations below follow the same shape as the ones in our Muse Wonder guide, with the base URL swapped for your local port.

OpenCode

Add a provider to opencode.json in your project (or ~/.config/opencode/opencode.json) that points at the llama.cpp server. The model id must match the -a alias you gave llama.cpp:

{
  "provider": {
    "local": {
      "name": "Muse Spark Open (local)",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "muse-spark-open": {
          "name": "Muse Spark Open",
          "reasoning": true,
          "limit": { "context": 32768, "output": 8192 }
        }
      }
    }
  }
}

Set the context limit to what you started the server with (32,768 above), not to the model's 1 million, or the agent will plan for room it doesn't have.

Claude Code

Claude Code speaks the Anthropic API, so it needs a server that answers in that shape; Unsloth's does. Start Unsloth as above, then launch Claude Code with the base URL and model pointed at it. One detail matters a lot with a local model: recent Claude Code builds prepend an attribution header whose value changes on every request, which defeats the server's prompt cache and makes local inference far slower; turn it off with the setting below.

export ANTHROPIC_BASE_URL="http://127.0.0.1:8888"
export ANTHROPIC_AUTH_TOKEN="<the key Unsloth printed>"
export ANTHROPIC_MODEL="unsloth/Muse-Spark-Open-816B-A42B-GGUF:UD-Q2_K_XL"
claude --settings '{"env":{"CLAUDE_CODE_ATTRIBUTION_HEADER":"0","CLAUDE_CODE_ENABLE_TELEMETRY":"0"}}'

Codex

Codex takes an OpenAI-compatible provider in ~/.codex/config.toml. For a llama.cpp server use the chat completions wire format, since that is what llama.cpp serves:

model = "muse-spark-open"
model_provider = "local"
model_reasoning_effort = "medium"

[model_providers.local]
name = "Muse Spark Open (local)"
base_url = "http://127.0.0.1:8080/v1"
wire_api = "chat"

Jake: "So the agent doesn't know it's talking to my machine instead of Meta?"

Ethan: "It doesn't care. It needs a URL, a model name and an answer in the right shape. The only thing that changes is who pays for the electricity."

AWS: Muse Spark Open in SageMaker JumpStart, step by step

For most readers this is the route that works today, because it needs no hardware at all: an endpoint in your own AWS account, your code and prompts processed on infrastructure you control, inside your VPC if you want, deleted when you're done. SageMaker JumpStart lists two variants, and the instance type is decided by memory, not preference:

Before you click Deploy you need four things: an AWS account with permission to create SageMaker models and endpoints; a SageMaker execution role (the AmazonSageMakerFullAccess managed policy is enough for a trial); a service quota for ml.p5e.48xlarge for endpoint usage (or the p6-b300 one for BF16), which new accounts have at zero and must request; and a Region where the model is listed, which at launch means US East (N. Virginia) and US East (Ohio). The quota request is the step that takes days, so file it first.

From SageMaker Studio

1. Open SageMaker Studio, choose JumpStart in the navigation pane, and search for Muse Spark Open.
2. Open Muse-Spark-Open-816B-A42B-NVFP4 (or the BF16 card) and choose Deploy.
3. Accept the Muse Model License when the EULA appears; the model is gated here too.
4. Keep the generated endpoint name or type your own, pick ml.p5e.48xlarge, set the initial instance count to 1. Under Advanced options you can select a VPC, a KMS key and network isolation.
5. Choose Deploy. Provisioning and loading the weights takes about 15 to 20 minutes; the endpoint is ready when its status reads InService.

From the SageMaker Python SDK (v3)

pip install --upgrade sagemaker

from sagemaker.core.jumpstart.configs import JumpStartConfig
from sagemaker.serve import ModelBuilder
from sagemaker.train.configs import Compute

# NVFP4 variant; for BF16 use "meta-vlm-muse-spark-open-816b-a42b" with ml.p6-b300.48xlarge
model_id = "meta-vlm-muse-spark-open-816b-a42b-nvfp4"
jumpstart_config = JumpStartConfig(
    model_id=model_id,
    accept_eula=True,  # confirms you accept Meta's license terms
)
model_builder = ModelBuilder.from_jumpstart_config(
    jumpstart_config=jumpstart_config,
    compute=Compute(instance_type="ml.p5e.48xlarge"),
    # role_arn="<your-sagemaker-execution-role-arn>",  # required outside SageMaker Studio
)
model = model_builder.build(model_name="muse-spark-open-nvfp4")
endpoint = model_builder.deploy(endpoint_name="muse-spark-open-nvfp4")

The endpoint takes an OpenAI-style chat payload. The answer comes back in message.content, the reasoning in message.reasoning_content, and the reasoning token count in usage.reasoning_tokens, so leave room in max_tokens:

import json

payload = {
    "messages": [{"role": "user",
                  "content": "Write a Python function that validates ISO 8601 dates, and add pytest unit tests for it."}],
    "max_tokens": 4096,
}
response = endpoint.invoke(body=json.dumps(payload), content_type="application/json")
result = json.loads(response.body.read().decode("utf-8"))
message = result["choices"][0]["message"]
print("Reasoning:", message.get("reasoning_content"))
print("Answer:", message["content"])

Add "stream": true and call endpoint.invoke_with_response_stream to get tokens as they are generated. And the step people skip: the instance is metered for every minute the endpoint exists, whether or not it is answering, so delete it when you stop:

from sagemaker.core.resources import EndpointConfig

endpoint_config = EndpointConfig.get(endpoint_config_name=endpoint.endpoint_name)
model.delete()
endpoint.delete()
endpoint_config.delete()

From the console, that is Inference → Endpoints, select it, Actions → Delete. Our SageMaker pricing guide explains what an idle endpoint costs and why a multi-GPU instance is the one you never leave running overnight by accident. Muse Spark Open is not on Amazon Bedrock as this is written; our Bedrock model ID list is the page that changes if that happens.

Running it yourself on GPUs: vLLM, SGLang, TensorRT-LLM

If you'd rather run the serving stack than let JumpStart do it, Meta's launch recipes are all for Blackwell-class nodes. The NVFP4 checkpoint runs on four B300s (or eight H200s), the BF16 one on eight B300s. The vLLM form, with the DSpark draft model for faster decoding:

export 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 1048576 \
    --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,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'

Prebuilt images exist for both vendors, vllm/vllm-openai:muse-spark-open and vllm/vllm-openai-rocm:muse-spark-open, and the server answers on port 8000 in the OpenAI shape with reasoning_effort as a request field. --max-model-len 1048576 serves the whole context window; the key-value cache on the full-attention layers grows with it, so lower the number if your workload is shorter. SGLang's recipe is the same idea with its own flags and the DFlash V2 draft model (RadixArk/Muse-Spark-Open-DFlash2), and TensorRT-LLM serves the NVFP4 checkpoint on a single four-GPU Blackwell node with trtllm-serve. AMD has FP8 and MXFP4 builds for MI350 and MI355X, Intel an INT4 build for Xeon 6. On AWS, the instance families behind those recipes are p5e (H200) and p6 (B200 and B300); check the quota page before you plan around them.

The hosted APIs, if you just want to call it

Seven providers served it on launch day: Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI. Two details worth knowing. Groq's listing is a limited preview, at roughly 350 tokens per second, with a 131,072-token context window and up to five images per request rather than the full million tokens. And every provider exposes the same four reasoning levels, so the reasoning_effort habit you form locally carries over. Meta's own Model API serves the closed Muse Spark line, not the Open weights; our Muse Wonder guide covers that side.

How good is it? Meta's numbers, read carefully

Meta published its own comparison against the other large open-weight models, run at xhigh effort. Three things stand out when you read the whole table rather than the headline:

First, "most capable US open-weight model" is a claim about US models: against Inkling and Nemotron 3 Ultra it wins everywhere, often by 20 points or more. Second, against the Chinese open models it's a split decision: it leads on agentic and tool-use tests (JobBench, MCP-Atlas, HLE-Diamond) and trails on terminal and coding benchmarks, where Kimi K3 and GLM 5.3 stay ahead. Third, the safety row is not a typo: the extra safety post-training shows up as a 0.5 on an adaptive jailbreak benchmark where the others score in the sixties, which is the trade Meta made for releasing it without a hosted guardrail. For a repair shop's booking agent that is a feature; for a red-team lab it's a limitation to know about.

Jake: "So it's the best at using tools and not the best at writing code?"

Ethan: "On the launch numbers, yes. Which is fine for us. The shop's agent spends its day calling the ticket system, not refactoring a kernel."

The license, in plain English

The weights are under the Muse Model License, which carries limited commercial terms that let most developers use the model for free. In practice: using it internally and building it into your own product are free; the usage policy bundled with the license bars some deployments, including military and critical-infrastructure uses; and the model is not meant for users under 18 without your own safeguards. It is not Apache or MIT, so if "open source" in the strict sense matters to your legal team, read the license file in the repository before you commit to it. The same license covers the GGUF and MLX conversions.

Muse Glimmer or Muse Spark Open: which Meta model you actually want

If you came here with a laptop, the answer is Muse Glimmer, Meta's 30B Apache 2.0 model, which runs on a 24 GB machine with Ollama or LM Studio; our Muse Glimmer guide has the commands. If you came here with a budget, Muse Spark Open on SageMaker gives you the big model by the hour with nothing to buy. The two-Mac-Studio build is the romantic option, and it's real, but it's a workstation-class purchase for a model you can rent. Ethan's plan for the shop: Glimmer on the back-room PC for the daily ticket triage, and a JumpStart endpoint for the one afternoon a month when something needs the big brain.

When it doesn't work: the errors we'd check first

Ethan didn't download anything. He filed the p5e quota request for the shop's AWS account, and while it was pending he put Muse Glimmer back to work on the ticket queue. When the quota came through, the JumpStart endpoint took nineteen minutes to reach InService, answered the first request with four paragraphs of reasoning before the code, and was deleted forty minutes later with the job done. Jake's verdict: "So the big one lives in the cloud and visits." Ethan said that was exactly how a 816-billion-parameter model should be treated.

Revision note. Written October 15, 2026, the day Muse Spark Open's weights, the SageMaker JumpStart listing and the GGUF files appeared. Cut your coat according to your cloth, says the proverb; here the cloth is memory, and the coat is 816 billion parameters.