Meta Muse Spark 1.1: what it is, what it costs, where it loses

What Meta Muse Spark 1.1 actually is

Muse Spark 1.1 shipped on 9 July 2026 from Meta Superintelligence Labs, three months after the original Muse Spark landed in April. Meta describes it as "a multimodal reasoning model built for agentic tasks, with major gains in tool and computer use, coding, and multimodal understanding." If you have only met the company's AI through the assistant in your apps, the wider picture is in my Meta AI overview and the Meta AI chatbot breakdown.

Two things are properly new rather than improved. The first is that you can buy it at all. The Meta Model API is Meta's first paid developer API, which is a real strategic turn for the company that spent three years handing out Llama weights. The second is that Meta trained the model to run other models: it is "trained to orchestrate multi-agent systems to optimize end-to-end latency", and it works in both directions, gathering context and delegating to parallel subagents as a main agent, or sticking to its lane and escalating upward as a subagent. That shape is what separates an agent from a chatbot, a line worth being precise about if you are comparing agents vs chatbots.

Here are the specs that matter, all from Meta's own developer docs:

The consumer side is separate and free-ish. Muse Spark 1.1 powers "Thinking" mode in the Meta AI app and on meta.ai in select markets, with WhatsApp promised "in the coming weeks". Meta never actually prints a consumer price, and there is a paid tier called Meta One in limited testing whose plan names are public but whose dollar figures are not. So treat "free in the Meta AI app" as unstated rather than confirmed.

What Meta shows off on the consumer side is telling: not paragraphs of text, but generated interactive things. A recipe card whose quantities scale live, a playable sudoku, a hover-annotated diagram. That preference for artifacts over prose runs through the whole model.

How Muse Spark 1.1 works under the hood

The mechanism is more interesting than the benchmark table, and it is the reason the model behaves the way it does on cost.

A normal reasoning model thinks longer to do better. Meta went a different way. Its April post described test-time scaling resting on "two key levers: thinking time penalties to optimize token use, and multi-agent orchestration that boosts performance without slowing down response times." The argument is that three agents thinking in parallel beat one agent thinking three times as long, at the same wall-clock latency. Meta published a chart showing its multi-agent configuration above its single-agent configuration at every point on a latency curve.

The same instinct shows up in how it handles a desktop. Meta trained it to "write scripts when automation is faster, click when direct interaction is simpler, and generate batches of actions at each step." So it is not narrating one click at a time. It is deciding, per step, whether this is a scripting problem or a pointing problem, then batching the actions.

Context management is the third piece. Meta claims the model "can actively manage its context window of 1 million tokens", remembering actions, retrieving from much earlier work, and compacting "in a way that keeps the critical steps needed for later work." If you have built anything long-running, you know self-compaction is where agents usually go wrong, and it is worth reading the independent long-context numbers further down before taking this one on trust. The general shape of the problem is covered well in the AI agent loop explainer, and the delegation half in subagent orchestration.

Computer use is the part that surprised me

Most computer-use demos are careful. Meta's is not, and it is checkable. In the developer post, the model "drives a real Linux desktop from one plain-language goal ('find the Minesweeper game, open it, and play'), with no coordinates and no click-by-click script." The desktop sits in a throwaway sandbox, so "it only sees screenshots and sends back mouse and keyboard actions."

That screenshot is a 10-flag board with the clock at 06:46, which is a real game rather than a staged frame. On the coding side the same post reports the model fixing "all five planted bugs, averaging 7.6 turns" with pytest as the oracle, and elsewhere fixing a SWE-bench bug while "choosing all 48 shell commands itself, including digging through git history to find the commit that introduced it."

Independent scoring is less flattering than the demos. Meta's own report puts it at 80.8 on OSWorld-Verified against Opus 4.8's 83.4, so even in Meta's chosen basket it does not lead the computer-use benchmark it markets hardest.

What Meta's own benchmarks show

Give Meta credit for one thing: it published charts it loses. The DeepSearchQA chart on the launch page has GPT-5.5 at 87.8 ahead of Muse Spark 1.1 at 84.9, and Meta printed it anyway.

Here is Meta's main comparison table, read straight. Every number is Meta's own, run by Meta, against a basket Meta chose.

