Mistral published the weights for Large 4 (“Le Chonk”) on 29 October 2026: roughly 1 trillion total parameters, ~49–52 billion active per token, native multimodal, 1 M context, trained on their own European Grace Blackwell cluster. It sits at the top of open models on coding-agent indexes while burning about 47 % fewer tokens than the next closest open contenders on the same tasks. Day-zero support landed in transformers, vLLM, SGLang and llama.cpp; GGUFs exist.
Those numbers matter for anyone shipping agentic tooling. They are almost orthogonal to the problem that actually bites when you try to put a streaming recognizer in front of a Windows call or interview.
The model is downstream of the audio engine
A 1 T MoE that activates 50 B parameters is still sitting behind the same WASAPI shared-mode period that every other local or remote STT sees. On a typical Windows 11 desktop the timeline for a live overlay looks like this:
- Capture quantum: 10 ms default (shared mode), occasionally 5–8 ms if the driver and you both cooperate
- Format conversion + lock-free ring-buffer copy (48 kHz float32 → 16 kHz int16): 1–3 ms off the audio thread
- Lightweight VAD or energy gate: 2–5 ms
- Network hop or local inference first-token / final: whatever the model or API actually returns
- UI paint on a non-audio thread: <16 ms if you stay off the audio callback
Add them up and even a 35–45 ms TTFS model (the current public leaders on Coval-style harnesses) becomes 80–120 ms end-to-end before the overlay can show a stable partial. The MoE routing and the 1 M context window do not shrink the WASAPI period.
Exclusive mode can push the capture side under 5 ms, but it steals the endpoint. That is usually unacceptable when the user is on a Zoom/Teams/Google Meet call and still needs the system mixer for the other side of the conversation.
Dual streams, not one mixed beam
Interviews and support calls have two acoustic sources that must stay separate until after recognition (and usually after translation):
- Microphone (local speaker)
- Loopback of the render endpoint (remote speaker)
Early mixing forces the recognizer to solve diarization, language ID and two different noise floors in a single beam. Speaker-attributed transcripts and subsequent translation both degrade.
On Windows the loopback path is still “open the render device as a capture stream” through WASAPI. The production constraint is unchanged:
// Sketch only — real code also handles IMMNotificationClient
// device-change events and format renegotiation.
// The callback must stay allocation-free and non-blocking.
use cpal::traits::{DeviceTrait, HostTrait, StreamTrait};
fn open_loopback(host: &cpal::Host, render_name: &str) -> anyhow::Result<cpal::Stream> {
let device = host
.output_devices()?
.find(|d| d.name().ok().as_deref() == Some(render_name))
.ok_or_else(|| anyhow::anyhow!("render device not found"))?;
let config = device.default_output_config()?;
let stream = device.build_input_stream(
&config.into(),
|data: &[f32], _: &cpal::InputCallbackInfo| {
// push into lock-free ring; resample on consumer
},
|err| eprintln!("loopback: {err}"),
None,
)?;
stream.play()?;
Ok(stream)
}
Any mutex that the UI or network thread might hold, any allocation, or any system call inside that callback becomes glitches. A trillion-parameter model does not relax the real-time contract.
What the open weights actually change
For a tool that lets the user bring their own key or run a local model, the new checkpoint is useful in three concrete ways:
- Token efficiency on the agent side. If the same overlay also drives a local coding or note-taking agent (summarise the last 30 s, extract action items, draft a follow-up), 47 % fewer tokens means you can keep more context or run a larger active expert budget without saturating the GPU.
- Day-zero llama.cpp / vLLM support. You can quantise and serve it on the same machine that is already doing the audio capture, or on a small local box, without waiting for a proprietary API to add the model.
- License that permits local use. The Mistral Ecosystem Open-Weight License allows download and local inference; the restriction is on operating a public Model-as-a-Service. That matches the BYOK / local-model pattern most real-time call tools want.
None of those three points move the 10 ms WASAPI quantum or the need for two independent capture streams.
Partial vs final still dominates the overlay budget
Streaming APIs (and local streaming setups) emit non-final tokens while the speaker continues and finalise on pause. The number that matters for an interview overlay is the time from the end of a phrase until the text is stable enough to show or to feed a translator. Aggressive partials + a small look-ahead buffer in shared mode usually beat exclusive mode once you factor in the rest of the call stack.
If you are building the same kind of dual-track, low-latency Windows overlay, the new open weights are a welcome reduction in inference cost and an extra option in the model menu. They do not change the order of operations: capture first, keep the streams separate, stay off the audio callback, then let the model do its work.
I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.

Top comments (0)