Muse Spark 1.3: Benchmarks, Pricing, Coding Gains and What Changed

Meta released Muse Spark 1.3 on September 2, 2026, pushing its fast-moving Spark model line further into the territory that matters most for AI agents: long-running tasks, software engineering, tool use, computer control and work that spans very large contexts. The model is available through Muse Code and the Meta Model API, with Meta saying its highest “max” reasoning mode will arrive after additional safety testing.

The headline benchmark numbers are strong. Muse Spark 1.3 posts large gains over Muse Spark 1.2 on coding, computer use and million-token retrieval, and in several coding evaluations it meets or beats results published for GPT-5.6 Sol and Claude Opus 5. But the more useful story is not that Meta suddenly “won” every benchmark. It did not. The release is more interesting because it narrows the gap across a broad set of agent tasks while keeping API pricing at the same level as the previous generation.

There is also an important launch-day caveat: Meta’s own materials use different reasoning configurations across evaluations, while the public launch post says max reasoning is not yet generally available. That makes the numbers worth studying, but not treating as a universal prediction of what every developer will get from the default API configuration.

Key takeaways

• Muse Spark 1.3 is available now in Muse Code and the Meta Model API; max reasoning is still pending additional safety testing.
• Coding is the clearest strength. Meta reports 75.4 on DeepSWE v1.1, 59.4 on SWE-Atlas Codebase QnA and 88.8 on Terminal-Bench 2.1.
• Long-context retrieval improved sharply. The published MRCR v2 scores reach 98.5 for 256K–512K contexts and 98.1 for 512K–1M.
• Pricing is unchanged at $1.25 per million input tokens, $4.25 per million output tokens and $0.15 per million cached input tokens for the xhigh configuration tracked by Artificial Analysis.
• The benchmark picture is mixed outside coding. Opus 5 and GPT-5.6 Sol still lead several agentic and research evaluations in Meta’s own comparison.

What changed in Muse Spark 1.3?

Muse Spark 1.2, released in August, was positioned primarily as a coding-focused update and the model behind the Muse Code beta. Version 1.3 broadens that idea. Meta describes the new model as being trained for longer-horizon work in which the model must keep track of objectives, use tools, recover from incomplete plans and continue operating without losing earlier constraints.

That distinction matters because many failures in current AI agents are not failures of raw knowledge. They are failures of continuity. A model can write a good function in one turn and still lose track of a repository-wide migration after twenty steps. It can correctly use one tool while misrouting a later request to the wrong task. It can produce a plausible “done” message even when an external action never succeeded.

Meta says Spark 1.3 was specifically trained to improve those behaviors. The model is supposed to build its own working context from messy or conflicting sources, identify holes in its plan, preserve requirements across long tasks and better recognize when it does not know something. It is also trained to ask a clarifying question when ambiguity is material, request help when blocked and confirm before consequential actions.

Those are less glamorous improvements than a single benchmark record, but they are exactly the behaviors that determine whether an agent is useful outside a demo.

Agentic workflows are the center of this release

The most important part of Meta’s announcement is its emphasis on sustained work. Spark 1.3 is designed to handle multiple workflows inside one long conversation and to map new instructions back to the correct task even when a user interrupts, changes direction or returns to an earlier request.

That sounds simple until a thread includes a code review, a data-analysis task, a research question and a document deliverable at the same time. Long conversations create a routing problem as much as a memory problem: the model has to know not only what was said, but which previous objective a new instruction belongs to.

Meta also emphasizes better self-calibration. Instead of treating every tool call or intermediate assumption as successful, the model is trained to recognize capability limits and obstacles. If that improvement survives real-world use, it could reduce one of the more frustrating agent failure modes: confident completion claims after a partial or failed workflow.

The company’s evaluation methodology reflects that wider scope. GDPVal-AA v2 covers 220 professional tasks across 44 occupations and nine major U.S. industries, with deliverables including documents, spreadsheets, slides, diagrams and reports. JobBench uses 65 professional tasks spanning 35 white-collar occupations. OSWorld 2.0 evaluates 108 end-to-end workflows on a full Ubuntu desktop, while AutomationBench uses 600 simulated business workflows with deterministic checks of the final application state.

In other words, Meta is not presenting Spark 1.3 solely as a better chatbot. The target is an AI worker that can operate software, manipulate files, use tools and keep a multi-step job coherent.

Coding: fewer turns, fewer tool calls and stronger benchmark results

