Muse Realtime Avatar Leaves the Research Post: Inside Meta's US Muse App Rollout

There is a sentence at the bottom of Meta's September research post that has quietly stopped being true. It reads: "All examples in this blog post illustrate model capability and do not all reflect avatars available in the Muse app." On 5 November 2026, Meta began rolling Muse Realtime Avatar out inside the Muse app in the United States, which means some of those avatars are now exactly what is in the app. The research demo became a consumer surface, in one country, without a launch event, a price list, a developer page or a version number attached to it. Muse Spark 1.2 sits on the same key as everything else in the full model catalogue so a second vendor contract is not part of the plan.

That is the whole news, and it is worth being precise about its size. Nothing about the model changed on 5 November as far as Meta has published. What changed is who can press the button. Everything Meta measured in September — the 870-millisecond first byte, the 448×768 portrait frame, the twelve concurrent sessions on one GB200 — still stands as a vendor-reported figure from a two-to-three-minute rated conversation, and none of it has been independently reproduced. The rollout is a distribution fact, not a capability fact, and the two get blurred constantly in the week after something ships.

What actually changed on 5 November

Meta's own account is a single post from the @AIatMeta account, timestamped 18:36 UTC on 5 November, and it is unusually terse for a product release. It says the company previewed Muse Realtime Avatar during Connect, describes it again as "our real-time embodiment technology that turns Muse Realtime Voice into expressive, interactive avatars," and then states that it is rolling out in the Muse app in the US to give people "a more natural way to engage with their personal agents."

There is no second research post, no model card, no changelog and no API announcement. Press coverage the same evening reduced it to a consumer line — one syndicated headline ran "Meta says US users can now video chat with their Muse AI avatar" — which is accurate and also the entire public record of the change. If you were waiting for a technical disclosure to accompany the rollout, there wasn't one.

What that leaves is a product that exists in exactly one place: the Muse app, on a US account, for a user aged 18 or over. Not the web, not WhatsApp, not the Mac app, not an endpoint. Meta's Muse help centre still says the app and website "are not yet available everywhere" and that some features may not be available in a given area, and the rollout post says the US explicitly, which is the strongest signal available that this is a staged deployment rather than a global switch.

The demo and the product are not the same build

This distinction matters more than it usually does, because Meta spent September showing things the app may not do. The research post's evaluation used raters in two- to three-minute live conversations with matched avatar identities, comparing Muse Realtime Avatar against two commercial systems across visual quality, synchronization, character consistency and mannerisms. The examples in that post included animals and household objects as well as photographic portraits and full-body illustrations — a range wide enough that Meta felt obliged to add the caveat about which of them reflect the app.

The caveat was the honest part, and the rollout has not replaced it with anything. Meta has not published a list of what the app build supports: whether every reference-image category is enabled, whether a user can supply their own image or only pick from a library, whether a session has a time limit, whether the 448×768 at 25 fps envelope from the research post is what a phone actually renders, or whether the watermarking described in the paper is applied to app output the same way. Those are the questions a user asks in the first ten minutes, and none of them has a published answer.

What is confirmed on the record is narrower: the thing exists in the app, it is built on the same two-layer design Meta described, and it is aimed at making an agent feel less like a chat window. The design itself is not in doubt. Muse Realtime Voice produces a stream of speech tokens — Meta calls them VQs — carrying both what is said and how it is delivered, and Muse Realtime Avatar consumes that same stream rather than running a separate lip-sync pass over finished audio. Meta's description of the renderer is "an audio-driven, Diffusion Transformer conditioned on speech-token stream, reference media, and a rolling window of recent video latents," generating "video in short causal chunks."

That architecture is why the avatar can hold a character across a long conversation at all: each finished chunk feeds its newest latents forward as motion context for the next, so appearance and mannerisms carry rather than drift, while the compute stays bounded per chunk. It is also why the whole thing lives or dies on the voice layer being good. A renderer that consumes the conversational model's own token stream inherits every hesitation and every bad turn-taking decision upstream.

870 milliseconds, now with a distribution channel attached

The latency figure is the one that will follow this product around, so it is worth restating what it measures before the rollout stories flatten it. Meta reports approximately 870 ms from the end of a user's turn to the first byte of the synchronized voice-and-video response. It is a response-start measurement. It is not the time to a complete reply and it is not steady-state delivery latency ten minutes into a call, and a system can hit 870 ms to first byte and still feel slow at minute twelve.

The serving numbers behind it are the more interesting engineering, and they are all relative to Meta's own baseline rather than to anyone else's hardware:

• Frame budget — each generation step produces eight frames, which is 320 ms of playback, computed in 20 ms, or 2.5 ms of model time per frame.

