# Voice In, Visuals Out: The Agony and the Ecstasy - Allen Pike, Forestwalk Labs AI Engineer · 2026-06-28 Allen Pike, co-founder of Forestwalk Labs, argues that voice is the preferred input for AI but visuals are the preferred output, as Andrej Karpathy recently claimed. He explains that while voice-in, voice-out requires sub-200ms latency for seamless conversation, voice-in, visuals-out can work within a more forgiving one-second response envelope. Pike shares three techniques his team uses to achieve this: using a fast model like Haiku with low p95 latency, sending inference every one to two seconds as the user speaks rather than waiting for silence, and leveraging stable prefix caching to keep the first 90% of the context identical, reducing cost and latency. He illustrates with a real example where a voice agent filed a Linear issue in under a second during a team call, demonstrating how the approach creates a natural, non-interruptive experience. ## Questions this episode answers ### What latency constraints make real-time voice AI challenging, and how can visual output help? Allen Pike explains that a seamless voice conversation requires under 200 milliseconds of latency—far tighter than the 100–1000 ms tolerated for visual reactions. Voice-in, voice-out systems struggle with network and model delays that make hitting 200 ms nearly impossible. By switching to voice-in, visuals-out, developers can deliver responses within a second, satisfying the visual attention span and avoiding the extreme latency demands of voice output. [5:22](https://aie.addtry.com/41f14c84-39a2-44a4-920d-abd64d3add5b?t=322000) ### What three techniques does Allen Pike recommend for achieving low-latency voice-in, visuals-out AI? Pike advises: 1) use a fast model like Anthropic’s Haiku, which offers low p95 latency (versus GPT‑5 mini’s 5,000–10,000 ms p95), and asynchronously hand off complex tasks to a larger model; 2) trigger inference every 1–2 seconds while the user speaks, rather than waiting for silence; 3) rely on prefix caching, keeping the first ~90% of the context window identical per request, enabling up to 90% faster, cheaper inference. [8:31](https://aie.addtry.com/41f14c84-39a2-44a4-920d-abd64d3add5b?t=511000) ### How did Allen Pike’s team use a voice agent to file a bug report during a call? During a call, Pike mentioned a bug in a Slack integration to his co-founder, who confirmed it. Pike then said, “Okay, well, let’s file that as a linear issue,” and the team’s real-time voice agent reacted within a second, confirming it had created the Linear ticket. This illustrates how a well‑tuned voice‑in, visuals‑out system can unobtrusively take action based on natural conversation. [4:09](https://aie.addtry.com/41f14c84-39a2-44a4-920d-abd64d3add5b?t=249000) ## Key moments - **[0:00] Intro** - **[0:37] Karpathy's Argument** - [0:37] Andrej Karpathy argues voice is the human-preferred input for AI, but visuals are preferred output. - **[1:12] Visuals Out** - **[2:15] Voice In** - [3:02] "The models that we have so far, the experiences that most people have seen, are both slow and dumb." - [4:30] Allen Pike's voice agent files a Linear issue within a second during a call at Forestwalk. - **[5:22] Tyranny of Latency** - **[7:48] Workaround** - [7:48] Visual output's 1-second latency envelope is more forgiving than the 200ms needed for seamless voice conversation. - **[8:47] Fast Model** - [8:47] GPT-5 mini's p95 latency of 5,000–10,000ms is too slow for real-time; Haiku-class models are required. - **[10:36] Eager Inference** - [10:36] Sending inference every 1–2 seconds while the user speaks creates seamless responsiveness. - **[11:38] Prefix Caching** - [12:02] Prefix caching the first 90% of context yields up to 90% cheaper, faster inference. - **[12:37] Outro** ## Speakers - **Allen Pike** (guest) ## Topics Voice Agents ## Mentioned Forestwalk (company), ChatGPT (product), Haiku (product), Linear (product), Siri (product), Slack (product) ## Transcript ### Intro **Allen Pike** [0:01] Allright, I'm Allen Pike, and today I'm going to be sharing some of what we've learned building Voice In, Visuals Out experiences using AI. Here we go. So this is Andrej Karpathy, and he made an argument last month that voice is the human-preferred input for AIs, but that we prefer visuals as the output. And he knows a thing or two about this stuff, but that's not how we have been, for the most part, building or using AI. We've been typing to it, it's been typing back, maybe with some markdown. But there's been breakthroughs over the last few months where both this Visuals In and Audio—or the Audio In and Visuals Out experience—is now really feasible, and we can create really delightful experiences with it. ### Visuals Out **Allen Pike** [1:12] The visuals outside is pretty intuitive,right? Of course, a third of our brain is dedicated to processing visual information; we love looking at things. And models have recently got to the point where they can generate rich HTML, tool calling, so we can have these experiences where there's visualizations that come back, explain things, help us understand, communicate the responses from these models. They can give us interactive controls that allow us to explore and understand and modify and change and direct the models. And they can even respond with beautiful illustrations and images,right? And so the ceiling on the visuals out piece has really lifted, and we have a lot more capability of what we can do in terms of responding from these models. ### Voice In **Allen Pike** [2:15] The more controversial half of Karpathy's argument, though, is this idea of voice as the preferred input. We've long sort of idealized and fantasized about speaking to an AI and having this real-time conversation where it understands what we need and it reacts appropriately in real time. But the experiences that most people have had so far with voice interfaces have been more like trying to get Siri to turn the lights on and it's not working, or like this guy that is trying to get ChatGPT voice mode to do things but it keeps being awkward and confused,right? The models that we have so far, the experiences that most people have seen, are both slow and dumb, which is not a great combination. And so a lot of people are down on voice as an input. But speaking is the ultimate way that, as humans, we communicate. When we're speaking, we have more words per minute than when we're typing, but we also convey more with each word. There's a huge difference in between if you say to me, "Okay," versus if you say, "Okay." And that's why when we have something that is really important that we need to communicate or get through to somebody, we will jump on a call and we will—or we'll speak in person—so that we can get through that high-bandwidth communication. And so what we've done at Forestwalk is we have built an agent that is in our calls that can help us out in real time. And so the other day I mentioned to my co-founder on a call that I'd seen a bug with this Slack integration, or at least I thought I had. And she responded that she had seen the same bug. And so I just said, "Okay, well, let's file that as a linear issue," and the voice agent within a second responded that it had done so. And that feels perfectly natural when you get it really dialed in, that you are speaking either incidentally or with a purpose, intentionally speaking to the AI, and it responds in a way that is not interruptive of you. It doesn't need to be voice; it is just taking action on your intent. And so we're going to see this experience more and more in the coming months and years, but there's a huge barrier, a huge challenge to making this actually work and feel good. ### Tyranny of Latency **Allen Pike** [5:22] And that is the tyranny of latency. It's really difficult to get a response through that whole chain fast enough. We've known since the '60s that to have a computer react to us fast enough that it feels instant, it needs to react in about 100 milliseconds, a tenth of a second. And so, of course, we are always aspiring to get our products to react that fast, and sometimes we can achieve that, but with networking and everything, it can be challenging depending on what work needs to get done. And so sometimes we might flex up to 1,000 milliseconds,right? You get a full second. It's about the limit before people start to lose their train of thought. They ask a computer to do something, takes more than a second, we're off to something else mentally,right? And so we're always in that play in between those two kind of human limits of trying to respond within a second, ideally within 100 milliseconds. But if we want to have a seamless voice conversation with an AI or another human, the limit is much more aggressive. We need to have a 200-millisecond latency or less if we want to have a fully conversive. People are verbalizing something and they are interrupting or interjecting or agreeing and forming that sort of connection, full voice in, voice out conversation. And so imagine trying to do that where you have a network request, maybe you turn speech to text, and then you do some sort of model inference on that text and then send it back on the network. It's like a ridiculous amount of work to do in 200 milliseconds. There are some clever approaches of trying to work around that. The Thinking Machines in NeoLab has a really thoughtful architecture where they were demoing recently, just a few weeks ago, they've time-sliced into 200-millisecond chunks, like that 200-millisecond goal, and have a model that's doing continuous inference in and out on 200-millisecond slices. So there are ways around it for voice in, voice out, but there's also just we don't need to wait for novel architectures. We can just switch to having voice in, visuals out, and then we benefit from the more forgiving visual response envelope that people have. ### Workaround **Allen Pike** [8:09] That if you have something that appears on screen within a second of what you've said, it feels like it has met that. It's within your attention span. It's reacting to you in a way that feels seamless. And so we've been building for that over the last few months, and it's a lot of fun, and we've learned a lot doing that. And so I want to finish up just by sharing three of the things that we found to be really important for getting within that latency envelope and making the experience feel really delightful for people who are using it. ### Fast Model **Allen Pike** [8:47] So the first one is that in order to respond in a way that feels seamless, you have to use a really fast model. So that's not just a model that is so small that it can respond fast enough in a few hundred milliseconds, though of course it does need to be, but it also has to be on an inference platform that prioritizes latency. So when GPT-5 mini came out, we were excited that, okay, well, yeah, we get this more intelligent model and presumably it'll be fast, but then in practice we are seeing latencies of 5,000 milliseconds, 7,000, p95 sometimes 10,000 millisecond latency for this small model. It was cheaper than the bigger model, but we weren't consistently or ever seeing it respond fast enough. Haiku is much better in terms of that p95 latency. So you really need kind of a haiku-class model as the one that's responding in this real time or one of the smaller open-source ones. And then if there is a larger chunk of work that needs to get done, then that model then hands off or sends off an asynchronous message to a larger model that can think, and then the continuous real-time model or soft real-time model that's responding quickly then can interleave in those responses if it's doing something heavier. So that's number one, you need to have a fast model, obviously with a short enough context that you're providing it that it can respond in a few hundred milliseconds. The second thing that's really critical if we're going to have this feeling of it being really responsive is to have short intervals of how quickly we're sending out for inference. And so traditionally for a voice application you might listen to the user for a few seconds and then they stop, you listen for a second of silence, and then you have some sort of inference goes on, and then you've blown your budget by a pretty wide margin just for waiting for silence. ### Eager Inference **Allen Pike** [10:55] So if we're going to have something up on screen within a second, then when we want to have our inference pretty eagerly responding as the person is talking, even if we're not entirely sure they've stopped talking, being willing to send inference every one or two seconds as they speak, because we sometimes have a sentence where we ask, "Oh, hey, we're going to want to change this and actually also listen to this other thing," it feels much more seamless if you're doing those things as people talk. So you have to have a model and an infrastructure where you're able to get these fast turns going. And then finally, in order to actually make all of that work, you need to have a stable caching regimen. So we have this huge improvement in the way that we work with LLMs over the last year where we have on the different platforms different ideas of this prefix caching where if the beginning of the context you send to the model is the same each time, then you can get up to 90% cheaper, faster inference depending on the conditions. ### Prefix Caching **Allen Pike** [12:02] And so you need to lean heavily into this architecture really. I think for most applications we're moving towards this, whether it's like a long-running agent or it's a frequently running agent, it's the same principle applies that we want the first 90% of the context window if we can to be the same from request to request, and then just use that final 10%, and then also, of course, minimize the number of output tokens so that you can get these really fast and relatively affordable inference turns to create that delightful experience. So these are some of the techniques we've found really useful. I would love to hear from anybody who has been exploring and experimenting, whether it's with real-time or any way that people are pushing the boundaries of creating delightful experiences with these models. ### Outro **Allen Pike** [12:55] I'd love to share what we've been learning, and I hope some of this inspires some of you to go out and build something great. Thanks. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.