Meta's Muse Spark Open lands in Amazon SageMaker JumpStart
Meta's Muse Spark Open, an open-weight model optimized for coding, is now available in Amazon SageMaker JumpStart. Users can deploy it to an endpoint in their own AWS account without managing the serving infrastructure themselves, according to AWS.
- Meta's coding-optimized open-weight Muse Spark Open is now in Amazon SageMaker JumpStart.
- The MoE model has 816B total and 42B active parameters and a 1M-token context window.
- BF16 runs on ml.p6-b300.48xlarge, NVFP4 on ml.p5e.48xlarge and needs roughly a quarter of the memory.
- At launch it is available in US East (N. Virginia) and US East (Ohio).
- The endpoint runs in the customer's AWS account, with VPC, KMS and network isolation options.
A large mixture-of-experts model built for coding agents
Muse Spark Open uses a mixture-of-experts (MoE) architecture with 816 billion total parameters, of which 42 billion are active for each token. AWS explains that this lets the model hold the capacity of a very large network while the compute spent per token is closer to that of a much smaller dense model.
Meta describes the model as coding-optimized and trained for agentic coding workflows, with a focus on first-attempt accuracy, tool calling and understanding of large codebases. It is a reasoning model that accepts text, images, documents, audio and audio-video as input and returns text. Its context window is 1 million tokens, which AWS says allows the model to take in a whole project, including dependencies, legacy code and thousands of files, so tasks do not need to be split up.
Meta says the model plans, acts, observes the result and corrects itself over long horizons, rather than making single tool calls. It was also trained to browse the web, coordinate subagents and operate computers across desktop, mobile and browser environments. AWS stresses that on SageMaker AI these are model capabilities: the application or agent framework must supply the tools, browser and computer-use environment. The endpoint returns the model's reasoning alongside its answer, so users can follow what an agent is doing and why.
The weights are released under the Muse Model License, which includes the Muse Spark Usage Policy.
Two variants and the instances they need
SageMaker JumpStart offers two variants: BF16 (Muse-Spark-Open-816B-A42B) and an NVFP4 quantized version (Muse-Spark-Open-816B-A42B-NVFP4). Although sparse activation keeps per-token compute low, serving still requires enough GPU memory to hold all 816 billion parameters, so instance choice comes down to memory capacity.
The NVFP4 variant stores weights in NVIDIA's 4-bit floating point format and needs roughly a quarter of the memory of the BF16 weights. It runs on ml.p5e.48xlarge, while the BF16 variant runs on ml.p6-b300.48xlarge. AWS suggests trying NVFP4 first when sizing for cost, and recommends evaluating it on your own workloads to confirm the quality fits the use case.
At launch, the model is available in US East (N. Virginia) and US East (Ohio). Both instance types are multi-GPU machines, and an endpoint is billed for as long as it runs, whether or not it serves requests. AWS advises deleting the endpoint when finished.
Deployment and control in your own account
The model can be deployed from SageMaker Studio or with the SageMaker Python SDK, and each path creates a real-time endpoint in the user's account. In Studio, users search for Muse Spark Open in JumpStart, open the model detail card, accept the end-user license agreement because the model is gated, choose an instance type and deploy. AWS says deployment typically takes 15 to 20 minutes while the instance is provisioned and the weights are loaded.
For the SDK route, the model IDs are meta-vlm-muse-spark-open-816b-a42b for BF16 and meta-vlm-muse-spark-open-816b-a42b-nvfp4 for NVFP4. The SDK path requires Python 3.10 or later and SageMaker Python SDK v3, and deployment requires setting accept_eula=True. Users also need an AWS account with the right permissions, a SageMaker execution role and service quota for the chosen instance type.
Because the endpoint runs in the customer's account, source code and prompts are processed on infrastructure the customer configures. Options include attaching the endpoint to an Amazon VPC, encrypting the storage volume with an AWS KMS key and turning on network isolation. Users also set the instance type and scaling limits and pin the model version, so the model only changes when they redeploy.
What it means for developers
AWS points to three use cases: coding assistants over private repositories, long-running coding agents that edit across files and run tests in a sandbox, and multimodal engineering workflows that turn screenshots, design documents or recorded bug reports into a reproduction plan or draft fix.
For teams that want to keep code inside their own cloud environment, the release offers a managed route to a large open-weight coding model. The hardware requirements are substantial, though, and the choice between the two variants will largely determine cost.
