A quote from Luke Curley
TL;DR · AI Summary
Luke Curley criticizes WebRTC's aggressive packet dropping in poor networks, which harms voice input quality—users prefer waiting 200ms for accuracy over real-time but distorted audio.
Key Takeaways
- WebRTC drops audio packets aggressively to maintain latency under 100ms
- Users prefer waiting 200ms for accurate LLM responses over real-time distortion
- Browser-level WebRTC packet retransmission is impossible due to hardcoded design
Outline
Jump quickly between sections.
The article quotes Luke Curley criticizing WebRTC's design trade-off between latency and audio quality.
WebRTC drops audio packets to ensure low latency, preventing interruptions in real-time calls.
Users would rather wait 200ms for accurate LLM prompts than accept distorted audio from real-time transmission.
Retransmitting WebRTC audio packets in browsers is impossible because the implementation enforces 'real-time or fail' behavior.
Mindmap
See how the topics connect at a glance.
查看大纲文本（无障碍 / 无 JS 友好）
- WebRTC语音AI问题
- 设计哲学
- 优先低延迟（<100ms）
- 容忍音质损失
- 用户需求冲突
- 愿等200ms换准确LLM响应
- 当前体验差：垃圾提示=垃圾输出
- 技术障碍
- 浏览器不支持重传
- 实现硬编码为实时或失败
Highlights
Key sentences worth saving and sharing.
WebRTC aggressively drops audio packets to keep latency low. If you’ve ever heard distorted audio on a conference call, that’s WebRTC baybee.
I would much rather wait an extra 200ms for my slow/expensive prompt to be accurate. After all, I’m paying good money to boil the ocean, and a garbage prompt means a garbage response.
It’s impossible to even retransmit a WebRTC audio packet within a browser; we tried at Discord. The implementation is hard-coded for real-time latency or else.
A quote from Luke Curley
[Simon Willison’s Weblog](https://simonwillison.net/)
Sponsored by:WorkOS — Make your app Enterprise Ready with SSO, SCIM, RBAC, and more.
9th May 2026
WebRTC is designed to degrade and drop my prompt during poor network conditions.
wtf my dude
WebRTC aggressively drops audio packets to keep latency low. If you’ve ever heard distorted audio on a conference call, that’s WebRTC baybee. The idea is that conference calls depend on rapid back-and-forth, so pausing to wait for audio is unacceptable.
…but as a user, I would much rather wait an extra 200ms for my slow/expensive prompt to be accurate. After all, I’m paying good money to boil the ocean, and a garbage prompt means a garbage response. It’s not like LLMs are particularly responsive anyway.
But I’m not allowed to wait. It’s _impossible_ to even retransmit a WebRTC audio packet within a browser; we tried at Discord. The _implementation_ is hard-coded for real-time latency or else.
— Luke Curley, OpenAI’s WebRTC Problem, in response to How OpenAI delivers low-latency voice AI at scale
Posted 9th May 2026 at 1:03 am
Recent articles
- Notes on the xAI/Anthropic data center deal - 7th May 2026
- Live blog: Code w/ Claude 2026 - 6th May 2026
- Vibe coding and agentic engineering are getting closer than I'd like - 6th May 2026
This is a quotation collected by Simon Willison, posted on 9th May 2026.