- Amazon says Meta's open-weight coding model, Muse Spark Open, can now be deployed to an endpoint inside a customer's own AWS account.
- Only 42 billion of its 816 billion parameters work on each token, but the servers must hold all 816 billion, so memory decides the instance.
- Before committing, benchmark both variants on your own code, and decide what tools and access an agent will get.
A coding assistant that can read an entire codebase is only as trustworthy as the place it runs. That place is now a purchasing decision, not just a technical one.
On October 15, 2026, Amazon Web Services published a guide to deploying Meta's Muse Spark Open in Amazon SageMaker JumpStart, its model hub. Meta describes the model as built for coding and for "agentic" work, where software plans a task, acts, checks the result and corrects itself. AWS says the model can be deployed to an endpoint in a customer's own AWS account.
The announcement is a deployment guide, not a benchmark. It gives no prices and no accuracy results. What it does give is a clear picture of how the model is built and what that means for the bill.
Why the bill follows memory, not work
Muse Spark Open uses a design called mixture-of-experts. The model holds 816 billion parameters, the numbers that store what it has learned. For each token, a word or fragment of code, only 42 billion of them are used.
Think of a large firm that keeps every specialist on the payroll. Any single case calls on only a few of them. But all of them still need desks in the building.
AWS makes the same point. Sparse activation keeps the compute per token low. But the full set of 816 billion parameters has to be loaded onto the GPUs, so memory size drives the choice of server.
That is why the two versions differ so much. The full-precision version, called BF16, runs on ml.p6-b300.48xlarge instances. A compressed version, called NVFP4, stores weights in a 4-bit format. AWS says it needs roughly a quarter of the memory, and it runs on ml.p5e.48xlarge.
AWS suggests trying NVFP4 first when sizing for cost. It adds that teams should test it on their own workloads to confirm quality. That caveat matters. Compression can change results, and the post offers no measurements either way.
There is also a running cost. AWS notes that these multi-GPU instances are billed for as long as the endpoint runs, whether or not it serves requests. An idle test endpoint still adds to the bill.
What 'in your account' does and does not settle
The model's context window is 1 million tokens. AWS says that lets it take in a whole project, including dependencies and legacy code, without splitting the task. For a company with a large private codebase, that is the appeal.
The control story is concrete. AWS says the endpoint can sit inside the customer's own virtual private cloud. Its storage can be encrypted with the customer's own key, and network isolation can be switched on. Teams also pin the model version, so it changes only when they redeploy. Because the endpoint lives in the customer's account, AWS says the machines that handle code and prompts are ones the customer sets up and controls.
A further point matters here. AWS states that browsing the web, coordinating subagents and operating computers are capabilities of the model. On SageMaker, the customer's own application or agent framework supplies the tools, browser and computer environment.
The lesson here is that the model decides what it can attempt, and you decide what it can touch. Hosting it privately answers where the data goes. It does not answer what an agent is allowed to do once it has tools.
One feature helps with that. The endpoint returns the model's reasoning alongside its answer, and reports how many tokens the reasoning used. AWS says this lets you follow what an agent is doing and why. That gives a security or audit team a view into what an agent was doing. Keep in mind that the reasoning is the model's own account. The post does not say it is a complete or faithful record of every action.
Questions to put to your team
Availability is narrow for now. At launch the model is offered in US East (N. Virginia) and US East (Ohio). Teams also need service quota for the large instance types before they can deploy.
Before approving a pilot, ask these questions.
First, which of the two versions did we test on our own repositories, and what did we measure? AWS itself advises benchmarking both before choosing an instance for production.
Second, who owns shutting down test endpoints, and is there an alert when one runs idle?
Third, what tools, credentials and sandbox will a coding agent get? A role broad enough for a walkthrough is not one to carry into production. AWS says as much about its own example policy.
Fourth, have legal and security reviewed the Muse Model License, including the Muse Spark Usage Policy? AWS notes the model is gated and requires accepting an end-user license agreement.
Private hosting moves the question from whom to trust to what to configure. The model arrives with its abilities built in. The limits are yours to set.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS.
