TL;DR — MiMo-V2.5 is Xiaomi's open-weight model built to take audio, image, and video natively in one context rather than piping a transcript through a separate text model. Today's probes only exercised its text reasoning, code, and JSON-extraction abilities — all clean — while the omnimodal side rests on vendor description, not measured benchmarks. The real draw for builders is a 1.05M-token context and self-hosting, which matters most for meeting intelligence and call analytics in privacy-bound fields.
Most "multimodal" open-weight models are a text model with a transcription step duct-taped to the front door: Whisper turns audio into words, an OCR pass turns an image into words, and the LLM never actually hears or sees anything. MiMo-V2.5 is pitched differently — Xiaomi's release notes describe it as taking audio, image, and video into the same context as native tokens, not as a pre-processed transcript. That distinction matters for anything where tone, timing, or visual detail carries information text can't capture: a sigh mid-sentence on a support call, a whiteboard sketch in a meeting recording, a gesture in a video clip.
What's actually verified here
The metadata I have permission to quote is narrower than the marketing story, so let's be precise about it. MiMo-V2.5 (Hugging Face ID XiaomiMiMo/MiMo-V2.5) ships with a context length of 1,050,000 tokens — big enough to hold a multi-hour meeting recording's worth of tokens without chunking, assuming the audio pipeline tokenizes efficiently. Pricing on the hosted route I probed is $0.14 per million prompt tokens and $0.28 per million completion tokens. Filling that entire context once would cost roughly $0.147 just in prompt tokens — cheap enough that long-context use isn't the expensive part; the inference compute to actually decode a long video is.
What the probes actually tested (and what they didn't)
Here's the honest part: the probe suite run against this model today was text-only — a coding task, an arithmetic reasoning task, and a structured-extraction task. I have no audio, image, or video transcripts to grade, so I can't verify the omnimodal claim against measured evidence. What I can verify is the text reasoning stack underneath it, since that's the same model doing the "thinking" regardless of which modality fed it.
On the coding probe — write merge_intervals and state its time complexity — the model sorted by start time, merged correctly, and returned [[1,6],[8,10],[15,18]] for the test case, which is right. It also correctly named the complexity as O(n log n), driven by the sort. That took 6.6 seconds for 239 completion tokens, about 36.4 tokens/sec.
The reasoning probe — a two-pump tank problem — is where I look hardest for silent arithmetic drift, and there wasn't any: net fill rate of 30 L/min for 20 minutes gives 600 L, leaving 1,800 L, which at 90 L/min alone takes exactly 20 more minutes. Correct, and shown in four clean steps, in 4.5 seconds at 47.7 tokens/sec — the fastest of the three runs.
The structured-output probe asked for strict JSON with three keys pulled from an invoice. The model returned valid JSON with the right vendor and date, though it kept the dollar sign in the total field rather than emitting a bare number — technically faithful to the source text, but the kind of detail that will bite you if a downstream system expects 445.50 as a float rather than a string. Worth a schema note or a stricter prompt if you're piping this into anything that parses currency.
The use case: ears and eyes that don't leave the building
The editorial reason to care about MiMo-V2.5 isn't the invoice-parsing accuracy — plenty of smaller text models do that fine. It's that a native omnimodal model, self-hosted, gives you a single inference stack for jobs that currently require stitching together three separate services: a speech-to-text vendor, a vision API, and an LLM, each with its own data-handling agreement.
Meeting intelligence: feed the raw audio (or video, if screen shares matter) directly into a 1.05M-token context and ask for action items, decisions, and who committed to what — without a transcript vendor ever touching the recording.
Call center analytics: tone, hesitation, and cross-talk carry signal that a clean transcript throws away. A model that ingests audio natively can flag frustration or confusion patterns a transcript-only pipeline misses entirely.
Voice interfaces: on-device or on-prem voice assistants that need to reason about what was said and how it was said, in one pass, without round-tripping through a cloud STT API.
What ties all three together is the same constraint: none of them can send raw audio or video to a third-party API in a regulated environment. Call recordings, meeting footage, and voice logs are exactly the kind of artifact that legal, healthcare, and financial teams are told not to hand to an external vendor. A self-hostable model with the weights on Hugging Face — at $0.14/$0.28 per million tokens if you do use a hosted endpoint, or free of that fee entirely if you run it yourself — is the shape of tool those teams actually need, which is precisely the setup tomorrow's episode leans on.
The honest gap
I want to flag this plainly rather than bury it: everything above about audio and video is the model's stated design, not something I measured today. The probes prove the text reasoning core is solid — correct algorithms, correct arithmetic, valid JSON — which is a reasonable proxy for "the brain works," but it's not proof that the audio or video encoders perform well on real recordings, handle background noise, or hold up on long video with fast cuts. If you're evaluating MiMo-V2.5 for a voice or video workload, budget time to run your own probes on your own audio before you commit infrastructure to it. Treat the omnimodal capability as a vendor claim worth testing, not a fact worth assuming.
Should you deploy it
If your workload is genuinely multimodal and privacy-bound — meeting recordings, call audio, video review — MiMo-V2.5's pitch is worth a pilot precisely because the alternative is three vendors and three data-sharing agreements instead of one model you control. If your workload is really just text with a transcript step in front of it, you don't need this model; a smaller, cheaper text-only model fed a transcript will do the same job for less compute. The 1.05M-token context is the single most interesting number in the metadata — it's the difference between chunking a two-hour recording into fragments and reasoning over the whole thing at once.
Tomorrow's episode turns to open-weight AI in healthcare — a field where "self-hostable" isn't a nice-to-have, it's the whole reason a model gets considered at all.
The numbers (measured, not quoted)
I ran three quick probes against Xiaomi MiMo-V2.5 via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 6.6s | 239 | 36.4 | completed |
| Reasoning | 4.5s | 215 | 47.7 | completed |
| Structured output | 2.9s | 95 | 32.9 | completed |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 1,050,000 tokens · hosted pricing $0.14/M input · $0.28/M output · weights: XiaomiMiMo/MiMo-V2.5 on Hugging Face
Credits — where it's due
- Xiaomi — for training Xiaomi MiMo-V2.5 and releasing the weights openly: XiaomiMiMo/MiMo-V2.5. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (1)
Omnimodal open weights are great but voice eval needs separate audio + text rubrics. ASR errors cascade differently than token errors.