TL;DR: Meta released Muse Spark Open on October 15, 2026, introducing an open-weight multimodal model designed for coding, tool use, and autonomous agent workflows. With approximately 816 billion total parameters, 42 billion active parameters per token, and up to one million tokens of context, the release brings large-scale MoE capabilities to downloadable model weights and hosted inference services.
The core trade-off: you gain deployment and customization control, but you take on hardware, licensing, and evaluation costs. Meta calls it the most capable US open-weight model. That claim does not mean it ranks first on every global benchmark.
Key Takeaways
- Muse Spark Open uses a sparse Mixture-of-Experts architecture with approximately 816B total parameters and 42B active parameters per token, and supports up to 1M tokens of context.
- Muse Spark Open accepts text, image, audio, and video inputs, and generates text outputs.
- Meta designed Muse Spark Open for coding, reasoning, tool use, and multimodal agent workflows.
- Meta provides Muse Spark Open checkpoints in BF16 and NVFP4 formats, while community projects offer additional quantized variants.
- Muse Spark Open’s downloadable weights do not make it unrestricted open source or inexpensive to self-host.
What Is Muse Spark Open? Specs and Overview
Muse Spark Open is a large-scale, open-weight multimodal model from Meta. It uses a sparse MoE architecture for software engineering and agentic tasks, including repository inspection, code editing, tool use, and interpretation of visual or audio observations.
Muse Spark Open Specifications
| Specification | Muse Spark Open specifications |
|---|---|
| Developer | Meta |
| Release date | October 15, 2026 |
| Architecture | Sparse Mixture of Experts (MoE) |
| Total parameters | Approximately 816B |
| Active parameters | Approximately 42B per token |
| Experts / selected experts | 256 / 8 per MoE layer |
| Transformer layers | 62 |
| Context window | Up to 1,048,576 tokens |
| Inputs | Text, images, audio, video |
| Output | Text |
| Checkpoints | BF16, NVFP4 |
| Inference | Transformers, llama.cpp, SGLang, vLLM, MLX, TensorRT-LLM, and Unsloth (Meta launch announcement) |
| License | Muse Model License |
The published architecture diagram shows the model components.
What Can Muse Spark Open Do?
Sparse MoE Architecture
Each MoE layer offers 256 experts and routes a token to eight. Sparse activation helps reduce computation relative to running all 816B parameters densely, while preserving a large total capacity. It does not remove the memory needed to store model weights or the communication overhead of expert-parallel systems.
Native Multimodal Understanding
A single model processes text, images, audio, and video inputs and produces text. This supports workflows such as screenshot-guided debugging, interface inspection, transcription-assisted tasks, and visual browser agents. It accepts images, audio, and video as inputs; it does not generate images, music, or video as outputs.
Long-Horizon Coding Agents
Meta emphasizes multi-file refactoring, debugging, tool invocation, and iterative agent execution. A long context window helps agents retain source code and task history, but success still depends on retrieval, tool permissions, validation, and the distribution of relevant information across context.
Reasoning and Tool Use
The inference ecosystem supports configurable reasoning effort and tool-call parsers. Low reasoning effort is a practical baseline for inexpensive tasks; more demanding workflows may warrant larger reasoning budgets, subject to measured improvements in task completion.
How Does Muse Spark Open Perform on AI Benchmarks?
The following are launch results reported in Meta’s model card, not measurements performed for this article. Meta specifies xhigh reasoning effort, temperature 1.0, top_p 1.0, and disabled top_k. Benchmark-specific harnesses matter; the summary does not provide a complete hardware configuration for reproducing every score.
| Evaluation | Meta-reported result | Scope |
|---|---|---|
| Artificial Analysis Intelligence Index | 39 | Third-party composite index reproduced by Meta |
| Terminal-Bench 2.1 | 76.4 | Terminus 2 agent; harness-dependent coding evaluation |
| VideoMMEv2 | 61.5 | Video evaluation; not a throughput measurement |
Interpreting Muse Spark Open Benchmarks
These values use different scales and should not be averaged. Reproduce your own repository and tool workflows with matched budgets, stopping rules, and model settings. Track successful completion, retries, latency, and total cost; a benchmark score does not establish production reliability.
How to Deploy: Local, API, and Cloud
Choose local deployment for control over weights and data, a hosted API for a quick evaluation, or a managed cloud endpoint for dedicated serving. Check the exact checkpoint, supported inputs, and serving context before choosing a route.
Local Deployment
Memory is the main constraint for local deployment. By raw parameter count, BF16 weights alone occupy about 1.6 TB; Meta’s deployment guidance specifies at least 2 TB of GPU memory for BF16 and 700 GB for NVFP4; runtime buffers and KV cache must also fit. Quantized community configurations have different footprints.
Two different Apple Silicon configurations are documented. Meta’s launch announcement describes deployment across two Apple M5 Ultra Mac Studio machines using MLX. Separately, the Llama.cpp section of Hugging Face’s launch article reports an imatrix-calibrated 2-bit quantization on a 512 GB Mac M3 Ultra, using about 304 GB for the model and generating approximately 18 tokens per second. These reports refer to different hardware and inference configurations; neither establishes equal quality across quantizations.
| Deployment | Advantage | Consideration |
|---|---|---|
| Apple Silicon / MLX | Unified memory, local controls | Memory and performance limits |
| llama.cpp quantization | Accessible GGUF ecosystem | Accuracy/quality trade-offs |
| NVIDIA GPUs / SGLang | NVFP4 optimized parallel inference | Several high-memory accelerators |
| vLLM | Scalable serving integrations | Plugin, checkpoint, hardware constraints |
| Hugging Face Inference Endpoints | Managed infrastructure | Ongoing hosting cost |
| Hosted API provider | Minimal setup | Provider availability and privacy terms |
Example: serve the Q2 checkpoint with llama.cpp.
Install the llama runtime and start the large Q2 checkpoint using the published llama.cpp recipe. This requires a compatible high-memory machine.
curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q2_K
This example requires enough memory for a very large quantized model; it is not a command intended for an ordinary laptop. Once the server starts, its OpenAI-compatible interface can be called using a compatible client.
Hosted API Access
Use the Groq example below for a hosted API request. For a dedicated cloud deployment, Hugging Face provides a managed Inference Endpoints recipe. Check the selected instance, endpoint context limit, and ongoing hosting charges before provisioning.
Groq documents limited-preview access for approved organizations. Install its Python SDK with pip install groq and set GROQ_API_KEY before running this text-only request.
from groq import Groq
client = Groq() # Reads GROQ_API_KEY from the environment
response = client.chat.completions.create(
model="meta-models/muse-spark-open",
messages=[{"role": "user", "content": "Explain MoE routing."}],
)
print(response.choices[0].message.content)
This example requires preview access and has not been executed with a paid account for this article. Groq currently documents a 131,072-token context window and text/image input; the hosted service does not expose every native model modality.
How Much Does Muse Spark Open Cost?
Downloading weights and paying for inference are different cost questions. Providers may charge per input/output token, provisioned capacity, or dedicated hardware. Self-hosted usage carries GPUs, memory, storage, electricity, operations, and engineering effort.
For illustration only, the following scenario assumes $1.25 per 1M input tokens and $4.25 per 1M output tokens. These are not verified universal or CometAPI rates.
| Illustrative workload | Input tokens | Output tokens | Calculated charge |
|---|---|---|---|
| Short coding task | 10,000 | 2,000 | $0.0210 |
| Repository review | 100,000 | 10,000 | $0.1675 |
| Large agent workflow | 500,000 | 50,000 | $0.8375 |
| Million-token analysis | 1,000,000 | 20,000 | $1.3350 |
Formula: estimated cost = input tokens / 1,000,000 × input unit rate + output tokens / 1,000,000 × output unit rate. Caching, retries, infrastructure, and provider-specific charges can change the total.
Is Muse Spark Open Really Open Source?
Unlike a closed-weight API-only service, Muse Spark Open offers checkpoints for developer-managed inference. Organizations can compare locally hosted systems, dedicated cloud deployments, and managed endpoints based on privacy, customization, quality, and operational cost.
Muse Spark Open is distributed as open weights under the Muse Model License. Downloadable checkpoints do not imply unrestricted open-source rights. Review the license conditions for redistribution, derivatives, attribution, and hosted model services before deployment.
Teams should review the current license text before using the weights in customer-facing products, redistributing modified checkpoints, or promising downstream usage rights.
Muse Spark Open vs Muse Spark Hosted API
Choose Muse Spark Open when you need control over model weights and deployment. Choose a hosted API when you want managed inference without operating the serving stack.
Model identity and deployment method are separate. Muse Spark Open is an open-weight release, while a hosted endpoint may serve a different Muse Spark version. Check the exact model ID and version before comparing them. Meta’s Muse Spark 1.1 announcement is one example of a Muse Spark model offered through the Meta Model API.
| Aspect | Muse Spark Open | Hosted Muse Spark API (e.g., 1.3 Standard / Contributor) |
|---|---|---|
| Weights | Open (downloadable BF16 & NVFP4 checkpoints from Hugging Face, etc.) | Closed (no weights released) |
| Release | Oct 15, 2026 | 1.3: Sep 2, 2026 (earlier 1.1/1.2 also available) |
| Size / Architecture | 816B total parameters, ~42B active per token (MoE: 256 experts, 8 active) | Not publicly disclosed (same base as Open per Meta statements) |
| Context | 1M tokens | 1M tokens |
| Modalities | Text, image, video, audio in; text out | Text, image, video, PDF (and sometimes audio) in; text out |
| Pricing (per 1M tokens) | Self-host: hardware cost only | Meta Standard: $1.25 input / $0.15 cached / $4.25 output Contributor: $0.10 / $0.002 / $0.20 (data used by Meta) |
| Access | Self-host | Meta Model API ， Muse Code, or aggregators like CometAPI / OpenRouter |
| License / Terms | Muse Model License (commercial use allowed with conditions; large-scale Model-as-a-Service >$20M revenue needs Meta agreement; attribution requirements) | Proprietary Meta terms; Contributor tier permits Meta to train on your data |
| Safety / Post-training | Extra safety post-training for standalone use without Meta guardrails | Integrated with Meta’s system guardrails |
Muse Spark Open and the hosted Muse Spark API share the Muse Spark family focus on coding, agents, long-horizon tasks, multimodal inputs (text + image/video/audio/PDF), tool calling, and a 1M-token context window, but differ fundamentally in distribution, access, and control.
Practical Differences
- Control & Privacy: Open lets you self-host (requires substantial hardware: ~700 GB+ VRAM for NVFP4 or ~2 TB for BF16) so data stays on your infrastructure. Hosted routes everything through Meta or the provider.
- Cost at scale: Self-hosting requires hardware or cloud capacity, storage, operations, and engineering time. Hosted APIs reduce those infrastructure costs but add usage fees, quotas, and possible retry costs. Compare the total cost for your workload instead of assuming that either option is always cheaper.
- Features & Performance: Both support tool calling, reasoning effort levels (low/medium/high/xhigh), and agentic coding. Open is tuned for standalone robustness; closed versions integrate more tightly with Meta products (Muse Code, Meta AI). Benchmarks are close; Open is positioned as the strongest US open-weight model at release, while closed 1.3 was the recommended production endpoint before Open launched.
- Flexibility: Open enables fine-tuning, custom quantization, and local/offline use. Hosted is simpler (no infra) and includes the cheaper Contributor tier if you accept data usage.
Which to Choose?
- Prefer Muse Spark Open when you need self-hosting, fine-tuning, offline or air-gapped deployment, maximum data control, or greater control over model serving.
- Prefer the hosted Muse Spark API (especially 1.3 Standard or Contributor) for simplest official access, Muse Code integration, potentially lower cost via Contributor, and Meta-managed infrastructure/safety.
- Via an aggregator like CometAPI: Useful for easy switching, unified billing, and comparing both (plus competitors) without multiple accounts. Verify
CometAPI as an Alternative Access Route
CometAPI provides an OpenAI-compatible interface for supported models. Its catalog lists Muse Wonder, which can be evaluated as a separate Meta model. Muse Wonder is not Muse Spark Open, and its listing does not establish that Muse Spark Open is available through CometAPI. Confirm the model ID, access, supported inputs, context limit, and current rates before integrating it.
For a pilot, run the same representative tasks against your shortlisted endpoints and compare successful completion, latency, and total cost including retries. Use CometAPI when convenient access to several supported models is the priority; choose a verified Muse Spark Open endpoint when that exact model is required; self-host when weight-level control justifies the operational effort.
What Is Muse Spark Open Used For?
- Best fit: Teams building coding agents or multimodal interface analysis workflows that benefit from direct access to model weights.
- Conditional: Private enterprise inference and model adaptation research, provided the team has sufficient infrastructure, evaluation capacity, and a suitable license arrangement.
- For occasional prototypes: Start with a hosted API to avoid committing to dedicated infrastructure before validating the workload.
What Are Muse Spark Open’s Main Limitations?
- Ordinary laptop chat is a poor fit: full-size inference requires substantial memory even with sparse activation. Consider a smaller model or hosted access for lightweight use.
- Native media generation is not supported: the model produces text, so image, music, and video generation require separate models or tools.
- Inference quality and throughput are sensitive to quantization and parallel deployment.
- The custom model license must be checked for the intended commercial use.
- Agent demos are not proof of unattended production safety or consistent tool execution.
FAQ
Why can a Muse Spark Open endpoint reject a long prompt?
Check the endpoint’s configured context limit, reserved output budget, and multimodal token accounting. The model’s maximum window is not a promise that every deployment serves that length. Reduce the request or choose a deployment explicitly configured for the required context.
How should you validate Muse Spark Open after quantization?
Replay a fixed set of representative tasks against the original and quantized checkpoints using the same prompts, tools, and budgets. Compare task success, malformed tool calls, and regressions on difficult inputs. Faster generation alone is not sufficient evidence to approve a quantized deployment.
What should you log when a Muse Spark Open agent fails?
Record the checkpoint, runtime version, reasoning settings, input size, tool schemas, tool responses, and stopping condition. Redact secrets and personal data. Distinguish model errors from tool failures and context truncation so the next test changes the relevant component.
How should you budget a Muse Spark Open pilot?
Set a task-level spending cap and a maximum number of retries before running the evaluation. Record total billed usage and successful completions across the entire pilot, including failed attempts. Use that observed cost per success to estimate production spending.
Conclusion
Muse Spark Open makes a compelling case for enterprises and developers seeking frontier-scale multimodal reasoning with direct model-weight control. The combination of 816B total parameters, 42B active per token, up to 1M context, and agent-oriented training distinguishes it from simpler chat-oriented releases.
Its practical value depends less on the headline parameter count than on measured quality, deployment feasibility, legal fit, and cost per successful task. Start with a reproducible workload evaluation before scaling into production.