# Muse Spark 1.3 Uses 25% Fewer Tokens. Its Max Mode Still Has to Wait. **Summary:** Meta says Muse Spark 1.3 uses roughly 25% fewer tokens and 20% fewer tool calls than 1.2. Its benchmarked max mode is still in safety testing, so I would test the modes that shipped before treating the scorecard as a production result. - Canonical: https://markhuang.ai/news/muse-spark-1-3-max-mode-has-to-wait - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-02 - Section: News - Tags: Muse Spark 1.3, AI Coding Agents, Developer Tools, AI Evaluation, AI Safety - Source: [Meta AI Research](https://research.meta.ai/blog/introducing-muse-spark-1-3) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A compact blue AI core routes work through streamlined tool paths while a brighter path waits behind an amber safety gate](https://cdn.markhuang.ai/news/muse-spark-1-3-max-mode-has-to-wait/hero.webp) *Spark 1.3 sends the everyday work down a shorter path. Its highest-reasoning route is still behind the gate.* [Meta has released Muse Spark 1.3](https://research.meta.ai/blog/introducing-muse-spark-1-3) in Muse Code and the Meta Model API. The claim that caught my attention is not the leaderboard: Meta says its engineers saw roughly 20% fewer tool calls and 25% fewer tokens than with Spark 1.2. Every unnecessary turn in an agent loop adds latency, cost, and another chance to wander. The release has an awkward split. The existing reasoning modes are available now, while the new max mode will arrive only after additional safety testing. Yet max is the configuration in Meta's benchmark scorecard. Spark 1.3 has earned a place in my test queue, but its headline scores have not earned production traffic. ## The useful number is not the biggest score A coding agent rarely fails because its benchmark number is one point too low. It fails because it rediscovered the same file, called the wrong tool, forgot a constraint, or declared victory before checking the result. Meta says it trained Spark 1.3 on more long-horizon coding tasks and across different agent harnesses. The model is also supposed to be less verbose and better at keeping detailed instructions. The 20% and 25% reductions interest me more than a broad intelligence ranking. They point at the cost of getting work done. Still, Meta describes comparisons made by its own engineers, without giving a task count, variance, cache assumptions, or a harness-by-harness breakdown. I would treat the figures as a testable claim, not a budget forecast. > **Info:** > > I would measure completed work per review minute. Fewer tokens help only when the agent also preserves the brief, uses the intended tools, and leaves a result I can verify. ## Meta benchmarked the mode developers cannot use yet Meta's scorecard reports Spark 1.3 max at 75.4 on DeepSWE v1.1, up from 55.0 for Spark 1.2 xhigh. On Terminal-Bench 2.1, it reports 88.8, tied with GPT-5.6 Sol max and above Spark 1.2's 82.9. Those are strong coding signals, but they belong to the max configuration that is still waiting on safety work. The wider table is more measured. Spark 1.3 max scores 64.9 on JobBench against 65.7 for Opus 5 max, and 1,754 on GDPval-AA v2 against Opus 5's 1,824. It leads the compared models on the two long-context MRCR tests and on DeepSWE, but not on every agent benchmark. The table makes the model interesting without telling me how it will behave in my repository. I made the same distinction when looking at the [Artificial Analysis Agentic Index](https://markhuang.ai/news/agentic-index-needs-your-failure-test): a leaderboard can fund a shortlist, but only a local failure test can choose a production model. Here I would go one step further and keep the current reasoning modes separate from max in my results. Combining them would turn a staged rollout into a performance claim the available product has not yet proved. ## The complaints about 1.2 map neatly to the release notes Public discussion of Spark 1.2 is mixed. In one [OpenCode discussion](https://www.reddit.com/r/opencodeCLI/comments/1vvmnjj/muse_spark_is_infuriating/), developers complained about unnecessary Python scripts, shortcut-taking, and poor behavior unless prompts were unusually tight. Others in the same thread said a different harness or custom system prompt worked well. A separate [first-impressions post](https://www.reddit.com/r/opencodeCLI/comments/1vsjcyo/muse_spark_12_my_initial_impressions_compared_to/) called 1.2 a pleasant workhorse but flagged its cache-hit rate. Anecdotes do not settle model quality, especially when harnesses and traffic load differ. They do tell me what to test. Spark 1.3 specifically promises fewer needless turns, better instruction retention, cleaner coding style, more accurate routing when a user interrupts a long thread, and a better sense of when to ask for help. That reads like a response to real workflow friction rather than another claim about solving harder puzzles. If those changes hold, the developer supervising a long job gets fewer interruptions. But "trained across diverse harnesses" does not guarantee the same behavior with my tool definitions or permission prompts. Meta's earlier [Spark 1.1 release](https://research.meta.ai/blog/introducing-muse-spark-meta-model-api) already advertised planning, delegation, context compaction, and a one-million-token context window. Version 1.3 has to show that those capabilities cooperate more reliably. ## The safety delay is part of the product I am glad Meta did not blur the max delay into a footnote. A stronger agent that takes consequential actions needs more than a refusal score. Meta says 1.3 is better calibrated around irreversible actions and more resistant to prompt injection, but the announcement does not publish quantitative support for those two claims. That omission matters because Meta disclosed in August that a pre-release Spark 1.1 model [exploited a real website during a misconfigured cyber evaluation](https://research.meta.ai/blog/addressing-third-party-testing-misconfiguration-muse-spark-1-1). Meta says the model believed the site was its assigned target and changed its database. The company reviewed more than 10,000 activity records and found no other instance. An agent's judgment cannot repair a broken boundary. That is also why I would not read "max is coming" as a release date. Additional safety testing can find a model problem, a harness problem, or both. I have argued before that a [cyber evaluation is production infrastructure](https://markhuang.ai/news/claude-cyber-eval-test-harness-risk) once a capable agent can touch the internet. Waiting is the correct state until the model and its environment clear that bar. ## I would run the cheaper experiment first For the available Spark 1.3 modes, I would use a small set of real repository tasks with fixed permissions and repeated runs. I would record completion, tool calls, tokens, elapsed time, human interventions, constraint violations, and attempts at irreversible action. Comparing those traces with Spark 1.2 in the same harness would test Meta's efficiency claim directly. I would keep max out of the comparison until developers can actually call it. Once it arrives, it gets its own lane and the same tests. A stronger score may justify extra reasoning on difficult migrations or long debugging sessions. It may also spend more time proving what the regular mode already knows. Spark 1.3 looks most promising where Meta has made the least glamorous claim: fewer calls and fewer tokens inside messy work. That could make an agent cheaper to supervise. The max benchmark is a useful preview, but my decision today is simple. Test the model that shipped, and wait for evidence on the mode that did not.