Meta Releases Muse Spark Open: 1M-Token Coding Model With Hosted and Self-Managed Deployment Options
Muse Spark Open brings downloadable weights, a million-token context window and launch support across Together AI, SageMaker JumpStart and vLLM. Infrastructure and harness choices still matter.
Meta has released the weights for Muse Spark Open, a coding-focused model with a one-million-token context window and several deployment routes available at launch. Developers can evaluate it through Together AI, deploy an endpoint in their own AWS account through SageMaker JumpStart, or use launch-specific vLLM infrastructure. The consequential change is the ability to choose where this model runs and how it connects to an existing coding agent.
The PyTorch announcement describes an 816-billion-parameter mixture-of-experts model with 42 billion parameters active per token. It accepts multimodal inputs and is trained for coding and longer agent workflows. Those specifications make it a candidate for repository-scale work, but the supplied announcements do not establish independent coding performance or show that filling the context window improves every task.
Three routes to an evaluation
The deployment options address different operational needs. Together AI’s October 15 announcement says the model is live on serverless and dedicated infrastructure. Its published serverless prices are $1.25 per million input tokens, $4.25 per million output tokens and $0.15 per million cached input tokens. That offers a way to begin testing without first provisioning a large model-serving installation.
AWS’s deployment guide describes a different tradeoff: a SageMaker endpoint running in the customer’s AWS account, with configurable VPC attachment, storage encryption and container network isolation. JumpStart offers BF16 and NVFP4 variants. AWS lists launch availability in US East, Northern Virginia and Ohio.
| Route | What the publisher documents | Evaluation implication |
|---|---|---|
| Together AI | Serverless and dedicated availability | Begin with API-based workload comparisons |
| SageMaker JumpStart | BF16 and NVFP4 endpoints in your AWS account | Assess deployment controls and sustained infrastructure cost |
| vLLM | Launch-specific NVIDIA and AMD container images | Test a serving stack your team operates |
The vLLM launch post supplies prebuilt NVIDIA and AMD images, reasoning and tool-call parser settings, and speculative decoding support. There is a packaging caveat: the post says availability through nightly PyPI wheels depends on a code review and merge, which usually takes about a week. Teams should distinguish the documented launch containers from support in their existing installation.
Sparse compute still needs substantial memory
The 42-billion-active figure describes computation per token; it does not mean the full model fits wherever a 42-billion-parameter dense model fits. AWS explicitly says serving requires enough GPU memory to hold all 816 billion parameters.
For JumpStart, AWS maps NVFP4 to ml.p5e.48xlarge and BF16 to ml.p6-b300.48xlarge. It says NVFP4 weights need roughly a quarter of the memory of BF16 weights and recommends evaluating quality on the intended workload. These are substantial multi-GPU deployments, and AWS charges for an endpoint while it runs, including idle time. Open weights therefore change deployment control without removing infrastructure costs.
The weights are distributed under the Muse Model License, including the Muse Spark Usage Policy. The supplied evidence does not include the complete license, so teams should review its actual terms before deciding whether a particular deployment or modification is permitted.
The model still needs a working agent environment
Meta describes training for planning, tool use, browsing, computer interaction and coordinating subagents. AWS makes the operational boundary explicit: the application or agent framework supplies the tools, browser and computer-use environment. Deploying the model does not itself create a repository editor, test runner or permission system.
For an existing coding harness, a useful first evaluation is a contained multi-file refactor with a reproducible test suite. Compare completed tasks, tool-call failures, latency and total cost against the current model. Keep the repository snapshot and tool permissions consistent so the comparison measures the model integration rather than a changed environment. Automater’s guide to agent evaluation CI gates provides a relevant framework for turning that evaluation into a regression check.
The million-token window deserves its own comparison. Try selected repository context and a larger context bundle on the same tasks; record whether the additional input improves successful completion enough to justify its cost and latency. A capacity limit alone does not establish effective retrieval across every file.
Muse Spark Open’s launch is significant because downloadable weights arrive alongside concrete serving and customization paths. PyTorch also documents TorchTitan support for supervised fine-tuning, LoRA and reinforcement learning. Readers now have several ways to investigate the model, while the decision to adopt it should rest on measured repository work, deployment requirements and license review.