Real-time answers
A thinking pause has about four seconds in it before it becomes the thing everyone is noticing. That budget is the whole engineering constraint, and most of what follows exists because the first version of this product missed it.
The budget
Measured end to end, from the interviewer's last syllable to your first visible word.
| Stage | What has to happen | Roughly |
|---|---|---|
| End of turn | Deciding the interviewer has actually stopped, not just paused mid-sentence. | A few hundred milliseconds |
| Classify | Was that a question, and is it one ask or two. Runs locally, costs nothing. | Single-digit milliseconds |
| Assemble | Pull the CV, the job description and the matching passages; build the prompt. | Tens of milliseconds |
| First token | The model reads the prompt and writes the first word. The dominant cost. | Most of the budget |
| Display | Stream it onto the screen as it is written rather than when it is finished. | Continuous |
Everything before the model is small. Which means every improvement that matters is about the model — which one, what it is asked to do, and whether it is warm.
What it took
Our own measured median began at just under six seconds, which is unusable. It is now about one and a half.
A live answer uses a fast model, not the largest one available. The largest one is still there for the questions that deserve it — it is just not the default, because defaulting to it taxes every easy question with the cost of a hard one.
Extended reasoning makes a hard answer better and a conversational answer slower. It is switched off on the fast tier and on for the advanced one, rather than being left on everywhere because it sounds better.
Tokens are forwarded to your screen as they arrive instead of being collected and sent in one block. Same total time; a first sentence at a second and a half instead of at four.
The first request to a cold path pays for connections and initialisation. That is paid before the interview starts, so the first real question is not the one that is slowest.
Checking who you are and loading the session used to happen one after the other. They have nothing to do with each other, so they now happen at once.
Choosing the trade
A live interview is not one kind of question, so one setting for all of them is the wrong shape.
| Tier | Good for | Cost |
|---|---|---|
| Fast | The live back-and-forth: behavioural questions, your own experience, follow-ups. | 1 credit |
| Balanced | Technical depth where an extra second is affordable. | 1 credit |
| Advanced | System design, a tricky algorithm, anything where you would rather wait and be right. | 3 credits |
Set per session and changeable mid-call. A screenshot of a coding problem is its own case — more to read, so more to pay for and a little longer to answer.
What speed does not fix
Three failures cost more than a slow answer, and each has its own answer.
Answers fall back across models and companies. If the first cannot answer, the next does, and you are charged once.
The session waits five minutes. Reopen it in the same tab, a new one or the Windows app, and it continues with the credits already held.
Starting a session holds enough credits for a full interview, so it cannot stop part way. What is not used comes back when it ends.
Questions
On our own test rig — a scripted interview that asks three questions in sequence against a locally hosted stack — the median time from the end of a question to the first visible word is about one and a half seconds, and every answer after the first starts inside three. That test runs as part of the suite, so the claim fails loudly if it stops being true. On the open internet your own latency to the provider is added to that.
Because that is roughly how long a thinking pause can run in a conversation before it becomes the thing both people are noticing. Inside it, a pause reads as consideration. Past it, you are visibly waiting for something, and an answer that arrives then has already cost you more than it gives.
It means a different trade, and the trade should be yours to make. A fast model answers a behavioural question as well as a slow one and is noticeably weaker on a hard system design question. So there are three tiers: a fast one for the live back-and-forth, a balanced one, and an advanced one that thinks harder for the questions worth waiting for.
The answer is displayed as it is written rather than when it is finished. That turns one four-second wait into a first sentence at one and a half seconds and the rest arriving while you are already speaking — which is the difference between usable and not, even though the total time is the same.
The next provider answers, and you are charged once. An answer that fails everywhere is not charged for. An interview is the worst possible moment to discover that one company's API is having an afternoon.
The answer itself takes the same time, because the same server writes it. What is faster is getting the question to it: the app hears the call directly and transcribes on your own PC, so nothing waits on a shared browser tab or a round trip for the audio.
Read next
Set up a session, ask it something out loud, and watch where the first word lands.
Create your account