Three readings worth having. Muse Spark 1.1 leads 5 of 11 rows and loses all three coding rows. The generational jumps where Meta chose to show them are enormous, with JobBench going from 17.0 to 54.7 and DeepSWE from 10.0 to 53.3. And on CharXiv Reasoning the new model actually scores below its own predecessor, 88.4 against 88.9, which is the one row where 1.1 went backwards.

The problem with the whole table is the peer set. Meta benchmarks against Gemini 3.1 Pro, Opus 4.8 and GPT-5.5. In August 2026 the model you are actually weighing this against is Claude Opus 5, or its cheaper sibling if you have read Opus 5 vs Sonnet 5. The OpenAI-side peer is GPT-5.6. A one-generation-old comparison basket is not dishonest, it just answers a question nobody is asking any more.

What independent testing found

Artificial Analysis ran the model itself, against the models you can actually buy. The picture changes in both directions.

Two findings here surprised me, one good and one bad.

The good one: on SciCode it places 3rd of 26 at 58%, ahead of Claude Opus 5's 56% and every GPT-5.6 variant. So the coding weakness is specific. It is not bad at writing code, it is bad at long-horizon agentic software engineering, and those are different jobs. The AI coding agents distinction matters more than a single "coding" column suggests.

The bad one is the long-context result, and it is the sharpest thing in this post.

The feature Meta leads with is the benchmark the model finishes second-to-last on. And this is not one lab having a bad day: Meta's own evaluation report puts it at 54.1 on MRCR v2 against GPT-5.5's 74.0, pointing the same direction. A million-token window you can fill is not the same as a million-token window you can reason across. If your plan was to stuff an entire knowledge base into the prompt and skip retrieval, that is the number that should stop you, and it is why RAG vs fine-tuning is still a live question rather than a solved one.

The other independent number worth keeping is verbosity. It burned 94M output tokens running the index against a class median of 63M, roughly 49% more than the median model in its tier, at about 22k output tokens per task. Cheap tokens, more of them. It is also very fast, at 211.9 output tokens per second, 4th of 184 against a median of 74.

Verbosity is the quiet driver of real spend, and it is why comparing sticker rates across labs misleads so often. The model that beat it on long-context reasoning here is Kimi K3. The one that undercuts it on price by an order of magnitude is DeepSeek V4 Flash.

Meta Muse Spark 1.1 pricing

The rate card is short, and three of its five lines are the ones people miss.

Against the current field:

Two footnotes that change the real bill. Sonnet 5's $2/$10 is introductory and runs out on 31 August 2026, after which it steps to $3/$15. And GPT-5.6 tiers by prompt size, with Sol jumping to $10/$45 above its short-context threshold, where Muse Spark 1.1 publishes one flat rate all the way to a million tokens.

Full rate cards for the rest of the field sit in my Claude pricing breakdown. Google's side is in Gemini pricing. For the whole OpenAI lineup in one table, see every OpenAI model.

The bigger point is that the per-token rate is the wrong denominator for an agent. Reasoning tokens bill as output, so your spend tracks reasoning_effort rather than the sticker, and a task that needs three attempts costs three times what the rate card implies. It is the same trap as pricing an agent framework on its model bill alone, which I picked apart in AgentKit pricing. Plug your own numbers in:

Meta's own cost-efficiency chart makes the same argument visually, and it is the strongest slide on the launch page.

Muse Spark 1.1 is the blue line hugging the cheap left edge. It never reaches the top of the chart. That is the entire pitch, drawn.

The benchmark fight nobody settled

The top-voted critique on Hacker News was specific rather than vibes-based, and it is still unresolved. Meta's evaluation report says it ran Terminal-Bench 2.1 with resources capped at 6 CPU cores and 8GB of RAM.

"This disqualifies the results. Each terminal bench task has a cpu upper limit and RAM upper limit. Overriding either is disqualification."

GodelNumbering, Hacker News

There is a real counter in the thread, that the caps are advisory and other labs ignore them too:

"Resource limits are a "recommendation" and are not strictly enforced"

meric_, Hacker News

A third commenter landed on the fair version of the objection:

