Realtime-Venus vs SeedRealtime: Two Opposite Ways to Be Unavailable

Realtime-Venus and SeedRealtime are the two halves of the same 2026 story, and they fail opposite tests. SeedRealtime is ByteDance's natively audio-visual full-duplex model, switched on inside the Doubao app on 5 August 2026 for free, reaching an audience its maker describes in the hundreds of millions — with no API, no model identifier, no price and no latency target. Realtime-Venus is a pair of 9B checkpoints from Ant Group's Venus Team and Tsinghua University, published on 12 September 2026 under Apache-2.0 with a technical report and no announcement, sitting in a repository that any engineer can download and almost none can realistically deploy. One of them you cannot call. The other you can download and then discover you have nothing to call it on. Both are genuinely at the frontier of the same capability, and neither has a benchmark that anyone outside its own authors has reproduced.

Two flavours of "you can't have it"

It is worth being precise, because the phrase "not available" hides a real difference.

SeedRealtime is unavailable in the way a consumer product is unavailable: it exists, it works, it has users, and the door is simply closed to developers. There is no API, no rate card, no documentation portal, and no stated timeline for one. ByteDance's route to market has been the app, and the app has been enough. What you get as a builder is a demo you can experience and cannot integrate.

Realtime-Venus is unavailable in the way a research artefact is unavailable: the weights are public, the licence is permissive, the code is there, and nobody is running it. The repository is not deployed by any inference provider, and downloads are not tracked at all, so there is no public signal of adoption either way. It is available in the sense that matters to a researcher and unavailable in the sense that matters to a product manager.

Put together, they frame the question this whole category is currently stuck on: the models that work are behind consumer apps, and the models you can run are not in production anywhere.

Both are at the tier that actually distinguishes 2026

A useful way to read the realtime field is in three levels. The first is half-duplex voice with vision bolted on — turn-based assistants that can see but still take turns. The second is audio full-duplex, listening and speaking at once with no camera: ByteDance's own Seeduplex, OpenAI's GPT-Live, xAI's Grok Voice Think Fast 2.0. The third is audio-visual full-duplex, where perception and expression span video and audio continuously.

SeedRealtime is the first model at the third tier to reach large-scale commercial deployment. Realtime-Venus is an open-weights entrant at the same tier — video through a SigLIP2 encoder, audio through Whisper-Medium, a Qwen3-8B backbone, and a one-second interaction loop that never stops perceiving. Its model card states it is adapted from MiniCPM-o 4.5, the OpenBMB omni-modal model released earlier in 2026, which puts the Ant Group contribution in the post-training and the runtime rather than the base architecture.

What they share, and what puts them a tier above the audio-only systems, is that neither pauses to look. Continuous visual perception while speaking is a genuinely different capability from describing a single frame, and both models were built around it.

What each one's numbers are worth

Neither model has a third-party benchmark. The evidence is not equivalent, though, and the difference matters.

• SeedRealtime publishes no benchmark at all. What ByteDance offers is a claim that dialogue rhythm problems — talking over the user, responding late, being triggered by a stranger's noise — drop by roughly half compared with a cascade system, from end-to-end human evaluations. The underlying data is not published.

• The predecessor's numbers are the same shape. Seeduplex, the audio-only model ByteDance shipped into Doubao in April 2026, was reported to halve false-response and false-interruption rates, cut endpoint latency by roughly 250 milliseconds, reduce premature responses by 40%, and raise call satisfaction by 8.34 points in a large-scale A/B test. All vendor-reported.

• Realtime-Venus publishes a table. Its report claims best scores on six of eight video benchmarks including StreamingBench 70.2, OVO-Bench 64.7 and Daily-Omni 81.3, and leads on MMAU 78.0, MMAU-Pro 63.2, Llama Questions 83.8 and Speech CMMLU 67.8 for the audio checkpoint.

