Realtime-Venus: Ant Group's Full-Duplex 9B Shipped Without a Launch

On 12 September 2026 a technical report went up on arXiv describing Realtime-Venus, a full-duplex interaction system built from two separately trained 9B models — Realtime-Venus-Omni for audio-visual interaction and Realtime-Venus-Audio for spoken interaction — credited to the Venus Team at Ant Group working with Tsinghua University. Within days an Apache-2.0 repository under inclusionAI/Realtime-Venus on Hugging Face held both checkpoints as downloadable BF16 safetensors, alongside a project page and a companion GitHub repository. What did not appear is the part worth noticing: no launch post, no product page, no API, no price list, and nothing on Ant Group's own properties announcing that any of it exists. This is a release that shipped everything except the announcement, which makes separating the established facts from the claims the whole job.

What is actually on the disk

The repository is not a stub. It carries two model directories, each with sharded safetensors weights, a config, and the custom Hugging Face Transformers code the card instructs you to load with trust_remote_code=True. There is a requirements file, an assets folder holding the token-to-waveform resources and a reference voice, and an Apache-2.0 licence at the top level. The card documents installation for Python 3.10 with CUDA and FFmpeg, and both a ModelScope mirror and a Hugging Face download path. The weights are real, the code is there, and nothing stops you downloading it today.

Two absences are as informative as the contents. The first is that the repository states plainly it is not deployed by any inference provider — there is no hosted endpoint, no serverless option, no third-party platform carrying it. The second is that downloads are not tracked at all, which means there is no public signal of how many people have pulled it. A model can look adopted or ignored on Hugging Face; this one is unreadable that way.

The two checkpoints, and what separates them

Both are 9B, both share a streaming backbone, and the difference between them is what they can perceive.

• Realtime-Venus-Omni — the audio-visual checkpoint. A SigLIP2 visual encoder for streaming frames, a Whisper-Medium audio encoder, and a Qwen3-8B language backbone. Accepts video or images, audio, and text; returns text and, optionally, a speech waveform.

• Realtime-Venus-Audio — the same backbone with vision switched off at load time. Audio and text in, text and speech out. It exists for the case where the camera is irrelevant and you want the smaller memory footprint and the simpler path.

• Shared specification — 40,960-token context on both, BF16 weights on both, speech generated as discrete S3 tokens decoded by a streaming flow-matching decoder rather than a separate text-to-speech model bolted on the end.

• Lineage — the model card states that 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 different and more specific claim than "a new 9B omni model."

The one genuinely new idea: delegation as a first-class stream event

Every full-duplex system in 2026 has to solve the same contradiction. Conversation control runs at millisecond-to-one-second granularity. Tool calls, retrieval, and hard reasoning take seconds to tens of seconds. A model that pauses to think stops being full-duplex; a model that never pauses cannot use a tool.

Realtime-Venus answers with a dual-loop runtime. The interaction loop runs in fixed one-second chunks, continuously ingesting audio and video features, updating conversation state, and deciding whether to listen or speak, while streaming text and aligned speech. It does not pause when background work is in progress. The second loop is a scheduler the paper calls Realtime-Venus-Harness: when the frontend decides a task exceeds what it can do inline, it emits an asynchronous delegation through private markers embedded in its own hidden sequence, and the harness executes the task in the background and reintegrates the result into the ongoing dialogue.

The detail that makes this more than a diagram is what the paper calls causal task capture — the delegated task is executed against an isolated snapshot of the conversation state, so that a long-running background task cannot be corrupted by the conversation moving on while it runs. That is the failure mode that makes most "delegate and keep talking" designs fall over in practice, and it is the most interesting thing in the report.

The harness is not in the weights. It lives in the GitHub repository as a separate component, which means the part that makes the architecture distinctive is the part you would have to assemble and trust yourself.

The numbers, and exactly whose they are

Every figure below comes from the technical report and the model card. None of it has been reproduced by anyone outside the authors, no third party has published an evaluation, and there is no leaderboard entry to check it against. Read them as the authors' own measurements.

• Video benchmarks, Realtime-Venus-Omni — best score on six of the eight benchmarks the report uses, including StreamingBench 70.2, OVO-Bench 64.7, and Daily-Omni 81.3.

• Audio benchmarks, Realtime-Venus-Audio — MMAU 78.0, MMAU-Pro 63.2, Llama Questions 83.8, Speech CMMLU 67.8, and a VoiceBench AlpacaEval score of 4.81 that the report describes as matching the best comparison figure.

