Muse Realtime Avatar vs Realtime-Venus: Video Out Against Video In

Two systems announced nine days apart both call themselves real-time and both claim the audio-visual label, and they point in opposite directions along the same axis. Muse Realtime Avatar, announced by Meta on September 23, 2026, takes a photograph and generates video of it speaking — its video is output, 448×768 portrait frames at 25 per second, produced by an audio-driven Diffusion Transformer that shares a token stream with Muse Realtime Voice. Realtime-Venus, uploaded to arXiv on September 12, 2026 by the Venus Team at Ant Group with Tsinghua University, consumes video: the Realtime-Venus-Omni checkpoint streams camera frames through a SigLIP2 encoder and talks about what it sees, while the Realtime-Venus-Audio checkpoint is the same backbone with vision switched off at load time. One renders a face. The other watches one. Neither is callable, and only one of them is downloadable — which turns out to be the more consequential difference.

The availability inversion is worth stating plainly before anything else, because it runs against every expectation about a Meta product and a research-lab release. Meta's system is closed: announced at Connect, demonstrated in a research post, embedded in the Muse agent, with no API, no weights, no price and no date. Ant Group's system is open: two 9B checkpoints as BF16 safetensors under Apache-2.0 at inclusionAI/Realtime-Venus on Hugging Face, with custom Transformers code, a requirements file, a reference voice, a project page and a companion GitHub repository. The company with the consumer product shipped nothing you can hold. The research team shipped the whole thing.

What each one does with a frame

The direction of the video is the entire architectural difference, and it is not a matter of emphasis.

• Video — Muse Realtime Avatar generates it, conditioned on speech tokens, a reference image and a rolling window of recent video latents; Realtime-Venus-Omni perceives it, with a SigLIP2 visual encoder streaming frames into the model alongside audio.

• Audio — Muse Realtime Avatar drives generation from Muse Realtime Voice's speech tokens, which carry content and prosody together; Realtime-Venus generates speech as discrete S3 tokens decoded by a streaming flow-matching decoder, rather than bolting a separate text-to-speech model on the end.

• Backbone — Meta's architecture is an audio-driven Diffusion Transformer of undisclosed size; Realtime-Venus is built on a Qwen3-8B language backbone with a Whisper-Medium audio encoder, and its model card states the Omni checkpoint is adapted from MiniCPM-o 4.5.

• Weights — Muse Realtime Avatar's are not published and there is no indication they will be; Realtime-Venus ships two 9B checkpoints, BF16, 40,960-token context on both, under Apache-2.0.

• Access — Muse Realtime Avatar has no API and no date; Realtime-Venus has no API either, and its card states plainly that it is not deployed by any inference provider.

• Where it runs — Muse Realtime Avatar runs inside the Muse app for users Meta has not enumerated, on 18+ terms; Realtime-Venus runs on your own GPUs, today, if you have the hardware and the appetite.

Read the last two lines together and the practical difference appears. Neither system can be called. One of them can be run.

The 9B download is real, and so is what it costs you

Realtime-Venus is not a repository stub. The weights are there, the custom loading code is there, and the licence at the top level is Apache-2.0. Two things about it are worth knowing before you plan around it.

The first is what is not in the weights. The dual-loop runtime that makes the architecture distinctive — the one-second interaction loop plus a background scheduler the paper calls Realtime-Venus-Harness, which executes delegated tasks against an isolated snapshot of conversation state so a long-running job cannot be corrupted by the conversation moving on — lives in the GitHub repository as a separate component. The delegation design, which is the genuinely new idea in the report, is the part you assemble and trust yourself.

The second is the lineage. The card states the Omni checkpoint is adapted from MiniCPM-o 4.5, the 9B omni-modal model OpenBMB open-sourced earlier in 2026. That is not a footnote. It means Ant Group's contribution is the post-training, the runtime and the delegation design layered onto someone else's streaming backbone, which is a narrower and more specific claim than "a new 9B omni model" — and a more useful one, because it tells you where to look if something in the visual encoder misbehaves.

The numbers, and exactly whose they are

This is where the two systems converge in an unhelpful way: neither has a single independent evaluation. Meta's four figures are company-reported against baselines Meta selected. Realtime-Venus's are author-reported in a technical report, with no third party having published a run and no leaderboard entry to check against. There is no public measurement of either system by anyone who did not build it.

Meta's four, as published: 870 ms from the end of your turn to the first byte of a synchronized voice-and-video reply; 448×768 portrait video at 25 frames per second; 60× fewer model evaluations than its own baseline; and 12 concurrent real-time sessions on one NVIDIA GB200, an 8× capacity gain over Meta's two-step BF16 baseline. Meta also discloses preference results against two commercial avatar systems, one of which it reports as not statistically distinguishable from parity on mannerism — a disclosure worth crediting, since it is the kind of result most launch posts omit.

Ant Group's, as published: best score on six of the eight video benchmarks the report uses, including StreamingBench 70.2, OVO-Bench 64.7 and Daily-Omni 81.3 for the Omni checkpoint; and for the Audio checkpoint, MMAU 78.0, MMAU-Pro 63.2, Llama Questions 83.8, Speech CMMLU 67.8 and a VoiceBench AlpacaEval score of 4.81 the report describes as matching the best comparison figure.

One asymmetry in the evidence is worth naming. Ant Group's figures are benchmark scores with named test sets — reproducible in principle, by anyone willing to download the weights and run the suite. Meta's headline number is a latency measurement on Meta's own serving stack, which nobody outside Meta can reproduce because nobody outside Meta has the system. The open release, in other words, is also the more checkable one.

Why both of these are a routing problem in disguise

Neither system is a complete agent, and that is true in the same way for both. Muse Realtime Avatar is a render layer bolted onto Muse Realtime Voice, which is the conversational layer of an agent whose reasoning runs on Muse Spark. Realtime-Venus delegates anything that exceeds what it can do inline — retrieval, tool calls, hard reasoning — out to a harness that executes the work in the background against a snapshot of the conversation. In both designs the thing the user talks to is a front end, and the thinking happens in a separate text model.

That separate text model is the part you can route. On OrcaRouter it is one endpoint for 196 models across 15 providers, at provider list price passed through with zero markup, with automatic failover when a model errors or times out — which matters more than usual when the thing on the other side is a self-hosted checkpoint nobody has independently evaluated. We do not host Realtime-Venus: it is a download, and we do not serve it. We do not host Muse Realtime Avatar either, because nobody does. What we carry is the layer both architectures hand their hard work to, so an unproven component on either side of the conversation is one line of configuration rather than a production bet.

Which of these is actually further along

The instinct is to say Meta's, because Meta has the product and the demo video. The evidence says something more interesting. Meta's system has better production engineering — 12 concurrent sessions on a GB200 is a serving result, and the disclosed preference tests against shipping avatar products are the only head-to-head numbers either system has. Ant Group's system has better verifiability: named benchmarks, published weights, an Apache-2.0 licence, and a report anyone can attempt to reproduce.

What neither has is a way to pay for it. And the one that is closer to being usable is not the one with the consumer app — it is the one you can download tonight and find out about yourself, on your own hardware, with your own data, and no announcement required.

If you are choosing, the question is not which model is better. It is whether you want a face you cannot call or a camera you can run.