• Concurrency — the optimized stack, including four-bit quantization-aware training, persistent KV caches, cache-aware routing and latency-aware dynamic batching built with NVIDIA, raises serving capacity 8× over Meta's two-step BF16 baseline, which is what enables 12 concurrent real-time sessions for video generation on a single GB200.

• Distillation — the teacher used 40 diffusion steps with three-way classifier-free guidance, 120 model evaluations per chunk; the distilled student reproduces a chunk in two unguided evaluations. That is 60× fewer evaluations, and Meta reports human preference moving from 45% to 55% between the two.

The 60× is the number most likely to be misread, so: it is a per-chunk compute reduction, not a sixty-fold speed-up in what a user feels. Sixty times fewer evaluations buys the ability to run at all in real time. Meta's own chart shows what the compression cost in quality — roughly ten points of human preference — which is a much more honest framing than "near-teacher quality" on its own.

There is no price, and the subscription is not one

The obvious question after "where can I use it" is "what does it cost," and the honest answer is that Meta has not priced the avatar. What Meta has priced is Muse itself. The help centre lists a free tier with a usage limit, a Power plan at $20 a month carrying 500 million Muse tokens a week, and a Maximum plan at $100 a month carrying 3 billion Muse tokens a week, with subscriptions sold through the app or at muse.ai.

Those are token allowances for an agent that reads, writes, browses and runs tools. Meta has published no conversion between Muse tokens and seconds of rendered avatar video, and it would be wrong to invent one. The defensible statement is that the avatar has no separate meter: if it is available on your account at all, it is available inside a subscription you were already buying for other reasons, and the marginal cost of using it is unknown to anyone outside Meta.

That also means the usual price-comparison reflex has nothing to grip. A team that wants to budget for avatar minutes cannot, because there is no unit to buy. A consumer deciding whether the $20 tier is worth it cannot isolate the avatar's contribution to the value. Meta has shipped a capability without shipping a way to reason about its cost, which is normal for a consumer feature launch and unusual for anything a business might plan around.

The developer question got worse, not better

Before 5 November, the standard answer to "can I build on Muse Realtime Avatar" was "not yet, it's research." After 5 November that answer is still no, but the reason has changed in a way that matters for planning. The model is now shipping to consumers and there is still no endpoint, which moves it from "unreleased" to "released without a developer surface" — a category that can persist for a long time.

The evidence is not a guess. Meta's own developer products index lists Muse Code, Muse Wonder, Muse Spark, Muse Spark Open, Muse Glimmer, Muse Image and Muse Voice Transcribe. It does not list Muse Realtime Avatar, and it does not list Muse Realtime Voice. The two layers of the streaming system that this whole product is built on are absent from the developer catalogue while everything else in the family is present. That is a deliberate boundary, not an oversight.

So the practical split in the Muse family is sharper now than it was in September:

• Shipped to consumers, no developer access — Muse Realtime Avatar and the Muse Realtime Voice layer beneath it. Available in the Muse app in the US, 18+, no API, no price, no docs.

• Shipped to developers, priced per token — Meta Muse Spark 1.2, the reasoning model the agent runs on, which is routable today as meta/muse-spark-1.2 at the provider's list price with zero markup, on the same OpenAI-compatible key as the rest of the catalogue. Its predecessor, meta/muse-spark-1.1, is on the same list.

That second line is the only part of this story a builder can act on, and it is worth being blunt about the asymmetry: an agent that reasons over a video call and an agent that appears in one are different products with different constraints, and only one of them has a rate card. If you are prototyping a conversational agent today, you are renting the intelligence and hand-rolling the face — or waiting.

What would change this again

Three developments would turn this rollout into something a team can plan against, and none of them is announced.

The first is a developer surface. An endpoint for either layer — even a waitlist — would move the product from a consumer feature into an infrastructure decision. Until then, every architecture that includes an embodied Meta agent has an unimplementable component.

The second is a measured latency curve rather than a single first-byte number. The interesting question about a system that streams causally is not how fast the first chunk arrives but whether the tenth minute looks like the first: whether the rolling latent window holds character under a user who interrupts, changes subject or moves abruptly. Meta's rated conversations lasted two to three minutes, which is a coffee order.

The third is a regional expansion with a published feature matrix. A US-only rollout tells you the deployment is staged; it does not tell you what a non-US user will eventually get, or whether the reference-image range in the research post survives contact with a consumer app.

Until one of those lands, the accurate one-line state of Muse Realtime Avatar is this: it is a real system with a real compression result and a real serving story, it is now in a real app for real users in one country, and it is still not a thing you can call. The gap between those two sentences is where every bad prediction about this product will come from — in both directions.