Meta Muse review: the fastest AI agent I have used, when it is working

Worth starting with the company's own claims rather than anyone's summary of them. From Meta's announcement, Muse “takes action, powered by Muse Spark,” which Meta describes as “Meta's most capable model to date, built for real-world agentic work.” It can “open a browser, fill out forms, and negotiate on their behalf,” and “develop a personalized plan and coordinate their time and resources.” It “keeps working after people close the app,” and it “remembers what matters to a person, so it can make suggestions unprompted.” It runs on “Muse Secure VM, a dedicated, virtual machine (VM) that houses both the agent and a person's data.”

Note what is absent: no uptime figures, no speed benchmarks, no reliability percentages, no competitor comparisons. The announcement is built around security architecture rather than performance promises. That is an unusually restrained way to launch a consumer product, and it turned out to matter in both directions.

Muse does real work, fast. I gave it genuine tasks. Sign into an account. Edit a profile. Set up a recurring posting schedule. It handled the mechanics with very little hand-holding and it was quicker at them than any agent I have used this year.

The multitasking is the standout. It runs parallel work across several browser sessions and holds the thread on each one, without the familiar failure where an agent loses track of task two because task one is still open. And it runs further on its own before it needs you. More autonomy per instruction is the entire point of this category, and Muse delivers more of it than its competitors.

It also surfaced a permission check that most tools with far less access skip. Told to post to my Instagram every Tuesday and Thursday, it halted and asked whether that was standing authorization going forward or whether each post needed approval. That is the correct behavior for software holding keys to your accounts.

It stops. Frequently. Not failures, mostly. Stops. A task begins, gets most of the way, and halts. No error, just idle, waiting. I would return to a session that had been sitting still and prompt it to continue. Then again. This matters more than it sounds, because “keeps working after people close the app” is the promise that makes an agent worth having at all. A task you have to come back and nudge is not delegated work. It is the same work with extra steps and a delay in the middle.

Then the browser layer went down completely. Not one session. Every one.

The diagnostic it returned was accurate, which is worth crediting to the engineering rather than to the model. It reported that the browser backend had been erroring since that morning, that pages would not load at all, that this was infrastructure rather than my account or my machine, and that chat and files were working while browser automation was down. Asked whether it was systemwide, the reply was that no widespread outage reports could be found and that it could not determine whether this was one session's setup or something broader.

It did not hallucinate an explanation. An LLM asked to account for its own failure will usually generate something plausible and wrong, because generating plausible text is what it does. Getting an accurate diagnosis instead means the system is surfacing real state into the model's context rather than leaving it to guess, and that is an engineering decision worth noticing.

When I pushed for detail, the output was more specific than I expected, and more useful.

The explanation it returned: Muse does not browse from the machine running the model. It sends the job to Meta's system, which starts a real Chrome browser on one of their servers and runs the task there, then reports back. What was failing was the handoff. Its requests were returning “failed before dispatch,” meaning they never reached a browser at all. The analogy in its output: like calling a taxi dispatcher who never picks up. There is no car to inspect.

I asked whether it could troubleshoot using Chrome DevTools. The answer was no, with the reason: there is no Chromium running on its machine, no debugging port, nothing to attach to, and DevTools needs a running browser to talk to. “It's their infrastructure, and my only move is the retry timer I've got running.”

That detail matters more than the outage itself. Failed before dispatch is not a browser crashing, a site blocking automation, or a bad selector. It is requests never being allocated a browser in the first place. That is the signature of a scheduler under pressure, and it points somewhere specific.

I want to offer a possible explanation, clearly labeled as a guess, because I think it is the most likely one and it is more interesting than “the software is bad.”

Muse launched on 8 September. Within days it had passed 83,000 US iOS downloads. On 18 September, ten days after launch, it hit number one on the US App Store with more than 730,000 US downloads over that stretch, moving past ChatGPT, Google's Gemini, Anthropic's Claude and Meta's own Instagram on the free iPhone chart. For scale, that trajectory is close to ChatGPT's own 2023 launch, which did 697,000 US downloads in its first eight days.

My browsers went down two days after it took the top spot.

Now consider what Muse actually provisions per user. Not an API call. A dedicated virtual machine with its own live browser, running per person, persisting after you close the app. That is an enormously more expensive unit of infrastructure than a chat response, and the cost scales with every single signup rather than with every query.

So here is the guess: Meta may simply not have expected this many people driving real browsers at once. A chat product that goes viral needs more inference capacity. An agent product that goes viral needs more actual computers. I cannot prove that, and Meta has not said it. But it fits the shape of what I experienced, it fits the timing, and it is a far better problem to have than an architecture that does not work.