Coding remains the most convincing part of the upgrade. Meta says Spark 1.3 was trained on more long-horizon coding tasks and is less verbose than Spark 1.2 in common engineering workflows. In comparisons conducted by Meta engineers, the new model used roughly 20% fewer tool calls and 25% fewer tokens.

Those percentages should be read as Meta’s internal comparison, not as a guaranteed discount on every workload. Still, efficiency is an important metric for coding agents. A model that reaches the same result with fewer shell commands, file reads and intermediate turns can reduce latency, API spend and the number of opportunities for an agent to drift off course.

Meta’s public scorecard also shows substantial gains on coding evaluations:

DeepSWE v1.1 is particularly relevant because it is not a toy code-generation test. Meta’s methodology describes 113 software-engineering tasks across 91 repositories in TypeScript, Go, Python, JavaScript and Rust, graded with functional and regression tests. SWE-Atlas Codebase QnA tests deep comprehension across 11 production repositories, while Terminal-Bench 2.1 uses 89 tasks performed in terminal environments and grades the resulting container state.

The pattern is clear: Spark 1.3 does not merely improve autocomplete-style coding. Its largest gains are in the sort of codebase understanding and multi-step execution that coding agents need.

Muse Spark 1.3 benchmarks: strong, but not a sweep

Outside coding, the launch results are more balanced. Spark 1.3 improves over Spark 1.2 across every agent-oriented row in Meta’s published comparison, but it does not lead all of them.

That is a more useful result than a simplistic “beats GPT” headline. On GDPVal-AA v2, Spark 1.3 moves ahead of GPT-5.6 Sol but remains behind Opus 5. On OSWorld 2.0 it makes a dramatic jump from 47.6 to 66.9, yet Opus 5 is still slightly higher at 68.3. GPT-5.6 Sol leads the published DeepSearchQA and Agentic IF Index results.

The conclusion is not that one model is universally best. It is that Meta has moved Spark much closer to the frontier across several categories while developing a particularly strong profile in coding and long-context work.

The million-token result deserves attention

One of the largest generation-to-generation improvements appears in MRCR v2, a long-context retrieval evaluation. Meta reports:

MRCR is not an agent benchmark. It tests whether a model can retrieve a target turn from a very long context containing multiple “needles.” Meta’s methodology uses 100 examples in each context band with eight needles distributed through the input.

That distinction matters: a near-perfect retrieval score does not mean a model can reason perfectly over an entire million-token repository. But the jump from 55.5 to 98.1 in the 512K–1M band is still significant. Long-running agents constantly accumulate logs, files, previous decisions, tool outputs and user instructions. Being able to retrieve the right piece of information late in a huge context is a prerequisite for doing something intelligent with it.

What the benchmark numbers actually mean — and the launch-day caveat

There is a reason to avoid treating the launch scorecard as a single definitive ranking. Meta’s own methodology notes that third-party model runs use common settings where practical but are “best effort”; prompts, tools and runtime may not be optimized for a rival provider’s proprietary model. That means a comparison can be fair enough to be informative without reproducing the absolute best performance each vendor could obtain in its own stack.

There is also a configuration wrinkle. Meta’s public launch post says existing reasoning modes are available immediately and max reasoning is coming later after additional safety testing. The evaluation document, meanwhile, describes different configurations across benchmark sections: its overall methodology references xhigh for Spark 1.3 in the rendered document, while the DeepSWE section explicitly references a Spark 1.3 max run. Independent evaluators such as Artificial Analysis also report separate xhigh and max results.

For buyers, the practical rule is simple: benchmark the reasoning mode you can actually deploy, in the harness you actually use. A launch score is evidence of capability, not a service-level guarantee.

Pricing, context window and availability

Muse Spark 1.3 is available through Muse Code and the Meta Model API. Artificial Analysis reports that pricing for the xhigh model is unchanged from Spark 1.2:

Artificial Analysis scores Spark 1.3 xhigh at 61 on its Intelligence Index and calculates a cost of about $0.55 per Intelligence Index task. Its max configuration scores 62, but public max pricing was not established in the same way at launch.

That one-point gap is another reason not to obsess over the label. On an actual agent workload, the right question is whether additional reasoning improves task completion enough to justify extra latency or token use. Artificial Analysis found that the max variant can use materially more reasoning on some agentic evaluations, so a higher reasoning setting is not “free” even when the underlying per-token rates are attractive.

Real-world agent work goes beyond coding

