Muse Spark 1.3 Guide: Fewer Tool Calls at the Same Price

The most useful claim in the Muse Spark 1.3 release is not a benchmark score. It is that, in comparisons run by Meta's engineers, the model completed the same coding work with roughly 20% fewer tool calls and 25% fewer tokens than Muse Spark 1.2. The list price did not move. If the claim holds on your workload, that is a price cut delivered as a model update.

Meta released 1.3 on 2 September 2026, four weeks after 1.2, in both Muse Code and the Meta Model API. Here is what changed, what the published numbers do and do not tell you, and how to check the efficiency claim on your own tasks.

What changed in four weeks

Meta's own framing is improved agentic and coding performance with a focus on real-world usability. The specifics it lists are behavioural rather than architectural:

• Longer threads. It sustains longer-horizon work across several workflows in a single thread, including when the user interrupts or redirects.
• Collaboration. It asks clarifying questions when a prompt is vague, pulls the user in when it is stuck, and confirms before consequential actions.
• Calibration. Reporting on the release says it treats destructive operations more cautiously than reversible ones, and recognises when it has hit a limit rather than inventing an outcome.
• Less noise. Fewer unnecessary turns, less verbose output, cleaner code.

The rest of the specification is shared with earlier Spark versions: a 1,048,576-token context window, text output, and input covering text, images, video and PDFs. Meta does not publish a parameter count or architecture, and the weights are closed.

Fewer tokens at the same price is a price cut

Standard 1.3 lists at $1.25 per million input tokens, $0.15 cached and $4.25 output on OpenRouter at the time of writing, the same as 1.2 and 1.1. So the per-token rate tells you nothing about which version is cheaper. Cost per completed task does.

If a task that consumed 400,000 tokens on 1.2 now consumes 300,000, the bill for that task falls by about a quarter, whatever the mix of input and output. Fewer tool calls compound the effect in agent loops, because every tool call usually means another round trip that re-sends a growing context. The token cost of reasoning models covers why output and repeated context dominate the bill.

The caveat is that this is an internal comparison on Meta's own coding work. Your harness, your prompts and your effort setting will move the figure, possibly a lot.

Read the effort level before the score

Spark exposes reasoning effort as a request parameter. Third-party reads of Meta's documentation list minimal, low, medium, high and xhigh, with medium as the default, and Meta's model page says 1.3 supports all levels including max for extended reasoning. At launch Meta said max would follow after further safety testing.

That matters because the headline comparison Meta published, as summarised by DataCamp, is 1.3 at max effort against GPT-5.6 Sol and Claude Opus 5, also at max:

• DeepSWE v1.1 — 75.4, against 73.0 and 74.0
• Terminal-Bench 2.1 — 88.8, level with GPT-5.6 Sol and ahead of Opus 5 at 86.7
• GDPval-AA v2 — 1,754, behind Opus 5 at 1,824
• OSWorld 2.0 — 66.9, behind Opus 5 at 68.3
• DeepSearchQA — 89.4, behind GPT-5.6 Sol at 93.0

The pattern is a coding lead and a general-agent deficit. Opus 5 still wins most of the broader agent evaluations in Meta's own table; 1.3 leads on repository coding and terminal work. None of these were run at the default medium effort that an untuned client will use, so expect lower numbers and lower token counts if you leave the parameter alone.

Long context that holds up, on paper

The most striking figures in the release are long-context retrieval. On MRCR, Meta reports 98.5 in the 256K to 512K band and 98.1 in the 512K to 1M band, against 91.5 and 73.8 for GPT-5.6 Sol. Opus 5 has no published figure on that test.

If those hold, 1.3 is one of the few models whose 1M window is usable near the far end rather than nominal. MRCR is a retrieval test, though, and finding a planted item is easier than reasoning across everything in the window. Context length vs effective context explains the difference, and why your own long-document test is worth more than a vendor's.

Where 1.3 asks instead of acts

The new collaborative behaviour is a feature in an interactive tool and a hazard in a headless one. A pipeline that sends a task and waits for a diff will not answer a clarifying question. Depending on how your loop handles a text reply with no tool call, that question may look like a completed run, a hang, or a failure.

Two mitigations work. Make prompts in unattended runs explicit about assumptions the model may make, and treat a question with no tool call as a distinct outcome your loop logs and routes, not as success.

One more exception: Meta's docs flag 1.3's audio understanding as not fully supported and recommend 1.2 for audio input. If you process recordings, keep a route to 1.2. For cheaper experimentation, Muse Spark 1.3 Contributor is the same model on data-sharing terms, without max effort on the API.

Measuring the efficiency claim yourself

1. Take fifteen completed tasks from your repository history and freeze their starting commits.
2. Run each on 1.2 and 1.3 in the same harness, at the same effort level. Start with high, since that is a setting you might actually ship.
3. Record tool calls, input tokens, output tokens and whether you would merge the result.
4. Compute cost per merged task for each version, and count how often 1.3 stopped to ask a question.

If 1.3 lands near Meta's quarter saving with equal or better merge rates, move your default. If the saving is small but quality is up, move anyway; you are paying the same. If it asks too often for your pipeline, tighten the prompts before you write it off.