This is the part that deserves more attention than it is getting. Muse never sees your passwords. Meta's documentation is specific: credentials go into a Secure Credentials Store, and Muse completes an authorized action without the model ever seeing the password, including passwords you type into the browser yourself. Real credentials are injected at the network boundary by a separate agent called Sentinel, which sits outside Muse's main runtime and acts as the permission authority for connector actions and network traffic. The model can propose an action. It cannot authorize one.

The practical consequence is that if the model is ever prompt-injected into attempting something it should not, there is nothing useful for it to leak, because it never held the secret.

• Permissions are scoped rather than blanket: one time, session-limited, task-limited, time-bound or ongoing, and later actions must match the scope granted.
• Every user gets an isolated VM that no other agent can reach.
• There is a full audit trail of what the system has done and what it plans to do next.

I watched this work. At one point it surfaced a message that a stored sign-in had expired and a fresh one was needed, rather than failing quietly or prompting me to paste a password into the chat. That is a credential timing out and the system declining to route around it. It reads as friction. It is the architecture working as designed. If you are weighing whether to give any agent browser access to your accounts, this is the model to compare others against.

My hands-on read is that Muse is not as sharp as Claude. That is an opinion. What follows is not. I opened two independent sources directly rather than relying on write-ups: Artificial Analysis, which measures intelligence, speed and cost per task, and Arena, which ranks models on blind head-to-head human preference. Figures captured 20 September 2026. Both boards move, so check them yourself.

Arena's Agent leaderboard is the one that matters for a personal agent, and Muse is not on it.

The top ten reads: Claude Fable 5.1 (Max) at 13.71 percent, GPT-6 Astra (Max) at 11.54, Claude Opus 5 (High) at 10.25, Claude Opus 5 (Max) at 10.16, Claude Fable 5 (High) at 8.81, Claude Opus 4.8 (High) at 8.19, GPT-5.6 Sol (xHigh) at 7.10, Kimi K3 (Max) at 6.22, Claude Sonnet 5 (High) at 5.97, and GPT-5.5 (xHigh) at 5.03. Seven of those ten are Claude, and no Muse variant appears in the top ten at all, for a product whose entire proposition is being an agent.

It is not that Muse is weak generally. On Arena's Text board, Muse Spark 1.2 (xHigh) sits fourth at 1500 and Muse Spark 1.3 (Max) eighth at 1493, against Claude Fable 5 (High) leading at 1506. On WebDev it is eighth at 1652. On Vision, sixth at 1294. This is a capable model that is mid-pack to strong nearly everywhere, and absent precisely where it is sold.

On the Intelligence Index: Claude Fable 5.1 (max) and GPT-6 Astra (max) tie at 53, Claude Opus 5 (max) at 51, Muse Spark 1.3 (max) at 48, Muse Spark 1.3 (xhigh) at 45. But look at the other two columns. Muse Spark 1.3 runs at 224 to 250 tokens per second against 54 to 70 for the Claude and GPT frontier models. That is three to four times faster. And it costs $1.60 per task at max against $5.86 for Claude Opus 5 (max) and $7.63 for Claude Fable 5.1 (max). Roughly a quarter of the price.

So the honest summary is this. Muse gives up about five points of intelligence and buys three to four times the speed at a quarter of the cost. For a consumer product meant for everyone rather than for developers, that is a defensible trade and arguably a smart one. It also explains exactly what I felt using it. The speed is real and measurable, not a placebo. And the agent weakness is real too, and shows up in blind human preference testing, not only in my afternoon.

Match the tool to the stakes. For exploratory work, research, anything you were going to review anyway, Muse is already the quickest thing available and the parallel execution is a real advantage over what else is out there.

For recurring, unattended, business-critical work, I want a model that is dependable across long sessions and holds context reliably, and I will accept clicking some buttons myself. Consistency compounds. Novelty does not. That is not a knock on Muse, it is the same advice I would have given about any agent product in its first month.

The hard part here is already solved. Getting a model to plan multi-step work, drive a real browser, run several tasks at once, recognize a form, and halt for permission at the right points is the genuinely difficult engineering, and Meta has it working on day one at consumer scale. Infrastructure stability is a solved problem everywhere else in this industry. It gets solved here too.

Run a boring test, not an exciting one. Give it a multi-step task, walk away for an hour, and look at the state you come back to. Do that on three separate days. Those three hours will tell you more than any feature list, including this one.

The idea is there. The execution is not, yet. Those are very different problems and only one of them is fatal. I will run the same test in a month, and on the evidence of what Muse does when it is running, I would like to be writing a different piece then.