# Qwen3.8-Omni-Flash: skipping most of the video on purpose

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/qwen3-8-omni-flash
> date: 2026-09-18
> tags: qwen, omni, multimodal, agents, benchmarks, pricing
[Qwen3.8-Omni-Flash](https://qwen.ai/blog?id=qwen3.8-omni-flash) is Alibaba's next omni-modal model — text, image, audio, and video in, text out, 1M-token context — and the announcement's own subtitle is "Omni Senses. Agentic Delivery." The senses part is the usual omni story. The agentic part is the actual news: the model is supposed to decide what to look at, rather than ingesting a video wholesale, and that's a real mechanism with real numbers behind it, not just a slogan.

It's API-only. I searched the `Qwen` org on Hugging Face directly — `Qwen2.5-Omni-7B/3B`, the `Qwen3-Omni-30B-A3B` family, a couple of quants — and neither `qwen3.8-omni-flash` nor its predecessor `qwen3.5-omni-plus` appear anywhere. [`Qwen-MM-Plugins`](https://github.com/QwenLM/Qwen-MM-Plugins), the toolkit Qwen ships alongside it, says the same thing in its own docs: audio for this model class is "handled through the API instead," because most agent harnesses can't feed audio to a local model at all. No weights means no `<ModelCard>` in this piece — there's nothing on the Hub to point one at, and DashScope's console, not a `config.json`, is the only source of truth for what this model actually is.

<Figure
  src="/articles/qwen3-8-omni-flash/fig1.png"
  alt="A grid of bar charts comparing Qwen3.8-Omni-Flash against Qwen3.5-Omni-Plus, Gemini 3.8 Flash, Seed 2.0 Lite, and Muse Spark 1.2 across agentic, audio-visual, and audio benchmarks, plus four pricing panels for video-with-audio input, audio-only input, and text input/output token prices, all lower for Qwen3.8-Omni-Flash."
  caption="Qwen's own benchmark-and-pricing grid. Every number this article checks is drawn from this figure and the tables underneath it. (Qwen, Qwen3.8-Omni-Flash announcement.)"
/>

Everything below either confirms a claim, corrects it against the primary source, or shows the arithmetic Qwen didn't spell out.

## Agentic perception: the mechanism behind "1M tokens"

The blog is specific about what changed: "For videos lasting several hours, conventional approaches require the model to process the entire recording from beginning to end, even when the answer appears in only a few minutes of footage. The native Qwen3.8-Omni-Flash agent starts from the question, independently decides what to watch and listen to, and locates key information through multiple rounds of coarse-to-fine evidence gathering." Static ingestion samples the whole file at a fixed rate; agentic mode treats "what to sample" as something the model plans, one function call at a time, conditioned on the question.

Qwen-MM-Plugins' `omni-memory` capability is a good place to see the same idea implemented rather than described, even though it's a separate piece of infrastructure — an agent-harness plugin that runs *around* an omni model, not the model's own internal benchmark loop. Its docs are blunt about the cost that motivates all of this: "Building one costs an omni call per 30s window, so over a short video it spends N calls indexing what fits in a single request." That's the naive-scan cost in one sentence — and it's exactly why the plugin's own routing table tells an agent to skip memory-building entirely under about ten minutes, and to build one without exception past thirty.

The one number Qwen actually discloses for the model's own agentic mode: on [OmniVideoBench](https://www.themoonlight.io/en/review/omnivideobench-towards-audio-visual-understanding-evaluation-for-omni-mllms) (Nanjing University's benchmark — 628 real videos, 4 seconds to 30 minutes long, averaging 384 seconds, about 6.4 minutes), switching from static to agentic reading lifts accuracy from 63.4 to 67.8 while token spend drops from 145,736 to 79,117. That's a **45.7% reduction** — not the 51.8% some secondary write-ups repeat. I could not find 51.8% anywhere in Qwen's own post, and every other value I found while checking (including a widely-echoed 145,736 → 79,117 pairing) resolves to the same 45.7%. Treat 51.8% as a number that got away from its source.