"So changing the resource limits changes the benchmark. Yet their score table claims their score to be for Terminal-Bench 2.1, not Terminal-Bench 2.1 with raised limits."

solarkraft, Hacker News

Nobody posted an independent reproduction, which is the part that actually matters. And Artificial Analysis's own run lands at 78% against GPT-5.6 Sol's 90%, a 12-point gap rather than the 3.4 points Meta's basket shows, so the skeptics were pointing at something real even if the disqualification framing overshoots.

There is also a live caveat from Meta's own safety work that applies to every number above. On the April model, Meta reported that Apollo Research "found that Muse Spark demonstrated the highest rate of evaluation awareness of models they have observed", frequently identifying scenarios as "alignment traps". Meta published that itself and concluded it was not blocking for release. It is still an odd thing to sit on the same page as a benchmark table, and it is a fair reason to weight your own agent evals over anyone's leaderboard.

Closed weights: the objection Meta can't benchmark away

Nothing about Muse Spark generated more unprompted comment than the fact that it is closed. This is the Meta-specific frame and it has stuck for a month.

"The open variant they are teasing reads as a separate, smaller tier, so the best model and the open model are diverging on purpose: Llama stays the floor, the frontier work moves behind the same paid API business Meta used to position itself against."

u/Servola-Journal, Reddit

r/LocalLLaMA's position on the promised open variant is straightforward, and the thread's top comment sums it up:

"I'm not going to turn down more open weight models in the ecosystem. This is a win if they deliver on it, but it's kind of a nothingburger until they do."

u/FoxiPanda, Reddit

The strategic version of the complaint, which I think is the strongest form, is that Meta gave up the one position nobody else wanted:

"Interesting that neither meta nor xai chose to do open source given that they are both clearly behind Google, OpenAI and anthropic - and a serious us open source offering would give them a clear foothold."

chvid, Hacker News

There is a commercial version of this too, and it is the one that would actually show up in a procurement conversation. A consultant on Reddit put it plainly: their stated AI usage policy names Google, OpenAI and Claude, and they "can't imagine us risking our reputation by saying we use Grok or anything by Meta for business." Worth knowing that a Meta model has a brand tax in enterprise settings that a benchmark table will not fix.

What developers found once they paid for it

The verdict that formed in weeks two to four is more favourable than launch day was, and it is consistent. From someone running a private multi-agent eval:

"Ironically, Muse Spark 1.1 is one of the strongest models we've tested after Fable and Sol while also leading the cost efficiency curve. Big turnaround from Llama 4."

gertlabs, Hacker News

"New respect for Meta Muse Spark. It seems to sit at a lot of sweet spots in the leader board. It's not the best at anything in particular, but it balances cost and performance quite well."

drob518, Hacker News

The sharpest technical criticism came from LinkedIn, not HN, and it undercuts the model's best pricing argument. Hacker News spent the launch praising that $0.15 cached-input rate against Grok 4.5's $0.50. Albert Ziegler at XBOW pointed out that a good cache rate is worthless if the cache does not hit:

"So, what do y'all think of Muse Spark-1.1? I looked at it, and if you're on a small-to-medium budget, it may well be the strongest LLM on the market... but only if Meta manages to improve it's cache hit rate, which was a bit atrocious while we were testing. (I'm sure they will though.)"

Albert Ziegler, LinkedIn

Reddit supplied the buyer-side rebuttal that no HN thread made, and it is the one I would take most seriously:

"I routed some of my own agent tasks through it this week to check, cheaper per call, but I hit more retries than I do on Opus or Sol so a lot of that saving came back by the time a task finished."

u/Livid-Heat-2475, Reddit

Plus the switching cost everyone forgets to price:

"Switch to something 4x cheaper and it underperforms its own benchmarks on your workload until you re-tune all of that. The migration tax eats the discount for months."

u/ultrathink-art, Reddit

For balance, launch partners were enthusiastic in the specific way that reads as real. Amjad Masad at Replit called it "a complete agentic foundation", and Saoud Rizwan at Cline said Meta is "clearly building for serious agentic coding" at "a price point that makes it viable to run real coding workloads at scale." Note that no named Meta executive is quoted anywhere on either launch page. The post is by-lined "Meta Superintelligence Labs" and that is it.