• Full-Duplex-Bench v1.5 — response to 75% of user interruptions, with continuation rates of 97% under backchannels, 88% under other-directed speech, and 86% under background speech. The report states this exceeds Gemini 3.1 Live and GPT-4o on all three continuation metrics.

The Daily-Omni figure is the one worth pausing on. MiniCPM-o 4.5, the model this checkpoint is adapted from, reports 80.2 on the same benchmark. Realtime-Venus-Omni reports 81.3. If both numbers hold up, the improvement from a large post-training and runtime effort is roughly one point on a benchmark the base model was already strong at — which is a realistic result for this kind of work and a much less dramatic story than the headline "best on six of eight."

What is not established

The list of open questions is longer than the list of settled ones, and that is the honest state of a model six days old.

• No independent evaluation exists. Not an arena placement, not a third-party reproduction, not a single outside group that has published a number.

• No latency figure in milliseconds. The report describes a one-second interaction cadence and the card documents per-second streaming calls, but there is no published time-to-first-audio number, which is the metric this category is actually bought on.

• No API and no price, and no statement that either is coming. Whether this is a product in waiting or a research artefact that will stay a download is genuinely unknown.

• No stated intent from the vendor. The absence of an announcement is not evidence of a quiet launch strategy; it is also consistent with a repository published for a paper and nothing more.

• No production evidence for the harness. It is the load-bearing component of the architecture and the least documented.

Why the quiet route keeps happening

This is the second time this year that Ant Group's model work has reached the public through a repository rather than a launch. UI-Venus-2-9B, the lab's GUI agent, appeared on Hugging Face at the end of August 2026 with no paper, no project page and no announcement — and has since been followed by a report. Realtime-Venus arrived in the opposite order: report first, repository alongside, announcement still withheld.

The pattern is not unique to Ant Group. Chinese labs in particular have been shipping research artefacts and consumer deployments into the world while leaving the developer-facing announcement for later, or skipping it. For anyone tracking the field this is inconvenient, because the usual signal — a launch post, a rate card, a documentation site — is exactly the part that is missing. The artefact is the announcement now, and reading it carefully is the only way to know what shipped.

If you wanted to run it

The card is unusually practical for a release this new. Loading is standard: AutoModel.from_pretrained on the local checkpoint directory with remote code trusted, SDPA attention, and bfloat16. Full-duplex streaming is entered with a single call that switches the model into duplex mode, after which the documented loop is one second of streaming_prefill followed by streaming_generate, repeated. Long-video memory is enabled with a memory-minutes parameter set to forty and is described as training-free, which is notable for a capability that usually requires fine-tuning. Two caveats are documented rather than discovered: a frame cap that silently truncates long video unless a constant is raised before importing the utilities, and a CJK font requirement for non-Latin subtitles rendered into duplex video.

What the card does not give you is a hardware floor. A 9B model in BF16 is roughly eighteen gigabytes of weights before any activation memory, which puts real-time duplex inference on a serious GPU and out of reach of the laptop deployment that the MiniCPM-o family it derives from was partly designed for.

There is a seam here worth naming, because it is where a router actually fits. Realtime-Venus delegates its hard work — retrieval, complex reasoning, business API calls — out to a background model. That delegated leg is ordinary text inference, and it is the leg that decides whether your conversational front end is useful or merely fluent. OrcaRouter carries none of Realtime-Venus; the duplex layer here is a self-hosted download and we do not serve it. The reasoning it hands off is the part we do cover: nearly 200 models behind one key at provider list price with no markup, automatic failover when an upstream has a bad afternoon, a routing DSL that composes several models into one call, and model fusion for the cases where one model's judgment is not enough. The delegation marker is the frontend's decision; which model answers it is a configuration choice, and keeping that choice outside the weights is what lets you change it without retraining anything.

What would settle it

Three things would move Realtime-Venus from a paper with weights to a model anyone can evaluate. An independent group reproducing the Full-Duplex-Bench continuation numbers, because 97% under backchannels is an extraordinary figure and extraordinary figures need a second reader. A published latency number, because full-duplex systems live or die on time-to-first-audio and this one has not stated a target. And documentation for the harness, because the asynchronous delegation design is the only part of this release that is genuinely new, and right now it is the part you can read about but not easily adopt.

Until then the accurate description is narrow and unexciting, which is exactly why it is worth writing down: a real Apache-2.0 release of two 9B full-duplex checkpoints, built on an open backbone, with strong self-reported benchmarks, no independent verification, no API, and no announcement. Everything above that line is inference.