The accuracy claim, though, is exactly right, and worth sitting with: this is not a quality-for-speed trade. On this one benchmark, agentic mode is *both* more accurate and cheaper — a genuine Pareto improvement, not a dial you turn one way at the other's expense.

<AgenticTokenBudget />

Qwen discloses one point on that curve, not the curve — the chart above is my extrapolation from it, clearly marked as such. But the shape it implies is worth stating plainly: static ingestion samples at a fixed rate, so its cost is linear in video length, and Qwen3.8-Omni-Flash's own context window is 1M tokens. Linear growth from the disclosed anchor crosses that ceiling at around 44 minutes. Past that point, "process the entire recording from beginning to end" isn't merely wasteful — a single static pass over the video no longer fits in the model's own context at all, regardless of the question. Agentic perception here isn't an optimization you could skip if you didn't care about cost; on Qwen's own numbers, it's what makes a model with this context window able to answer a question about the top end of the video lengths it's rated for.

One more thing the same table shows, and the blog's prose doesn't mention: the "Agentic Omni Understanding" comparison ran the *same* Qwen Code harness against Gemini 3.8 Flash, not only against Qwen's own model.

| | Qwen3.8-Omni-Flash static | Qwen3.8-Omni-Flash agentic | Gemini 3.8 Flash static | Gemini 3.8 Flash agentic |
|---|---|---|---|---|
| OmniVideoBench | 63.4 | 67.8 (+4.4) | 65.2 | 70.1 (+4.9) |
| Video-MME-v2 | 65.0 | 71.3 (+6.3) | 71.0 | 72.7 (+1.7) |
| LVOmniBench | 63.3 | **73.6 (+10.3)** | 70.7 | 70.7 (+0.0) |

Gemini gains too, and on OmniVideoBench it gains slightly *more* in absolute points than Qwen does — the agentic wrapper isn't exclusive to this model. But it isn't uniform, either: on the longest-context benchmark of the three, LVOmniBench, Gemini's agentic score is identical to its static score — no improvement at all — while Qwen jumps 10.3 points and ends up ahead of Gemini on that row specifically. Wherever "approaching Gemini" holds for Qwen, it's this row, and the agentic wrapper, doing the work.

## "Close to," and "exceeds" — the blog is more careful than the resharing

The line that made the rounds: Qwen3.8-Omni-Flash "achieves audio-visual performance close to Gemini 3.8 Flash and overall audio performance that exceeds Gemini 3.8 Flash." That's Qwen's own wording, and it draws a real line most coverage erases — a Hacker News thread on the release collapses both halves into "audio-visual performance close to Gemini 3.8 Flash and overall audio performance that exceeds it," which is at least faithful, but plenty of secondary write-ups (and, when I asked a search tool to summarize the pricing, the tool itself) flatten it further into a flat "beats Gemini," or worse, attribute the >93%/>98% *price* cuts — which are against Qwen's own predecessor, Qwen3.5-Omni-Plus — to a comparison against Gemini. The blog never says that. Worth checking which of the two claims you're actually reading before repeating either.

<BenchmarkGap />

"Close to" holds up on audio-visual: five of the eight comparable rows sit within about two points either way, and Qwen leads three of them outright. It does not hold on the two benchmarks built specifically around *long* video — Video-MME-v2 (65.0 vs 71.0, a 6.0-point gap) and LVOmniBench (63.3 vs 70.7, 7.4 points) — which is the same territory the agentic-mode table above shows Qwen closing, not the static number the headline is drawn from.

"Exceeds" on audio is real, but it's not evenly true — it's carried almost entirely by multi-speaker transcription. Qwen's own combined-score formula for that (footnote 4 on the figure: `100 × [1 − (0.5×DER + 0.5×cpWER)]`) turns the diarization-error and word-error pairs into a single 0–100 score, and on that score Qwen3.8-Omni-Flash isn't close to anyone:

