Orientation · not official documentation

A version number is not one quality score.

Q: What should I read to understand the model itself?

The Muse Spark 1.3 page covers the published figures in more depth, and the hands-on review covers how those numbers feel in an actual product rather than on a leaderboard.

The most recent release of Meta’s model got measurably better at tool use and measurably worse at long documents, in the same version, on the same day. Which of those matters is decided by what you are building so this page covers the published figures and what they imply for a real workload, and sends you to Meta for anything you would paste into code.

What the numbers mean The model line-up

4 named models 4 published figures 4 decisions first 0 endpoints here

Three published movements, two directions. “Newer” and “better” came apart here.

Read this first

What this page is, and what it deliberately leaves out

No endpoints, keys, SDKs, limits or prices

Not an oversight. Those are exactly the details that change without notice, and they are the one category where a confidently wrong third-party answer costs you an afternoon and possibly a production incident. An independent guide is the wrong source for anything you would paste into code.

What is here

The model names Meta has published, and what each is for
The benchmark figures that have been reported, with sources named
What those figures imply for a real workload
The decisions worth settling before you write code

What is not, and never will be

Base URLs, routes or request shapes
Authentication schemes or key formats
Exact model identifier strings
Token prices, quotas or rate limits

All of those belong in Meta’s own developer documentation, which is the only source that is both current and authoritative. Use this page to work out what to build on; use Meta’s to work out how.

If you found this page looking for a quickstart snippet, that is the honest answer rather than a disappointing one: a snippet from a site like this one is a liability, not a shortcut.

The line-up

Four named models, one of them actually documented

Worth being blunt about the asymmetry. One member of this family has published benchmark figures and a release history; the other three are names with very little attached to them publicly, and this page marks which is which rather than padding the gaps.

Muse Spark 1.3

Figures published

The general-purpose model, and the engine behind Meta AI since it replaced Llama across those products in April 2026. Version 1.3 arrived on 2 September 2026. This is the one you can actually reason about, because Meta published numbers and independent testers published more.

ContextA one-million-token window, accepting text, images and video.

StrengthsTool use, and efficiency roughly 20% fewer tool calls per task than 1.2.

WeaknessLong-document accuracy fell to 79% from 83%, per independent testing rather than Meta.

MoreThe figures in full, and how they feel in use.

Muse Code

Little published

Named as the code-oriented member of the family. Beyond the name and that positioning, there is not much in public no benchmark figures, no stated context window, no published comparison against the general model.

KnownThat it exists and is aimed at code.

Not knownEverything else. Any specification you find attributed to it on a third-party page deserves a source check.

Muse Voice Transcribe

Little published

Speech-to-text, by name. The consumer-facing equivalent is the system-wide dictation in the Mac app, which is a reasonable place to form an impression of the quality even though it tells you nothing about the developer-facing surface.

KnownThat it exists and handles transcription.

AdjacentDictation in the Mac app is the nearest thing you can try today how that behaves.

Muse Glimmer

Little published

The least-documented name in the family. It appears in Meta’s developer line-up without a published description detailed enough to build a plan around, and this page is not going to invent one.

KnownThat it is listed among the developer tools.

Not knownIts purpose, size, modality or availability. Treat confident descriptions elsewhere with suspicion.

Three of the four entries above are mostly absences. That is an accurate picture of what has been published rather than a gap in this page and if Meta’s documentation now says more, it supersedes this entirely.

Reading the figures

Four numbers, and what each one is really telling you

Benchmark deltas are almost always quoted in percentage points, which is the least useful way to hear them. A jump from 80% to 85% sounds like a five per cent improvement and is nothing of the sort.

Convert every benchmark movement into a change in failures. That is the number your users actually meet, and it is usually several times larger than the headline.

Eighty to eighty-five means failures fell from one in five to roughly one in seven about a quarter fewer. And the same arithmetic works in reverse: the long-document drop from 83% to 79% raised errors from roughly one in six to one in five, which is about a quarter more. A four-point regression and a five-point gain, almost identical in practical weight, pulling in opposite directions.

Which is why “is the new one better” has no general answer. It has an answer for a contract-reading product and a different answer for a tool-calling one, and those answers are opposites.

Same movement, two framings. Only one of them predicts what your support queue looks like.

Tau3-Bench Banking

35% → 47%

The largest single movement in the release, on a benchmark built around multi-step tool use in a constrained domain.

What it means: success rose by roughly a third in relative terms, but note where it started. At 47% the model still fails more of these than it completes, so a product built on this kind of task needs a failure path as a first-class feature rather than an afterthought.

Terminal-Bench 2.1

80% → 85%

A smaller headline movement, on a benchmark where the model was already competent.

What it means: about a quarter fewer failures one in five becoming closer to one in seven. Gains near the top of a scale are worth more than they look, because each remaining point is harder to win and every one of them is a user who no longer hits a wall.

Tool calls per task

about 20% fewer

