Meta Releases Muse Spark Open Weights: 816B Parameters, 1 Million Token Context, Runs on Two Mac Studios, Supporting Local Coding and Agent Tasks

Meta has released its open-weight model Muse Spark Open, positioning it as the most capable American open-weight model to date. Its core highlights include:

• Built for code and agents: Focused on end-to-end complex software engineering, long-horizon planning, and multi-step reasoning.
• Mixed-modality input with text-only output: Native support for interleaved text, image, video, and audio inputs, outputting unified text and structured tool calls.
• Self-hosting and on-premise deployment: In addition to cloud APIs, it can run on user-owned hardware. The official desktop deployment path utilizes two M5 Ultra Mac Studios, each equipped with 512GB of unified memory, running an NVFP4 quantized checkpoint.

How it handles programming and video editing workflows

In practical tasks, Muse Spark Open supports multimodal mixed input and text-only output, offering a context window of up to 1 million tokens (1M). A 1M window represents the maximum context capacity; it does not guarantee reliable retrieval or 100% execution success across arbitrary ultra-long materials.

The core use case targeted by the model is end-to-end agent development. Downloading model weights does not instantly grant out-of-the-box computer operation capabilities. The model itself is responsible for understanding inputs, planning steps, and generating interface-compliant tool invocation text; concrete actions must be executed on its behalf by an external agent framework (such as Muse Code or open-source agent runtimes) within sandboxes, terminals, or the operating system. This workflow operates through the following stages:

1. Reading inputs and environment feedback: The model ingests code files, user requests, screenshots, or execution outputs returned from previous tool steps.
2. Generating tool invocations: The model analyzes the current state and produces the next tool name and parameters to call (such as editing a file, executing a shell command, or querying an API).
3. External framework execution and feedback: The external agent framework executes the action in the actual environment and returns standard output, error logs, or updated screenshots back to the model.
4. Analyzing and refining plans: If execution encounters dependency conflicts, compilation errors, or failing tests, the model adjusts parameters, edits code based on returned error diagnostics, and tries again. Every step still requires outcome verification.

Consider a typical UI debugging task: a user provides the agent with a screenshot of a misaligned webpage alongside the corresponding front-end component source code. The model first correlates the visual misalignment in the screenshot with the code structure, infers conflicting style properties, and outputs a patch; the external agent framework writes the modifications to disk and runs the local build command; if the build tool returns a syntax error, the framework passes the error log back to the model; the model inspects the error, refines the code, and instructs the framework to run and inspect the build again. This example illustrates how the workflow operates; it does not imply the model will succeed on every attempt.

Technical case studies published by Meta demonstrate similar procedural workflows:

• iOS client Ice Cubes development: On local hardware (on-device, which does not equal completely offline), the model drove Muse Code to inspect open-source Mastodon client code, pinpoint bugs, write patches, and complete local project builds.
• DaVinci Resolve video processing: Acting as an agent driving DaVinci Resolve, the model reviewed footage frame-by-frame to identify the strongest moments and executed vertical reframing and cropping.

Why store 816B weights when computing with only 42B parameters?

The released model contains 816 billion total parameters. Muse Spark Open's ability to run across two desktop machines stems fundamentally from its sparse Mixture of Experts (MoE) architecture:

• MoE expert architecture: The model contains 816B total parameters across 62 layers. Each MoE layer houses 256 expert feed-forward networks; during per-token generation, the front-end router selects the 8 most relevant experts for computation, resulting in approximately 42B active parameters per token across the entire model.
• Compute and memory bandwidth overhead: Although only 42B parameters are activated per token, actual floating-point operations and latency cannot be equated directly to a dense model of equivalent active size. Attention layers, routing decisions, memory bandwidth, and multi-node communication all introduce additional overhead.
• Weight residency: This official deployment path still requires loading the entire weight set into memory or VRAM. Invoking only a small fraction of experts reduces the portion participating in computation at each step; it does not remove the remaining parameters from the model.

Running this model on two Mac Studios requires the following setup:

