Muse Spark 1.1 Guide: Meta's First API Model, Two Versions On

Muse Spark 1.1 has an odd place in Meta's line-up. It was the model that opened the Meta Model API to outside developers, and within four weeks it had a successor, then a second one four weeks after that. All three still sit side by side in Meta's documentation, at the same list price.

So the useful question is not whether 1.1 is good. It is whether there is any reason to call it rather than 1.2 or 1.3, and the honest answer is: occasionally, and mostly for reasons that have nothing to do with capability.

What 1.1 changed from the April model

Meta Superintelligence Labs released the first Muse Spark on 8 April 2026. It powered the Meta AI app and was proprietary from day one; Meta has said the Muse family will include open models later, but Spark itself shipped closed.

Muse Spark 1.1 followed on 9 July 2026, and Meta used it to launch the Meta Model API in public preview, initially for US developers. Meta's announcement describes it as a significant upgrade with gains in tool and computer use, coding and multimodal understanding. It also claims the model was trained to orchestrate multi-agent systems, acting either as a main agent that delegates to parallel subagents or as a subagent itself.

The practical specification is shared across the Spark versions: a 1,048,576-token context window, text output, and multimodal input covering text, images, video and PDFs. Meta says the model manages that window actively, compacting context while keeping the steps that matter. OpenRouter lists it at $1.25 input and $4.25 output per million tokens at the time of writing, with cached input at $0.15, which matches what reporting on Meta's own rates says.

A tool-use model first, a coder second

The benchmark table Meta published with 1.1, as reproduced by DataCamp, has a clear shape. Against Gemini 3.1 Pro, Claude Opus 4.8 and GPT-5.5, it led on the tool-orchestration evaluations:

• MCP Atlas (scaled tool use) — 88.1, against 82.2 for Opus 4.8
• JobBench (professional tool use) — 54.7, up from 17.0 for the April model
• Humanity's Last Exam with tools — 62.1
• Finance Agent v2 — 57.2

It trailed on long-horizon coding. On DeepSWE 1.1 it scored 53.3 against 59.0 for Opus 4.8 and 67.0 for GPT-5.5, and on SWE-Bench Pro it scored 61.5 against 69.2 for Opus 4.8. On OSWorld-Verified, the computer-use benchmark, it scored 80.8, behind Opus 4.8 at 83.4.

Read that as a profile, not a ranking. A model that is strongest at choosing and sequencing tools across many servers, and weaker at grinding through a long repository change, suits orchestration roles: the coordinator in a multi-agent setup, or an assistant wired to a dozen MCP servers. That is a different job from an unattended coding agent, and it is precisely the gap Meta targeted with 1.2.

The same number, two different harnesses

One detail in Meta's own materials is worth knowing before you trust any Spark figure. The 1.1 launch table puts it at 80.0 on Terminal-Bench 2.1. A month later, Meta's 1.2 launch charts reported 1.1 at 76.2 on the same benchmark, measured through the Muse Code harness at xhigh effort.

Neither number is wrong. They are the same model on different scaffolding with different settings, and a four-point swing from harness alone is normal. It is also larger than many of the gaps that comparison tables present as decisive. Building a small eval from your own tasks is the only way to get a figure that applies to your harness rather than someone else's.

Why anyone would still call 1.1

Price is not a reason. 1.1, 1.2 and 1.3 all list at the same standard rate, so moving forward costs nothing per token. 1.3 is reported to use fewer tokens for the same work, which makes it cheaper per task.

The reasons that remain are operational:

• A pinned regression baseline. If you validated prompts, structured-output schemas or tool definitions against 1.1, keeping it as a reference lets you see what a migration actually changes.
• Behaviour you depend on. Later versions were tuned towards coding and towards asking clarifying questions. If your pipeline expects 1.1's behaviour in a non-coding orchestration role, measure before switching.
• No contributor variant. Meta's docs list 1.1 in standard mode only. There is no cheap data-sharing version of it, so you cannot accidentally route sensitive traffic to a tier that trains on it.

Note what 1.1 does not offer. Meta's documentation describes it as pay-as-you-go only and not available in Muse Code, Meta's terminal agent. If you want Meta's own coding harness, you are on 1.2 or 1.3 regardless.

Planning the move off it

Meta has not published a deprecation date for 1.1, but three versions in eight weeks is a pace that makes one likely eventually. Treat 1.1 the way you would any superseded snapshot: pin it explicitly, keep a test set that exercises the behaviour you rely on, and plan the migration before you are forced into it.

A reasonable sequence:

1. Run your existing tool-calling and structured-output cases against 1.1 and 1.3 with identical prompts.
2. Compare total tokens per completed task, not just pass rate. A newer model that finishes with fewer calls is cheaper at the same list price.
3. Check every place 1.3 now stops to ask a question. In an interactive product that is welcome; in a headless pipeline it can look like a hang.
4. Switch the default, keep 1.1 available behind a flag for a release cycle, then remove it.

If nothing in that comparison favours 1.1, there is no reason to keep it beyond a baseline. If something does, you have found a behaviour worth writing down before it disappears.