Not an accuracy measure at all, which is why it is easy to skim past.

What it means: cost and latency, not quality. If you are billed per call or per token, this is the figure with the most direct line to your invoice and on an agentic workload it may matter more to your unit economics than either accuracy number above.

Long-document accuracy

83% → 79%

The one that moved backwards, and the one reported by independent testers rather than by Meta.

What it means: errors rose by roughly a quarter, from about one in six to one in five. If your product summarises contracts, reviews policies or answers questions over long files, this release is a regression for you regardless of what the other three columns did.

Benchmark figures as published; the tool-use and efficiency numbers are Meta’s, the long-document figure comes from independent testing. Relative changes above are ordinary arithmetic on those published values, not separate measurements. A benchmark is a proxy for your workload and never a substitute for evaluating on it.

Before you write code

Four decisions the documentation will not make for you

Meta’s docs will tell you how to call the thing. These are the questions that determine whether calling it was the right idea.

Decision one

Which column do you actually depend on?

Write down the one benchmark whose movement would change your product, before you read any more figures. For most teams it is exactly one, and knowing which makes every future release note a ten-second read instead of a debate.

Decision two

Does the regression sit on your critical path?

If long documents are load-bearing for you, the newest version is not automatically the one to build on. That is an unusual thing to have to consider, and this release is the reason it is worth considering at all. The detail.

Decision three

What happens when the model moves under you?

Assume it will. Meta replaced the engine behind its consumer products server-side and behaviour changed with no version moving on the client. Whether you can pin a version through the API is a question only Meta’s documentation answers ask it early. How that played out.

Decision four

What does your product do when it is wrong?

At 47% on a tool-use benchmark, failure is a normal operating condition rather than an exception. A product that only works when the model is right is not finished, and this is the design work that outlasts any model version.

Then evaluate on your own data anyway

Everything above is reasoning about somebody else’s measurements. A benchmark is a proxy, and the gap between a proxy and your workload is where most production surprises live. A hundred examples of your own, scored by hand, will tell you more than any published table.

Build that set before you choose a model, not after the first complaint it is also what lets you answer “did the upgrade help?” in an afternoon rather than an argument.

For integration specifics authentication, request shapes, model identifiers, quotas and pricing go to Meta’s developer documentation. Nothing on this page substitutes for it.

FAQ

Developer questions

Does this page have the API endpoint and authentication details?

No, deliberately. Endpoints, key formats, SDKs, rate limits and prices change without notice and are the one category where a wrong answer costs you real time. Those belong in Meta’s own developer documentation, and nowhere else. Why.

Which model should I build on?

Muse Spark is the general-purpose one and the only member of the line-up with published benchmark figures. The others are named products with little public detail, so choosing one of them is a decision to make from Meta’s documentation rather than from any third-party summary. The line-up.

Is Muse Spark 1.3 better than 1.2?

It moved in both directions at once. Tool use and efficiency improved while long-document accuracy fell from 83% to 79%, so whether 1.3 is an upgrade depends entirely on which of those your product depends on. The four figures.

What does a five-point benchmark gain actually mean?

Read it as a change in failures rather than a change in score. Terminal-Bench moving from 80% to 85% means one in five failures became closer to one in seven about a quarter fewer, which is a much larger practical difference than five points suggests.

Should I worry about the long-document regression?

Only if long documents are on your critical path. Going from 83% to 79% means errors rose from roughly one in six to roughly one in five, which matters a great deal for a contract-reading product and very little for a tool-calling one.

Can the model change underneath my application?

Treat that as the default assumption. Meta replaced the engine behind its consumer products server-side, and behaviour changed without any version moving on the client. Whether a pinned version is available through the API is something only Meta’s documentation can tell you. What changed silently.

Are there usage limits?

Certainly, but no specific figure should be taken from a page like this one. Consumer-side limits tightened once already without a price changing, which is a reason to design for a ceiling rather than to assume a particular one.

What is Muse Code for?

It is named as a code-oriented member of the line-up, and beyond that there is little published detail. That absence is worth stating plainly rather than filling with plausible guesses. What is known.

Is this page official Meta documentation?

No. This is an independent guide with no affiliation to Meta. It is orientation for deciding what to build on, and every integration detail should be taken from Meta’s own developer documentation.

What should I read to understand the model itself?

Muse Spark 1.3 covers the published figures in more depth, and the hands-on review covers how those numbers feel in an actual product rather than on a leaderboard.

Convert every delta into failures

Know which column you depend on.

One release moved three published figures in two directions. Teams who had already named their critical benchmark read that in ten seconds. Everyone else had a meeting.

What the numbers mean Muse Spark 1.3 in full

Four named models
One with published figures
No endpoints here, by design
Evaluate on your own data

Independent guide not affiliated with Meta and not official documentation. For endpoints, authentication, model identifiers, quotas and pricing, use Meta’s developer documentation. Why this page omits them.