Meta releases Muse Spark Open, but self-hosting is still an infrastructure decision
Meta has opened the weights of a large multimodal agent model, but 700GB of GPU memory, operating effort and licence conditions still determine whether migration pays.
What shipped
Meta released Muse Spark Open on October 15, an open-weight multimodal model aimed at coding and agentic work. It has 816 billion total parameters, activates 42 billion per token, supports a 1M-token context window and accepts text, image, audio and video inputs.
Openness has a bill
Open weights do not remove the serving bill. Meta specifies at least 700GB of GPU memory for the NVFP4 checkpoint and 2TB for BF16, while local MLX deployment is optimized for two M5 Ultra Mac Studios. Commercial use is allowed, but the licence requires attribution and a separate agreement for certain larger model-as-a-service providers.
One early independent result is promising, not decisive. Muse Spark Open completed 38 of 43 questions, or 88%, in Plotly’s analytics test; the run cost $5.16 through OpenRouter and had a median time of 48 seconds per question.
Our production call
Virtual Arc would first test the hosted version on real workflows, using the same tools, cache patterns, limits and retry policies as production. We would measure cost per successfully completed task rather than token price or a single aggregate benchmark.
Self-hosting becomes rational when private data, consistently high utilization or deep customization pays for the hardware and the on-call team. Until then, we would keep Muse Spark Open as a fallback route and a way to reduce single-vendor dependency, not as a reason for an urgent migration.
Meta’s release of Muse Spark Open matters because it gives teams an open-weight, multimodal agent model with a 1M-token context window and enough capability to deserve a real bake-off. It does not make frontier inference cheap. The NVFP4 checkpoint still calls for at least 700GB of GPU memory, while the licence adds attribution and a separate-agreement trigger for larger model-as-a-service businesses. Virtual Arc would not migrate a production agent stack on the strength of openness alone. We would test it through a hosted provider against our own completed-task suite, including tool failures, retries, latency and cache behaviour, then model the utilization needed to beat API pricing. Self-host only where data control, sustained volume or customization pays for the serving team; otherwise use the release as leverage to reduce dependency on any single closed vendor.