Muse Realtime Avatar: Meta Gives Its Muse Agent a Face, at 870 Milliseconds a Turn

The number Meta chose to lead with is 870 milliseconds. That is how long Muse Realtime Avatar takes, by Meta's own measurement, from the moment you stop talking to the moment the first byte of a synchronized voice-and-video reply arrives. It is a genuinely aggressive figure for a system that has to generate video, and it is worth reading precisely — because almost everything interesting about Meta's new embodiment model sits in the gap between what that number measures and what people will assume it measures.

Muse Realtime Avatar was announced on September 23, 2026 at Meta Connect and written up the same day by Meta Superintelligence Labs in a research post titled "Bringing Your Muse to Life." It extends Muse Realtime Voice, the conversational layer inside Meta's Muse agent, by giving it a body. It is not a chatbot with a stock avatar: you hand it a reference image — a photograph, a full-body illustration, an animal, a household object — and it renders that thing talking, gesturing and shifting posture in continuous video for the length of the conversation. Zuckerberg said on stage that the avatar attached to his own Muse is named Jolly.

A shared token stream, not a lip-sync pass

The architecture is the part worth understanding, because it explains why Meta keeps saying "embodiment" instead of "avatar." Muse Realtime Voice produces a stream of speech tokens — the post calls them VQs — that carry both the content of what is being said and its prosody: the pacing, the emphasis, the rise and fall. Muse Realtime Avatar consumes that same stream. It is an audio-driven Diffusion Transformer conditioned on those speech tokens, on the reference media you supplied, and on a rolling window of recent video latents, and it generates video in short causal chunks, feeding each new latent forward as motion context for the next one.

Sharing one token stream is what keeps voice, lip motion and expression locked together. The alternative — generate the audio, then run a separate lip-sync model over it — is how most of the avatar industry works, and it is why so many of those avatars look like they are being dubbed. Meta's design removes that seam by construction. The rolling latent window is the second half of the idea: without it, a chunk-based generator drifts, and by minute three your character has quietly become someone else.

Four published numbers, and what each one actually measures

Meta published more numbers than is usual for a research post attached to a consumer feature. All four below are company-reported, measured by Meta against baselines Meta chose; none of them has been reproduced outside the company.

• 870 ms from end of turn to first byte. This is a response-start figure. It is not the time to a complete reply, and it is not ongoing delivery latency for the rest of the call. A system can hit 870 ms to first byte and still feel sluggish at second twelve. Meta's post is explicit that this is the first-byte measure; coverage that omits the qualifier is reading it as end-to-end responsiveness, which it is not.

• 448×768 portrait video at 25 frames per second. That is a tall phone-shaped frame, not a landscape one, and 25 fps is cinematic rather than smooth — the standard frame rate for film, below the 30 or 60 fps a native camera feed would give you. Meta says demos are watermarked with a transparent overlay so a recipient can tell they are not looking at a normal camera feed.

• 60× fewer model evaluations. Covered properly below, because this is the number most likely to be misread.

• 12 concurrent real-time sessions on one NVIDIA GB200. Meta reports that its serving work — persistent KV caches, cache-aware routing, latency-aware dynamic batching, four-bit quantization-aware training, fused kernels and CUDA Graph capture, developed with NVIDIA — raised capacity 8× over its own two-step BF16 baseline. The arithmetic behind it is clean: each generation step produces eight frames, which is 320 ms of playback, in 20 ms of model time, or 2.5 ms per frame. Both the 12 and the 8× are against Meta's specified baseline, not against another vendor's hardware.

Why 60× is not 60× faster

The compression claim is the one that will get repeated most and understood least. Meta's teacher model was a 40-step diffusion model with three-way classifier-free guidance — three passes per step, so 120 model evaluations to produce one chunk of video. The student is an unguided two-step causal model with a fixed-length KV cache, trained by distillation and self-forcing, and it needs two evaluations for the same chunk. That is a 60× reduction in evaluations per chunk at, in Meta's words, near-teacher quality.

It is a per-chunk compute reduction. Sixty times fewer evaluations does not mean a user waits one sixtieth as long, because latency had other contributors before distillation and still has them after. The chart in Meta's own post shows what the reduction bought in quality terms: human preference rising from 45% to 55%. That is the honest version of the story — the point of the distillation was to make a system that could run in real time at all, and the quality cost was held to about ten points of preference rather than being eliminated.

The evaluation, including the result that went the other way

Meta tested against two commercial avatar systems, Runway Characters and HeyGen LiveAvatar, using matched avatar identities so raters were comparing the animation rather than the character design. Raters held two- to three-minute live conversations with each system and then compared visual quality, synchronization, character consistency and mannerisms.

Meta reports being preferred 78% to 22% over Runway Characters and 88% to 12% over HeyGen LiveAvatar, and preferred across every evaluated dimension. Then the post does something most vendor evaluations do not: it discloses that the mannerism comparison against Runway Characters was not statistically distinguishable from parity. A tie inside a sweep is a small thing, but it is the detail that tells you the sweep is being reported honestly rather than cherry-picked.

The limits of the test matter more than the tie. Two to three minutes is a short conversation. The raters were Meta's. And the post itself cautions that its demonstrations "illustrate model capability and do not all reflect avatars available in the Muse app" — which is a research team saying, plainly, that the video you watched is not necessarily the product you will get.

What you cannot do with it

There is no API for Muse Realtime Avatar. There is no price, no rate card, no waitlist and no published date. Meta did not say when users or developers will be able to use it. The 18-and-over Muse app is the only surface it is headed for, and the avatar is arriving alongside a set of other Muse features — voice customization, a Muse email address, Mac computer control, glasses integration — that have their own timelines, some of them stated as "coming months."

The comparison that matters here is not against Runway or HeyGen. It is against the rest of the Muse stack. Muse Spark, the reasoning model the agent runs on, has been available to developers since Meta opened it through the Meta Model API, and Muse Spark 1.2 is served through OrcaRouter as meta/muse-spark-1.2 at $1.25 per million input tokens and $4.25 per million output tokens, provider list price with zero markup, inside a one-million-token context window that already accepts text, images, video, audio and files. That is the part of Muse you can call today. The face is the part you cannot.

That asymmetry is worth sitting with if you are planning anything. 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 is on a rate card.

What to watch next

Three things would change this from an announcement into a decision. The first is a release date for the avatar inside Muse, because everything Meta published is about a model, and nothing it published is about a product you can use on a Thursday. The second is a latency measurement taken over a long conversation rather than at first byte — 870 ms is a starting gun, and the question a real call asks is what happens at minute ten. The third is whether the system holds character under adversarial conditions: a user who deliberately changes the subject, moves fast, or feeds it a reference image designed to look like a real person.

Until then, the honest summary is the one the research post implies without saying. Muse Realtime Avatar is a real piece of engineering with a real compression result behind it, demonstrated in a controlled setting, evaluated by the company that built it, in conversations that lasted as long as a coffee order. It is not vaporware. It is also not something you can buy, route, or benchmark — and those are different claims.