1. Unified memory configuration: Two Mac Studios powered by Apple M5 Ultra chips, each configured with 512GB of unified memory (totaling 1TB unified memory), or four 256GB machines. Memory capacity dictates where weights reside, while bandwidth dictates how quickly weights are fetched: each M5 Ultra provides 1.2TB/s of unified memory bandwidth, allowing GPUs to rapidly stream the weights needed for the current token. Real-world generation speed also depends on compute throughput and dual-machine communication.
2. NVFP4 quantized checkpoint: The setup runs NVFP4 weights, primarily compressing MoE expert weights to 4-bit while retaining BF16 on select layers, resulting in a static file size of approximately 537GB. The 537GB figure represents only the weight file size; runtime execution requires allocating memory for the KV cache to store processed context, intermediate activation buffers, and the operating system. Therefore, subtracting weight file size from total memory does not guarantee sufficient headroom to run a full 1M context window.
3. MLX tensor-parallel sharding: Leveraging the latest Apple MLX framework, each layer's 256 experts are tensor-sharded across both machines, with each device hosting a shard of the weights (rather than assigning the first 128 experts to Mac A and the remaining 128 to Mac B). During inference, weights remain resident locally, while intermediate activations are exchanged between devices over direct Thunderbolt 5 connections with RDMA enabled.

Beyond the dual-Mac desktop environment, official documentation also outlines datacenter GPU deployment configurations:

• NVFP4 deployment path: Static weights occupy approximately 537GB, with official requirements specifying at least 700GB of VRAM. This has been validated on a single node with 4 NVIDIA Blackwell Ultra GPUs (running via TensorRT-LLM) or 8 H200 GPUs.
• BF16 reference path: Full-precision weights occupy approximately 1.65TB, with documentation examples budgeting around 2TB of VRAM (such as an 8x NVIDIA B300 cluster).

Third-party provider Unsloth also offers a Dynamic GGUF single-workstation path. Its 2-bit quantization lists total memory requirements of approximately 250–316GB, representing combined system RAM and VRAM, or unified memory on Apple hardware. The smallest profile, UD-IQ2_XXS, fits into a 256GB machine; however, Unsloth recommends at least UD-IQ2_S for agent tasks, as smaller variants degrade on general-purpose workloads, whereas chat tasks can tolerate smaller footprints. Consequently, casually chatting with the model versus running continuous code refactoring may demand entirely different quantization profiles. Longer contexts also consume additional memory; task quality and execution speed for specific quantization variants still warrant independent evaluation. Quantization variants and selection criteria can be reviewed in the Unsloth Guide.

Once weights are loaded, speculative decoding can reduce generation latency: a smaller draft model proposes multiple tokens, and Muse Spark Open verifies the batch of candidates in a single pass, accepting matching tokens and reducing sequential generation passes by the large model. SGLang pairs with DFlash V2, while vLLM pairs with DSpark. The official developer guide reports that DFlash achieves a 3.7x single-request throughput speedup on AMD MI355X, and 2.9x under 16 concurrent requests; these results reflect the specific GPU and benchmarking setup and cannot be converted into dual-Mac execution speeds.

Low-level compute execution is also optimized: Helion GPU kernels in SGLang achieve 1.03–3.95x kernel-level speedups on NVIDIA and AMD GPUs, whereas end-to-end gains on AMD MI350 reach 3%. How much an isolated kernel accelerates differs fundamentally from end-to-end request speedups.

How do its benchmark results translate to real-world tasks?

Meta positions Muse Spark Open as the "most capable American open-weight model to date." According to the official evaluation methodology, published benchmark figures were not all independently tested by Meta; rather, they blend third-party public leaderboards (such as Scale AI and Artificial Analysis), Meta internal benchmarks, and vendor-reported numbers. All models were tested with their officially recommended maximum thinking settings enabled (e.g., xhigh for Muse, max for GLM and Kimi, thinking enabled for Nemotron); having similar high-tier setting names does not imply identical compute, time, or cost expenditures.

The same comparative scorecard reveals concurrent strengths and deficits:

Expand to view official cross-model benchmark scorecard