Meta’s demos deliberately include work that looks more like an office or engineering assignment than a programming benchmark. One example asks the model to inspect CFD simulation results and a STEP CAD file, summarize boundary conditions and performance metrics, reason about aerodynamic implications, make preliminary design recommendations and export a structured PDF report.

The point is not whether one generated engineering report is production-ready. It is that the model is being trained and evaluated around workflows where the output is an artifact: a PDF, spreadsheet, presentation, code change or completed application state. That is a better match for how businesses measure work than a benchmark that stops at a text answer.

This also explains why GDPVal-AA, JobBench and AutomationBench are worth watching. They test whether an agent can turn instructions and source material into something usable, not merely whether it can state the correct fact.

Safety changes matter more as agents gain autonomy

Meta says Spark 1.3 has stronger resistance to adversarial inputs and prompt injection, along with better judgment about irreversible actions. Those changes are especially relevant to tool-using agents because the risk profile changes when a model can modify files, operate a browser, call an API or trigger a real transaction.

A conventional chatbot can hallucinate and give a bad answer. An agent can hallucinate and then act on it.

That is why the company’s decision to hold max reasoning for additional safety testing is notable. More reasoning capability does not automatically equal more dangerous behavior, but a model designed for long-horizon tool use needs reliable boundaries around consequential actions. Asking for confirmation at the right moment is not merely a user-experience feature; it is part of the control system.

Where Muse Spark 1.3 still needs scrutiny

Independent testing adds useful friction to the launch narrative. Artificial Analysis gives Spark 1.3 xhigh an Intelligence Index score of 61, placing it among the leading models it tracks, and a max score of 62. But its breakdown is not uniformly better than Spark 1.2.

The evaluator reports a four-point decline on AA-LCR, from 83% to 79%. Its Omniscience accuracy also fell slightly, largely because Spark 1.3 abstained more often when uncertain. That is not necessarily a negative behavior: the xhigh model’s higher abstention rate also reduced its hallucination rate. A model that says “I don’t know” more often can score worse on raw accuracy while becoming safer or more trustworthy in ambiguous situations.

There is another practical unknown: performance inside a specific agent harness. Meta co-trained earlier Spark models with Muse Code, and the company continues to optimize the model for its own agent environment. Developers using a different orchestration layer, tool schema, memory system or coding agent should run their own evaluations rather than assume the Muse Code results transfer directly.

Who should try Muse Spark 1.3?

Spark 1.3 is most compelling for teams whose bottleneck is not one-shot text generation but sustained execution.

• Software teams working in large repositories: the DeepSWE, SWE-Atlas and Terminal-Bench results point toward stronger repository-scale coding and terminal work.
• Agent builders: improved tool use, task routing, self-correction and long-context retrieval directly target common orchestration failures.
• Document-heavy professional workflows: GDPVal-AA and JobBench suggest Meta is investing in artifact creation across documents, spreadsheets, presentations and reports.
• Cost-sensitive API workloads: unchanged token pricing paired with higher capability makes 1.3 an obvious model to benchmark against an existing Spark 1.2 deployment.
• Long-context applications: anyone feeding an agent extensive code, research, logs or conversation history should pay attention to the MRCR gains, while still testing reasoning quality on their own data.

Teams that primarily need the very best web-research score, or whose evaluation already favors another frontier model, should not switch because of a launch headline. Meta’s own scorecard shows GPT-5.6 Sol ahead on DeepSearchQA and its Agentic IF Index, while Opus 5 remains ahead on several professional and computer-use evaluations.

What comes next for Meta’s Muse models

Meta is moving unusually quickly through the Spark line. Muse Spark 1.1 arrived in July, Spark 1.2 and Muse Code followed in August, and Spark 1.3 landed less than a month later. The company says its roadmap includes bigger models and an eventual Muse Spark open-weights release.

That makes Spark 1.3 feel less like a final destination than a proof point for Meta’s current strategy: iterate quickly on a relatively cost-efficient agentic model, co-design it with an agent product, and improve the parts of model behavior that show up only after a task runs for many steps.

The benchmark table will get most of the attention, but the lasting question is simpler. Can Spark 1.3 stay coherent long enough to finish real work without constant human rescue? The release gives Meta a much stronger case than Spark 1.2 did. Developers now have to test whether that improvement holds inside their own repositories, tools and workflows.

Sources

• Meta AI Research — Introducing Muse Spark 1.3
• Meta AI Research — Muse Spark 1.3 Evaluation Methodology
• Artificial Analysis — Muse Spark 1.3: Meta reaches the frontier
• Meta AI Research — Introducing Muse Code and Muse Spark 1.2