The only metric that matters
We measure end-of-speech to first visible token: the gap between the interviewer finishing their question and the first word appearing on your overlay. On normal broadband, that is roughly 600ms.
Not average response time. Not tokens per second. The gap where you are sitting in silence, because that is the gap the interviewer notices.
How the pipeline gets there
Audio is captured directly from the meeting process, converted to 16kHz mono, and streamed to a speech-to-text engine over a persistent websocket. There is no record-then-upload step, so transcription is already nearly complete when the interviewer stops talking.
The transcript streams straight into a streaming language model. We start rendering the first token the moment it arrives rather than waiting for a complete response, which removes the largest single source of perceived delay.
The client holds a short-lived credential and talks to the transcription service directly, so audio does not make an extra round trip through our servers on its way out.
Answers are capped and structured — bullets first, detail after. A shorter answer starts sooner and is easier to glance at, which is the same goal from two directions.
Native, because the audio path is shorter
Lexora is a compiled Rust binary, not an Electron wrapper or a browser extension. That matters for audio: a system-level process tap gets the interviewer's voice directly from the meeting app, with no echo from your speakers and no dependency on browser tab-audio permissions.
It also means lower memory use during a call, and nothing sitting in your browser's extension list.