• Strengths: Muse Spark Open leads listed models on JobBench (61.8), which evaluates real-world workplace workflows, and MCP-Atlas (89.2), which tests genuine MCP protocol tool invocations. It scores 26.1 on the tool-free HLE-Diamond advanced knowledge and reasoning QA benchmark, 25 on the AA-Omniscience factual reliability test, and 50.0 on the multimodal vision benchmark ZeroBench (note that this score reflects a tool-assisted pass@5 metric—at least 1 success out of 5 samples—rather than single-attempt accuracy).
• Deficits: On interactive real-terminal tasks in Terminal-Bench 2.1, it scored 76.4, trailing Kimi K3 (85.0), GLM 5.3 (83.9), Qwen3.8 (82.0), and Beam (80.1; note that Beam did not disclose its runtime framework, whereas remaining terminal scores used Terminus 2). On software defect repair in DeepSWE 1.1, it scored 60, trailing Kimi K3 (68) and GLM 5.3 (67). DeepSWE models were executed with their respective preferred agent frameworks (such as Muse Code, Claude Code, Kimi Code, etc.), reflecting the combined performance of the model and its agent scaffolding.

These results corroborate targeted strengths on specific tasks: Muse Spark Open leads listed baselines on JobBench and MCP-Atlas, but does not sweep across composite indices, Toolathlon long-horizon workflows, or software engineering. When choosing a model, evaluate it against your own business workflows and MCP tools first; if your workloads center heavily on terminal operations, automated bug fixing, or cross-software long-horizon workflows, compare combinations of alternative models and their respective runtimes. The model underwent additional safety post-training. When integrating tools in practice, outer software wrappers must still manage permissions and enforce human-in-the-loop confirmation for irreversible operations.

Where to start and how pricing works

Developers and enterprise teams can choose deployment options based on practical requirements:

1. Managed Cloud APIs: Third-party inference providers offer hosted model access, including Baseten, Fireworks AI, Modal, Nebius, OpenRouter, and Together AI; Groq currently provides a limited preview tailored for multi-step agent loops. Free usage rights granted under the Muse license apply strictly to the model weights themselves, not to cloud API inference; hosting platforms bill independently based on token consumption or dedicated compute resources.

2. Cloud Model Catalogs: Model weights and private deployment options are accessible directly via online catalogs on Amazon SageMaker AI, Google Cloud Model Garden, and Microsoft Foundry Models.

3. Local and On-Premise Cluster Deployment: Developers can visit the Hugging Face model collection to download NVFP4 or BF16 weights. The dual-Mac route begins with the Official Meta Mac Deployment Guide: each machine must run macOS 26.2 or later, MLX 0.30.1 or later, connect directly via Thunderbolt 5 with RDMA enabled, and allow the primary machine to launch processes on the secondary via passwordless SSH.

   Store full files on disk, load shards into memory. According to the guide, each Mac must hold the complete ~537GB NVFP4 checkpoint on its local disk; upon startup, MLX loads only the respective tensor shards into unified memory. Therefore, each machine cannot reserve disk space for merely half of the weight files.

   Private GPU nodes can be orchestrated with SGLang, vLLM, or TensorRT-LLM, with specific setups detailed in the developer notes; for low-bit single-workstation setups, refer to the Unsloth route described above.

4. Post-Training and Fine-Tuning: Teams looking to further adapt the model to specialized domain data can utilize supported frameworks such as PyTorch's TorchTitan.

Inference requests can configure reasoning_effort across four tiers: low, medium, high, and xhigh. The model card defaults to xhigh; complex programming and agent tasks recommend high or xhigh, while simple tasks prioritizing lower latency can use low or medium. Officially recommended sampling parameters are temperature = 1.0, top_p = 1.0, with top_k disabled.

Muse Model License terms

Muse Spark Open is released under the open-weight Muse Model License. Subject to its terms, users may modify, fine-tune, distill, merge, and redistribute the model, and Meta explicitly disclaims ownership over outputs generated by the model. Use remains contingent upon attribution, the Usage Policy, and commercial service stipulations, with three primary obligations:

1. Attribution requirement: Any product or service built upon the model or its derivatives must prominently display "Built with Muse Spark Open" across user interfaces, accompanying documentation, websites, or settings.
2. Usage Policy compliance: Usage and distribution must adhere to the safety and compliance standards outlined in the accompanying Usage Policy.
3. Additional agreement for MaaS: Entities offering Model-as-a-Service (MaaS—providing model outputs to third parties via API or comparable interfaces) whose cumulative gross revenue across the entity and its affiliates exceeds US$20 million within any rolling 12-month period must provide advance notice to Meta and execute a separate written license agreement.

This MaaS limitation explicitly exempts internal enterprise use, research, other non-MaaS commercial operations, and embedding the model as an underlying component to provide functionality within an entity's own non-MaaS products.