← Blog·engineeringuxvoice

What 'sub-second voice' actually feels like

Engineering / 02

If you have ever held a walkie-talkie, you already understand the problem. The half-second delay between saying something and being heard is small enough to ignore on paper and large enough to break the conversation. You start talking over the other person. You compress your thoughts into sentences shaped like bullets. It’s efficient and it is not a real conversation.

The entire first generation of “voice AI” products was built on walkie-talkie time. You tapped a button, spoke into the phone, waited for three long seconds while a progress bar pretended to be thinking, and then a polite British woman read you the answer. That is not voice. That is chat with a fancier hat.

The 800-millisecond cliff

Humans in normal conversation turn-take with astonishing precision. The median gap between the end of your sentence and the start of mine is around 200 milliseconds. A gap longer than about 800 ms feels wrong. It doesn’t feel like thinking. It feels like disconnection, bad signal, disinterest.

There is real research on this from conversation analysts—Tanya Stivers’ cross-linguistic work is the canonical reference—but you already know it in your body. Imagine asking a friend how their weekend was. If they pause for one full second before answering, you’ll notice, and you’ll feel it. One second is the cliff.

Every voice product that lives above the cliff gets used like a voice-memo app. Every product that lives below it gets used like a person. That is the whole game.

“Every voice product above the cliff gets used like a voicemail app. Every product below it gets used like a person.”

Chat-with-TTS vs. real voice-to-voice

The cheap way to ship voice is a pipeline that looks like this: speech-to-text, then LLM, then text-to-speech, glued together with two or three round-trips across the internet. Each stage waits for the previous one to finish before starting. The user waits for all three. On a good day, you land somewhere between 2.4 and 3.8 seconds. On a bad day, your companion sounds like it’s calling from the moon.

Real voice-to-voice looks different. The audio stream is never fully “finalized” before the model starts thinking. Partial transcripts flow into the model as you speak. The model starts generating a response before you have stopped talking, and revises if you surprise it. The audio is streamed back a chunk at a time—often the first syllable is playing in your ears while the rest of the sentence is still being planned.

It is a mildly unreasonable way to build software, and it is the reason a modern companion can reply in under a second. The user never sees the seams. They just notice that the thing feels alive.

What disappears when latency does

Watch a new user try a sub-second system for the first time. The first minute is always the same. They ask a question with the slightly stiff cadence of someone talking to Siri—clear, loud, over-articulated. The answer comes back instantly. Their face changes. The second question is conversational. By minute three, they are laughing, interrupting, trailing off, using sentence fragments, doing all the things humans do with each other.

The stiffness is not a personality trait. It is a protocol users learn for dealing with slow machines. When the machine stops being slow, they drop the protocol in about forty-five seconds.

A few things that become possible under a second

  • Interrupting. You can cut the companion off mid-sentence with a “wait, actually—” the way you would with a friend. Above the cliff, interruption just creates a garbled mess.
  • Thinking out loud. You can say “so the thing is, I guess, I’m not sure, but maybe…” and have the companion wait through the hesitations instead of trying to answer three different half-sentences.
  • Silence. A sub-second system can afford to be quiet. Because the delay isn’t spent loading, pauses register as thoughtfulness instead of buffering.
  • Laughing. Seriously. Humor is a latency-bound art form. A joke landed 2.5 seconds late is not a joke.

The hidden costs of fast

None of this is free. Streaming architectures are harder to debug, harder to scale, and harder to reason about than their synchronous cousins. You trade predictable failure modes for unpredictable ones. Your partial transcripts will occasionally misfire and the model will respond to something the user never said. You need recovery flows that feel graceful, not apologetic.

There is also an engineering tax on the model itself. To respond under a second, you often have to pick a smaller or more aggressively tuned model than the state of the art. This is why the fastest voice systems in 2026 are not always the smartest on any given benchmark. In conversation, though, being present beats being brilliant. A perfect answer at T+3s lands worse than a good answer at T+0.6s, almost every time.

The product bet

Our bet at TwoPeas is that latency is a feature in the same way that a well-tuned piano is a feature. It is not the song. It is the precondition for the song being playable at all. Everything else we build—memory, Live2D expressions, personality, voice variety—assumes the conversation is already happening at the speed of human talking.

When we test a build internally, we don’t ask “was the answer good.” We ask, “did you forget, at any point, that you were talking to software.” Sub-second voice is the only reliable way we’ve found to earn that forgetting. And the forgetting is the whole point. That’s what a companion is for.

The simple test, if you’re shopping

Try this with any voice AI you’re evaluating: ask a short question, interrupt the answer halfway through, and say “no, actually, different question.” If it handles the interruption smoothly—stops talking within 150 ms, gracefully listens, responds to the new question under a second—you are in the right decade. If it keeps reading the old answer, or stalls, or starts over from the top, you are talking to a chatbot with a voice costume. They are not the same species.