Meta released Muse Spark Open on 15 October 2026, making downloadable weights and partner-hosted inference available for coding and agentic workflows. The useful engineering question is where to evaluate it: an existing API account, a dedicated endpoint or infrastructure your team operates. Those choices have different capacity limits, costs and operational obligations.
This guide checks public documentation as of 22 October. Daphnis has not run the model, measured its speed or reproduced Meta's benchmark results. The layout-repair task, token volumes and acceptance thresholds below are proposed evaluation fixtures. They let a team compare deployments using work it can inspect, rather than treating a model-family name as a complete service specification.
Give the coding pilot a visible, testable defect
Create a small fictional interiors website with one deliberately broken mobile project card. At a 390-pixel viewport, a fixed-width child pushes the Enquire button beyond the right edge. Supply the repository, a failing screenshot and this brief: keep the card and action inside the viewport, preserve desktop proportions, and leave the enquiry destination unchanged. Do not supply the expected patch.
This is a useful setting for an image-aware coding evaluation because the screenshot shows the symptom while the source contains the cause. A model might correctly describe the clipping yet edit the wrong component. It might also hide horizontal overflow without making the button reachable. The acceptance check must inspect the resulting interface and the code change separately.
Daphnis's Urbanface case study documents an interiors website with film, image-led scrolling and a dedicated mobile experience. It explains the relevance of preserving both presentation and interaction. The fixture here is fictional; it is not an Urbanface defect, a Muse integration or evidence of a client outcome.
Check the endpoint before planning a million-token request
Meta's model card specifies 816 billion total parameters, 42 billion active per token and a 1M-token inference context. It lists text, image, audio and video inputs with text output. These describe the released model; an inference provider can expose a narrower interface.
For example, Groq's model documentation marks access as limited enterprise preview and asks organizations to contact Groq. Its endpoint, meta-models/muse-spark-open, lists a 131,072-token context, a 131,072-token maximum output and up to five input images, with text and image input. Those two token ceilings are not permission to submit both maxima simultaneously. Confirm the combined request budget with the provider.
By contrast, Modal's model page describes its Shared Endpoint as live and lists 1M context. The page does not establish a separate maximum output allowance. Neither a live endpoint nor released weights prove that every hosting option has the same general-availability status, supported modalities or service commitment. Record those terms for the specific account and deployment you will use.
For the mobile fixture, begin with the relevant component, styles, dependencies and two screenshots. Add repository context only when a failure reveals a missing dependency or convention. Log input size and rejected requests. A larger window is useful only if the agent finds the right evidence within it; a full repository dump can also increase repeated input cost and make a failure harder to diagnose.
Size self-hosting for resident weights and working memory
The active parameter count does not describe the weight storage you must provision. Meta's deployment guide puts the NVFP4 checkpoint at approximately 530 GB and describes multi-device serving configurations. The model card specifies at least 700 GB of VRAM for NVFP4 and 2 TB for BF16. Check the runtime recipe for how that capacity is distributed; these figures are not a claim that an ordinary single GPU suffices.
Checkpoint size and serving capacity answer different questions. In addition to holding weights, a deployment needs room for request state, runtime allocations and its chosen concurrency. Measure the intended prompt lengths and simultaneous jobs on the proposed configuration. A successful short request at concurrency one does not establish capacity for several long coding sessions.
For Apple hardware, Meta's deployment guide describes two 512 GB M5 Ultra Mac Studios or four 256 GB machines, connected for distributed inference. Treat this as a vendor deployment recipe, not a Daphnis hardware recommendation or a measured latency result. Obtain a current hardware quote, define uptime requirements and include the person who will maintain the runtime before comparing ownership with an API bill.
Weight access also has conditions. The Muse Model License requires attribution and imposes a separate-agreement condition on qualifying Model-as-a-Service businesses above an aggregate $20 million revenue threshold, with specified exceptions. Read the complete license and usage policy for your intended offering; downloadable weights do not imply unrestricted commercial terms. An inference engineering review can scope capacity measurements and operating responsibilities alongside that licensing review.
Calculate a pilot bill before a hardware break-even claim
At research time, Baseten's public model page lists $1.25 per million input tokens, $0.15 per million cached input tokens and $4.25 per million output tokens. Modal lists the same rates. These are provider offers checked today, not a universal price attached to Meta's weights. Groq's preview page does not supply a comparable public price.
Consider 100 coding tasks averaging 30,000 uncached input tokens and 5,000 billable output tokens across all calls per task. The totals are 3 million input and 0.5 million output tokens. At the rates above, input costs $3.75 and output costs $2.125, for $5.875, or approximately $5.88. This illustrative subtotal excludes sandbox compute, storage, taxes and human review; it is not the cost of a completed coding service.
If the provider reports cache hits for 2 million of those input tokens, the revised subtotal is $1.25 for uncached input, $0.30 for cached input and $2.125 for output: $3.675, approximately $3.68. Do not assume that repeating similar prompts earns a cache discount. Use recorded billable usage, and check how the provider counts reasoning tokens and tool-loop output before applying the estimate to an invoice.
Suppose only 80 tasks pass review. Without cache savings, the token cost per accepted task becomes $5.875 divided by 80, approximately $0.073. If each of the 100 attempts also takes an assumed two minutes of review at $30 per hour, review adds $100. The combined amount is then about $1.32 per accepted task, before the other exclusions. This sensitivity calculation shows why acceptance and correction effort belong beside token price.
For self-hosting, use the same denominator: accepted tasks. Add the period's infrastructure charge or hardware allocation, energy, runtime maintenance and review cost, then divide by accepted work. Include idle capacity. There is no defensible break-even volume until the team measures throughput, utilization and acceptance on the intended hardware; parameter counts alone cannot supply those inputs.
Run a controlled repair evaluation
Build twenty fixtures in a disposable repository: five width or wrapping defects, five keyboard or focus defects, five mismatches between a screenshot and the relevant component, and five cases where the correct response is to ask for a missing requirement. Include the mobile card example. Have a frontend reviewer write the expected behavior and disallowed shortcuts before any model attempt. Keep those answer sheets outside the agent's accessible files.
Compare your current coding setup with Muse Spark Open through one chosen provider. Keep the tool permissions, task prompt, source revision, execution budget and acceptance checks fixed. Record the requested model, provider, precision where disclosed, reasoning setting and returned usage. If the setups require different harnesses, label the result as a comparison of complete systems rather than attributing every difference to the model.
Run each fixture twice per setup in randomized order, resetting to its original revision between attempts. Twenty fixtures × two setups × two attempts gives eighty trials. Reserve another five fixtures for confirmation after adjustments. This is a manageable pilot, not a statistically representative benchmark; retain individual failures so a single average does not hide repeated mistakes on keyboard behavior.
For the card repair, inspect 390-pixel and desktop layouts, follow keyboard focus into and out of the action, activate the unchanged link, and check the page's reduced-motion setting. Reject patches that delete the action, disable a test, clip reachable content or alter unrelated routes. A screenshot alone cannot prove that keyboard activation works. Our accessible form recovery guide supplies related checks when a fixture continues into an enquiry form.
Score accepted patches, unauthorized file changes, regressions, requests for necessary clarification, reviewer minutes and total elapsed time. Count failed requests and retries in cost. Preserve the original patch even if a human later repairs it, and report the repair separately. An AI evaluation and guardrails engagement can turn the fixture manifest and reviewer rubric into a repeatable check for future endpoint or runtime changes.
Choose the next deployment from the failure evidence
Start with an isolated branch and tools that can read, edit and test the fixture but cannot publish it or access production credentials. Use the read, draft and send permission pattern to keep review and release separate. Repository comments, image captions and tool output are evidence to inspect; they do not grant the agent additional authority.
Set stop conditions with the owner of the work. For this pilot, any unauthorized publication attempt or destructive change outside the fixture stops expansion. A team might require at least eighteen of twenty fixture types to pass both repetitions before trying a larger queue, while reviewing every failure individually. That threshold is an illustrative local decision, not an industry standard or a predicted Muse result.
Bring the failed patches, accepted-task costs, endpoint restrictions and capacity measurements into the deployment decision. If errors come from missing requirements, improve the brief. If the model repeatedly edits the wrong component, inspect retrieval and tool context. If acceptable work is constrained by measured queue time or data-location requirements, evaluate dedicated hosting. Each finding suggests a specific next experiment before a hardware purchase or wider coding rollout.