• Both are unreproduced. A published table that nobody has checked and an unpublished A/B that nobody can check are different kinds of unverified. Neither is evidence you can build a procurement decision on.

The one comparison worth making inside the Realtime-Venus numbers is against its own base. MiniCPM-o 4.5 reports 80.2 on Daily-Omni; Realtime-Venus-Omni reports 81.3. A one-point gain over the model it was adapted from, on a benchmark that model already handled, is a plausible result for a post-training and runtime effort — and a much smaller claim than "best on six of eight" reads on its own.

The turn-taking problem, which is where full-duplex lives

Full-duplex is not a latency feature. It is a set of behaviours: knowing when a pause means "I am thinking" rather than "I am done", telling a bystander's conversation apart from the person talking to you, and staying quiet through a backchannel instead of treating "mm-hm" as an interruption.

SeedRealtime's approach is to model conversational state natively and drop the external voice-activity detector entirely, so turn-taking is a learned behaviour inside the network rather than a threshold applied to an audio stream. That is the same architectural commitment Realtime-Venus makes, and both are positioned against the cascade systems that need a separate component to decide who talks.

Where the evidence differs is that SeedRealtime's claim is about deployment at scale — hundreds of millions of users, real rooms, real noise — while Realtime-Venus's is about a benchmark. The Full-Duplex-Bench v1.5 results for Realtime-Venus-Audio — 75% response to interruptions, continuation of 97% under backchannels, 88% under other-directed speech and 86% under background speech, exceeding Gemini 3.1 Live and GPT-4o on continuation — are the most directly relevant numbers either model has published for this problem. They are also entirely self-reported, and 97% continuation under backchannels is a striking figure that deserves a second reader before anyone quotes it as fact.

Where each one leaves a builder

The practical gap is not quality, it is the shape of the offer.

• SeedRealtime — you can experience it in Doubao for free and integrate it never. There is no path from "this is impressive" to "this is in my product."

• Realtime-Venus — you can download it, fine-tune it, run it air-gapped, and inspect every layer. The cost is two 9B checkpoints in BF16 at roughly eighteen gigabytes of weights apiece, plus a continuous per-second streaming loop, which means a GPU node that bills whether or not anyone calls.

• Neither has a hosted option. Neither can be tried with a key and an afternoon.

That last point is the reason the two models are more useful as a pair than as opponents. Between them they demonstrate that both halves of the problem are solved — the capability works, and the weights are releasable — while showing that nobody has yet put them together into something a developer can actually call.

There is a workaround that a lot of teams will reach for, and it is worth being clear about what it does and does not cover. If you cannot get the voice layer, you can still build the part that thinks. Realtime-Venus delegates its expensive work — retrieval, hard reasoning, business API calls — to a background harness through asynchronous delegation markers, and that delegated leg is ordinary text inference. OrcaRouter carries neither Realtime-Venus nor SeedRealtime; both duplex layers are outside what we serve, and we do not host either. Nearly 200 text models behind one key at provider list price with no markup is the half of the architecture we do cover, with automatic failover so a background task does not fail because one upstream had a bad afternoon, a routing DSL for composing several models into one call, and model fusion where a single model's judgment is not enough. It is not the part of these systems that is hard. It is the part that is actually purchasable.

What would change this comparison

Three developments would settle it, and none of them has happened yet. An independent benchmark of Realtime-Venus, because a table with no second reader is a claim and not a result. An API for SeedRealtime, because the model with the strongest deployment evidence is currently the one nobody can use. And a published latency figure from either — time-to-first-audio is the metric this category is bought on, and as of this writing neither model has stated one.

Until then, the honest summary is that SeedRealtime is the proof that audio-visual full-duplex works at consumer scale and Realtime-Venus is the proof that the weights can be opened, and neither of those facts gets a builder any closer to shipping a product. That is not a criticism of either lab. It is a description of a category that has solved the research problem and not yet the distribution one.