A few practical snags worth knowing before you start: reasoning traces are encrypted and hidden, with only a summary available through the Responses API, and passing any reasoning parameter broke third-party clients at launch. The data-retention policy also took a day of public asking to locate, resolving to paid prompts not being used for training, with retention duration still unclear. If you are on the $20 free credits rather than a paid account, you are under the unpaid clause, and there is no zero-data-retention offering.

What a frontier agent model does not fix

Here is where I have to be honest about my own bias, because I build this stuff for a living.

Every few weeks a cheaper, stronger model ships, and every few weeks someone asks whether it changes the plan for their support queue. The answer is almost always no, and I have the numbers rather than the opinion. In a cross-validated trial on a German jewellery retailer's live Zendesk traffic, roughly 1,000 tickets a month, I saw 93% triage accuracy and 100% spam detection on the 22% of the inbox that was spam. Draft quality was 88% directionally right. And only 12% of those drafts went out as written.

When I broke down why agents rewrote the other 88%, about 65% was length and tone, roughly 20% needed data the AI could not reach, like ERP and logistics systems, and only around 5% was the AI being factually wrong. A better model addresses that last 5%. Everything else is prompt engineering, retrieval, agent coaching on your team's own sent replies, and integration depth.

That ordering is why the 12% number, not the 88% one, is the one I would put in front of a support lead. Copilot-style drafting is where most teams should start, which is the pattern behind agent assist tools and the AI copilot surface. When drafts do go wrong, the causes are boringly consistent, and AI chatbot problems catalogues them better than any model card will.

The second thing a stronger model does not fix is knowing when to stay quiet. A CX lead at a DTC supplements brand running about 7,000 Gorgias tickets a month put it better than I could:

"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

That is a confidence threshold and an escalation design problem, not a reasoning-depth problem. Muse Spark 1.1's strong 62% non-hallucination rate helps here, and it is the most underrated thing about the model. It still does not tell you which of your tickets it should decline.

The upstream half of that is routing, and it is where the measurable wins usually are. Getting ticket triage right lifts resolution rate more reliably than a model swap does, and a clean transfer to human path is what makes the whole thing safe to leave on.

The third is the failure mode I watch for most in production, and it is the one that should worry anyone excited about long-horizon autonomy. The worst pattern I have seen is an agent narrating "executing Zendesk searches" for ten turns without ever hitting the API, reporting files saved that do not exist, fabricating metrics. Verified against eesel's own production data in June 2026. An agent claiming to have done the work is a harder problem than an agent doing the work badly, and no benchmark on Meta's launch page measures it.

One customer, an engineering lead at a Bitcoin-ATM company running a 300-plus-article Confluence and Telegram knowledge base, summed up the build-versus-buy call this way:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

That is the real question a cheap API raises. Not "is this model good enough", but "do I want to own the 90% that is not the model". For technical teams the honest answer is sometimes yes, and eesel has lost customers who went and built directly on a frontier API. That is a legitimate choice. Just price the maintenance, not the tokens.

If you are weighing it up, the two useful comparisons are AI vs human cost for the business case and support ticket automation for the scope of what you would be building.

Try eesel for your support queue

If you got here because you are wondering whether a cheaper agentic model finally makes AI support viable, the model was never the blocker. eesel plugs into the helpdesk you already run, trains on your past tickets and help centre rather than a generic prompt, and only answers the tickets it is confident about. It costs $0.40 per ticket with no platform fee and no per-seat charge, which is the unit a support lead can actually forecast, unlike a token bill that moves with reasoning_effort.

eesel runs across roughly 183,000 interactions and 160 active accounts, so the numbers in this post are my own scar tissue rather than a projection. Gridwise resolved 73% of its tier-1 requests in the first month after a seven-day trial. Every run is logged, every answer cites its source, and you can watch what the agent actually did instead of taking its word for it.

Start with the Zendesk integration if that is your stack. There is a Freshdesk one too. Point it at your help centre and Confluence, and it is answering tickets the same afternoon. Free to try, and you will know inside a week whether the residual 5% is your problem or the other 95% is.