| Multi-speaker set | Qwen3.8-Omni-Flash | Gemini 3.8 Flash | Qwen3.5-Omni-Plus |
|---|---|---|---|
| AliMeeting-test | 89.7 | 37.1 | 11.1 |
| AISHELL-4 | 93.0 | 38.4 | 0.0 |
| MagicData-RAMC | 90.1 | 49.2 | 2.3 |
| MLC-SLM (en) | 90.9 | 56.3 | 33.8 |

(AliMeeting-test is Qwen's own figure; the other three rows are the same published formula applied to the raw DER/cpWER pairs in Qwen's table — the figure doesn't chart them, but the numbers are theirs.) Qwen3.5-Omni-Plus was close to non-functional at this specific task — an AISHELL-4 combined score of 0.0 means its DER and cpWER were both literally 100%. That collapse, not a close race, is most of what "exceeds Gemini" is describing.

Flip to ordinary single-speaker audio and the picture reverses. On MMSU, WildSpeech, VoiceBench, and Audio-MultiChallenge — the everyday tab in the chart above — Gemini leads on all four, and on VoiceBench the two-generations-old Qwen3.5-Omni-Plus (92.9) beats the new model (91.6) too. "Overall audio performance exceeds Gemini" is true averaged across 16 audio rows; it is not true on the ones that look most like a normal ASR benchmark.

## The +19.5-point average that's mostly one number

A separate claim going around: Qwen3.8-Omni-Flash gains 19.5 points on average across WildClawBench-MM and UniClawBench. That number is real — it's exactly the average of the two point deltas below — but it isn't how Qwen's own post frames either benchmark, and the framing matters:

| Benchmark | Qwen3.8-Omni-Flash | Qwen3.5-Omni-Plus | Δ vs Plus | Gemini 3.8 Flash |
|---|---|---|---|---|
| WildClawBench-MM | 71.0 | 34.5 | **+36.5** | 58.9 |
| UniClawBench | 69.6 | 67.1 | +2.5 | 69.0 |
| AgenticVBench | 36.8 | 14.5 | +22.3 | **45.0** |
| OmniGAIA | 74.0 | 57.2 | +16.8 | **78.6** |

`(36.5 + 2.5) / 2 = 19.5` exactly. But the blog's own prose states the WildClawBench-MM figure as a point gain ("improves by 36.5 points") and the UniClawBench figure as an absolute score ("scoring a strong 69.6") — never as a delta. Now it's clear why: UniClawBench barely moved. A 19.5-point average across two benchmarks really can be carried by one, and here it is.

The same table has two rows that don't fit "agents are the story" at all: Gemini wins AgenticVBench by 8.2 points and OmniGAIA — the one benchmark run with no agent framework at all — by 4.6. Four agentic benchmarks, evaluated with three different harnesses (Claude Code, OpenClaw, and none), and Qwen leads two, Gemini leads two.

## What it actually costs

Qwen's own pricing chart states two headline cuts against Qwen3.5-Omni-Plus: audio input down more than 98%, audio-visual input down more than 93%. A third number circulating — "video input costs reduced by about 89%" — isn't in the blog at all, but it isn't wrong either. It's measuring something narrower, and Alibaba Cloud's own [Model Studio pricing page](https://www.alibabacloud.com/help/en/model-studio/model-pricing) has the numbers to show which:

| | Qwen3.8-Omni-Flash | Qwen3.5-Omni-Plus | Cut |
|---|---|---|---|
| Input, text/image/video (per 1M tokens, Intl.) | \$0.15 | \$1.40 | **−89.3%** |
| Input, audio (per 1M tokens, Intl.) | \$0.15 | \$11.00 | −98.6% |
| Output, text (per 1M tokens, Intl., multimodal-input mode) | \$0.47 | \$8.30 | −94.3% |
| Video-with-audio input, blended (USD/hour, Qwen's own methodology) | \$0.20 | \$3.27 | −93.9% |

Qwen3.5-Omni-Plus billed audio input at a **7.9× premium** over its own text/image/video rate (\$11 vs \$1.4 per million tokens). Qwen3.8-Omni-Flash collapses that entirely: one flat \$0.15/1M rate covers text, image, audio, and video input alike. That's a pricing-structure change, not a demonstrated tokenization one — the console pricing tables don't disclose tokens-per-frame or tokens-per-second for either model, so I can't confirm the encoding itself got more efficient, only that the price schedule did.

Which is also why "89%" and "93%" are both correct and both real: they're the same rate cut, measured two different ways. \$1.40 → \$0.15 is the pure video/image/text tier, no audio blended in — **89.3%**, matching the pricing page exactly. Qwen's own headline **93.9%** is a haircut on a hardware where the input contains a video's *actual* audio track too — footnote in Qwen's chart: "the price per hour is estimated by multiplying the input cost of a two-minute clip by 30 \[…\] video inputs use a resolution of 720p and are sampled at 1 frame per second." Blending in the even-steeper audio-tier cut (−98.6%) pulls the combined number above the video-only figure. "About 89%" is the video-frame tokens alone; "more than 93%" is video *with* its soundtrack. Neither is the wrong number — they're not the same measurement.

<Callout type="note">
The pricing-console tables above are Alibaba's international rates. Domestic (China mainland) pricing scales down proportionally — \$0.113/\$0.014/\$0.382 for Qwen3.8-Omni-Flash versus \$0.96/\$7.29/\$5.5/\$29.29 for Qwen3.5-Omni-Plus — and the same 88–89% cut on the text/image/video tier holds in that currency too.
</Callout>

## What's real today, and what's still a 404

Two GitHub links sit side by side in the announcement. One works. The other doesn't, and the blog's own tense is worth quoting exactly: "we have further expanded Qwen-MM-Plugins \[…\] We have also **open-sourced** Qwen-Live Harness."

[`Qwen-MM-Plugins`](https://github.com/QwenLM/Qwen-MM-Plugins) is real — I cloned it. Apache-2.0, a working installer, and a Python package that names this exact model as its default:

```python
# src/shared/api_omni.py
DEFAULT_OMNI_MODEL = "qwen3.8-omni-flash"

# Per-model video-duration ceilings for SERVER-SIDE sampling (seconds), from
# Bailian/Model Studio docs, as of 2026-08:
_OMNI_VIDEO_MAX_SEC: dict[str, int] = {
    "qwen3.8-omni": 3600,          # 1 hour
    "qwen3.5-omni": 3600,          # 1 hour
    "qwen3-omni-flash": 20 * 60,   # 20 minutes
    "qwen-omni-turbo": 3 * 60,     # 3 minutes
}
```

That table is a fact about the API surface, not a marketing line: each server-side sampling ceiling roughly triples the previous Omni-Flash generation's, and it's read from the same Model Studio docs I pulled the pricing from — an independent, code-level confirmation of the "up to one hour" figure the blog states in prose for meetings.

[`Qwen-Live-Harness`](https://github.com/QwenLM/Qwen-Live-Harness) is a different story. Fetching that URL today returns a plain HTTP 404 — no README, no repository, nothing. A Hacker News thread on the release independently reports the same thing: "the announced harness GitHub repository returns a 404 error and appears to have been removed." So "coming soon," read literally, turns out to be the accurate framing — except it's not quite that simple either. The npm registry has a real, installable `qwen-live-harness` package, version 0.4.2, published the same day as the blog post, Apache-2.0, 140 files, a genuine compiled tool-dispatcher/memory/permission-broker system matching the blog's description ("task delegation, proactive interaction, long-term memory, and context management"). Its own `package.json` points its `repository` field and its `bugs` URL straight at `github.com/QwenLM/Qwen-Live-Harness` — the same repo that 404s. You can `npm install -g qwen-live-harness` right now and it works; you cannot read a line of its source, because the tarball ships only compiled `dist/`, and the source repo it names isn't public yet. "Open-sourced" shipped the binary before it shipped the source.

<Figure
  src="/articles/qwen3-8-omni-flash/fig2.png"
  alt="Diagram of the Qwen-Live Harness interaction framework: a main agent block containing Qwen3.8-Omni-Flash's Talker and Thinker sub-models, a vision encoder, and a spatial audio transformer, flanked by context (history, prompt, compress), memory (internal long/short-term and working memory, external audio-video memory), tools (search, code, retrieval), sub-agents, and a monitor, with a frontend block below running voice-activity start/end detection on the incoming audio-video stream."
  caption="Qwen-Live Harness's own interaction framework. Talker/Thinker is Qwen-Omni's known dual-stream design; Spatial AuT is new to this generation. (Qwen, Qwen3.8-Omni-Flash announcement, Figure 2.)"
/>

The diagram is worth a look even with the source unreachable, because it states two architectural facts the prose doesn't: Qwen3.8-Omni-Flash keeps the **Talker/Thinker** split from earlier Qwen-Omni generations (a reasoning "Thinker" and a generation-facing "Talker" as separate sub-models, not one monolith), and it adds a labeled **Spatial AuT** — an audio transformer with its own block, distinct from the vision encoder — which lines up with the blog's separate claim that Qwen3.8-Omni-Flash-Realtime is "the first omnimodal model capable of locating targets by sound." The harness wraps that core in a context manager, a two-tier memory (an internal long/short-term store plus an external audio-video memory — a persistent version of the same "don't re-watch it" idea the token-budget section covers), and a tool layer. None of that is verifiable against source code today; it's what the figure states, not what I could read.

One more real, checkable data point on the "agentic delivery" half of the name: Qwen says it tasked Qwen3.8-Omni-Flash with improving `Qwen2.5-Omni-3B`'s Sichuan-dialect speech recognition, unsupervised, in 12 hours. Across four rounds and 3,413 self-generated training examples, the smaller model's character error rate went from 25.79% to 15.30% — a 40.7% relative reduction. I have no way to independently verify a training run I wasn't given logs for, but the number is specific enough, and the mechanism (model diagnoses, generates data, evaluates, rolls back what didn't help) matches the same "plan, act, check evidence" shape the video-understanding claims describe. Consistent story, unverified run.

## Hearing where something is

Everything above is about *reading* recorded media. The other half of the launch is a second model — `qwen3.8-omni-flash-realtime` — that listens to a live stream instead, and the claim attached to it is the one no chart can carry: Qwen calls it "the first omnimodal model capable of locating targets by sound." That's the **Spatial AuT** block in the diagram above, doing something. Qwen ships a demo for it. Here are its last twelve seconds.

<Video
  src="/articles/qwen3-8-omni-flash/spatial-audio"
  poster="/articles/qwen3-8-omni-flash/spatial-audio-poster.jpg"
  alt="Split screen from Qwen's spatial-audio demo. On the left, a panel titled Reasoning holds the model's first-person account of the room, and below it a Trajectory Output table of eight waypoints with x, y and yaw columns. On the right, the robot's own camera view pans past a grey wall and a row of office chairs. The stage label at the top moves from 'Reason in Real Time to Plan Navigation Routes' to 'Generate Trajectories' to 'Locate the Sound Source', and the clip ends on a third-person shot of a quadruped robot walking up to a phone lying on the carpet."
  caption="The closing twelve seconds of Qwen's spatial-audio demo — re-encoded, muted and looped here; the source clip carries an English audio track. Left column: the model's own reasoning and the trajectory it emits. Right column: what the robot sees. (Qwen, Qwen3.8-Omni-Flash announcement, demo-13-robot-navigation.)"
/>

The setup, from earlier in the same clip: a quadruped robot in an office, a phone lying on the carpet, and a person who says — the transcript bubble carries a waveform icon, so it is spoken, not typed — "please go check, what is making the noise". The demo then names each stage on screen as it happens: *Prioritize Human Voice Commands*, *Understand Voice-Based Tasks*, *Determine sound direction and distance*, *Observe the Environment and Detect Obstacles*, *Reason in Real Time to Plan Navigation Routes*, *Generate Trajectories*, *Locate the Sound Source*.

What makes this worth more than the usual launch reel is that Qwen leaves two panels on screen at the same time and never connects them. On the left, the model's own reasoning — this is the frame at 55.5 seconds, transcribed:

<Callout type="note">
I am in a room with a grey wall on my left and a carpeted floor, with office chairs to my right. I need to find where the sound is coming from. **I hear the sound coming from my front-right at a medium distance of 1.2 meters, which aligns with the phone on the floor.** To reach the source, I need to move towards the open space on the right side of the room, navigating around the wall on my left. So I will **first move forward-right** to approach the area with the phone, and then continue moving forward-right to get closer to the sound source.
</Callout>

Directly below it, in the same frame, a `Trajectory Output` table: eight waypoints, each an `x`, a `y` and a `yaw`, in the robot's own body frame. Qwen prints both panels and comments on neither. And it does this **twice** — the same pair of panels, ten seconds earlier, with different numbers in both. At 45.5 seconds the model says it hears the sound "from my front-right at a medium distance of **2.2 meters**" and emits a different eight-waypoint table. Two stated distances, two plans, one clip. That is enough to check something.

<SoundTrajectory />

Take the later plan first. Waypoint 8 sits 1.101 m forward and 0.492 m right of where the robot started, so `hypot(1.101, 0.492) = 1.2059 m`, bearing 24.1 degrees right of straight ahead. The model said 1.2 m, front-right. The plan it wrote lands on that figure to within six millimetres.

The earlier plan does not, and that is the part that makes the later one interesting rather than suspicious. Told it hears something 2.2 m away, the model emits a path that stops at 0.958 m — 1.24 m short — and its own prose says so, promising only to "get closer to the noise source" rather than to reach it. The reason is visible in the table: every waypoint is either a 0.25 m step or a 15-degree turn, and a plan gets exactly eight slots. The far plan spends four of them turning — including its very last slot, one more 15 degrees right that it never gets to walk along — which leaves four steps, one metre of travel toward something 2.2 m away. The near plan spends only three on turns, leaving five steps and 1.25 m of travel, and ends on a step rather than a turn. That is just enough to close a 1.2 m gap. The planner isn't ignoring the distance it reports; it is spending a fixed budget against it and coming up short when the target is out of range.

Which is the honest reading: this is an internal consistency check, not a measurement. Nothing in either frame tells you how far the phone actually was. What it tells you is that the distance the model narrates and the path it then writes are the same quantity, coupled — not decorative text generated beside a trajectory computed by something else, which is the cheaper explanation worth suspecting in any vendor demo. With a 0.25 m quantum the achievable endpoints are coarse, so landing inside 6 mm of the stated 1.2 m is not a thing a grid that crude does by accident very often; with two samples from one vendor-chosen take, "suggestive" is as far as it goes.

The quantisation is worth carrying away on its own. *Step a quarter metre, turn fifteen degrees,* eight slots, emitted as a plan — that is a discrete action vocabulary, not continuous servoing toward a sound. Useful to have in mind before reading "the first omnimodal model capable of locating targets by sound" as something closer to a homing missile than to a planner that has been handed a bearing and a distance.

## What "low latency" actually measures

"Low-latency" appears in the Realtime section's prose with no number anywhere near it. The numbers exist, in one table near the bottom of the post headed *Throughput & Latency*, described as "the observed throughput and latency of the Qwen3.8-Omni-Flash-Realtime API under different input conditions." Qwen publishes four columns per row and never subtracts any of them from each other. Subtracting two is where the interesting part turns out to be.

<RealtimeLatency />

Two things fall out. First, the number that matters for anything voice-shaped is not time-to-first-token, it is **time to first audio packet** — the moment the person hears anything — and Qwen's own figure for that is 978 ms on audio-only input, rising to 1,215–1,350 ms once a video track is in the stream. Call it a second, and up to 1.35 seconds with vision on. That is measured by Qwen, on Qwen's infrastructure, and it is the only latency figure the entire launch offers. It is not a bad number; it is simply a much more specific number than "low-latency," and it is the one to hold up against whatever a competing realtime API publishes.

Second, the decomposition is stable in a way the raw table hides. Across all six conditions the wait for the first *text* token climbs 390 ms — 591 ms to 981 ms — as the input lengthens and gains video. The additional wait before the first *audio* packet, on top of that, stays between 356 and 408 ms: a 52 ms spread across conditions whose prefill cost nearly doubles. Prefill is what scales with the input; the speech stage charges a roughly fixed toll afterwards. The framework figure above draws Talker and Thinker as separate sub-models, and a fixed post-text cost is exactly the shape that separation would produce — though a latency table on its own cannot prove that is the cause.

Throughput is the least surprising row: 81–85 text tokens/s in every condition, and an audio-generation RTF of 0.1524–0.1538, i.e. a second of speech synthesised in about 154 ms. Roughly 6.5× faster than it plays, which is the margin that keeps a turn from stuttering once it has started.

Here is what that stream looks like from the client side. Abridged from Qwen's own WebSocket example in the post — audio in at 16 kHz, audio out at 24 kHz, one camera frame a second travelling alongside it:

```python
# Qwen3.8-Omni-Flash-Realtime over WebSocket — abridged from the official example
# at qwen.ai/blog?id=qwen3.8-omni-flash
# pip install websocket-client pyaudio dashscope opencv-python -U
import base64, os, time
import cv2, pyaudio, dashscope
from dashscope.audio.qwen_omni import (
    MultiModality, OmniRealtimeCallback, OmniRealtimeConversation,
)

dashscope.api_key = os.getenv('DASHSCOPE_API_KEY')
url = 'wss://dashscope-intl.aliyuncs.com/api-ws/v1/realtime'
model = 'qwen3.8-omni-flash-realtime'
voice = 'Tina'
video_fps = 1
video_size = (1280, 720)

class SimpleCallback(OmniRealtimeCallback):
    def __init__(self, pya):
        self.pya = pya
        self.out = None

    def on_open(self):
        # 24 kHz: the rate the model's own speech comes back at
        self.out = self.pya.open(format=pyaudio.paInt16, channels=1, rate=24000, output=True)

    def on_event(self, response):
        if response['type'] == 'response.audio.delta':
            self.out.write(base64.b64decode(response['delta']))   # play it as it arrives
        elif response['type'] == 'response.audio_transcript.done':
            print(f"[LLM] {response['transcript']}")

pya = pyaudio.PyAudio()
callback = SimpleCallback(pya)
conv = OmniRealtimeConversation(model=model, callback=callback, url=url)
conv.connect()
conv.update_session(
    output_modalities=[MultiModality.AUDIO, MultiModality.TEXT],
    voice=voice,
    instructions="You are Qwen-Omni, a helpful assistant.",
)

mic = pya.open(format=pyaudio.paInt16, channels=1, rate=16000, input=True)   # 16 kHz in
camera = cv2.VideoCapture(0)
next_frame_at = 0.0
while True:
    audio_data = mic.read(3200, exception_on_overflow=False)     # 3200 frames @ 16 kHz = 200 ms
    conv.append_audio(base64.b64encode(audio_data).decode())
    success, frame = camera.read()
    if time.monotonic() >= next_frame_at:
        frame = cv2.resize(frame, video_size)
        success, image = cv2.imencode('.jpg', frame, [cv2.IMWRITE_JPEG_QUALITY, 80])
        conv.append_video(base64.b64encode(image).decode())       # one JPEG per second
        next_frame_at = time.monotonic() + 1 / video_fps
    time.sleep(0.01)
```

One detail in there is worth carrying into any latency comparison you make: `mic.read(3200)` at 16 kHz is a 200 ms block. The reference client hands the socket a fifth of a second at a time before anything reaches the API at all. Whatever Qwen's own harness did when it produced the table above, client-side chunking of that size is part of what a user experiences, and it is a knob, not a property of the model.

## The knobs that ship with it

The non-realtime path is an ordinary OpenAI-compatible Chat Completions call, which is most of why this model is easy to try and impossible to inspect. Qwen's own example, with the parameters that actually change the bill:

```python
# Qwen3.8-Omni-Flash, OpenAI-compatible endpoint — abridged from the official
# example at qwen.ai/blog?id=qwen3.8-omni-flash
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DASHSCOPE_API_KEY"],
    # Beijing: https://dashscope.aliyuncs.com/compatible-mode/v1
    base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)

messages = [{
    "role": "user",
    "content": [
        {"type": "image_url", "image_url": {
            "url": "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20241022/emyrja/dog_and_girl.jpeg"}},
        {"type": "input_audio", "input_audio": {
            "data": "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20250211/tixcef/cherry.wav",
            "format": "wav"}},
        {"type": "text", "text": "Please describe the image and tell me what is being said in the audio."},
    ],
}]

completion = client.chat.completions.create(
    model="qwen3.8-omni-flash",
    messages=messages,
    extra_body={
        "enable_thinking": True,
        # "preserve_thinking": True,
    },
    reasoning_effort="xhigh",   # supported levels are xhigh, medium, and low
    stream=True,
)
```

`reasoning_effort` takes `xhigh`, `medium` or `low`, and the post is explicit that **`xhigh` is the default** — the most expensive setting is what you get if you don't pass the parameter, which is worth knowing given that the whole pricing story above is about the input side. `preserve_thinking`, likewise, is "enabled by default across all scenarios for the best out-of-the-box experience," so reasoning tokens stay in the context across turns unless you turn that off. Audio arrives as a first-class `input_audio` content part with a URL and a `format`, alongside `image_url`, in one message — that packaging, not the benchmark table, is the thing that makes this feel like a model rather than a media pipeline stitched to a chat endpoint.

The realtime harness installs in three lines, exactly as the post prints them:

```bash
npm install -g qwen-live-harness
qwen-live-harness init
qwen-live-harness
```

Those still work. `github.com/QwenLM/Qwen-Live-Harness` still does not: I re-checked the `QwenLM` org through the GitHub API while writing this section, and a name search across it returns `Qwen-MM-Plugins` and a small `qwen-mm-plugins-hub` docs repo — no harness, on the same day as "we have also open-sourced Qwen-Live Harness."

## The ledger

**Well evidenced.** The 45.7% token cut on OmniVideoBench, the accuracy gain that comes with it rather than against it, and the pricing-tier collapse that makes "89%" and "93%" both true statements about different things — all three check out exactly against Qwen's own tables and Alibaba Cloud's own console. So does the Qwen-MM-Plugins repository, and the video-duration ceiling it states independently confirms the "up to one hour" figure in the announcement's prose. The spatial-audio demo is better evidenced than a demo usually is: it shows its panels twice with different numbers in them, and both times the distance the model narrates and the path it then writes are the same quantity — reached to six millimetres when the eight-waypoint budget can cover it, honestly falling 1.24 m short when it cannot.

**Load-bearing framing.** "Approaching Gemini" and "exceeds Gemini" are both true on average and both concentrated in a handful of rows — long-video reasoning is where the audio-visual gap is real, and multi-speaker diarization is almost the entire audio lead. The +19.5-point agentic average is arithmetically correct and is carried almost entirely by one of its two inputs.

**Underspecified.** "Low-latency" is prose; the only number behind it is a single table saying roughly one second to the first audio packet, 1.35 s with video in the stream, against no baseline and on undisclosed hardware. The same table's stable finding — that the speech stage adds a near-fixed 356–408 ms on top of prefill however the input grows — is mine, from subtracting two of Qwen's own columns, and it is a pattern in six rows, not a guarantee.

**Not shown.** Whether the flat \$0.15/1M input price reflects a genuinely more efficient tokenizer or just a different price schedule on the same encoding — the console gives prices, not tokens-per-frame. What "51.8% fewer tokens" was supposed to refer to; I never found it. And whether `Qwen-Live-Harness`'s source will match the compiled package already sitting on npm, since as of this writing there's nothing at the URL to check it against.