OpenAI emits typed events like response.output_text.delta and response.output_audio.delta. Learn the API pattern behind responsive LLM UX. Read now.
Why typed events beat raw token dumps
Real-time LLM interfaces feel responsive when the client can react as soon as the model produces something useful—not when the full response is finished. A bare byte stream forces every consumer to invent its own framing: where a text chunk ends, whether audio arrived, whether a tool call started, or whether the stream failed mid-flight. Typed events reverse that burden. The server emits discrete messages with stable names and payloads, so the client dispatches on event type instead of parsing an ambiguous blob.
Names like response.output_text.delta and response.output_audio.delta encode both the domain object and the kind of change. Text deltas update a running string; audio deltas append media fragments. The same response may interleave both. With explicit types, UI code can route text into a transcript view and audio into a player without guessing from MIME types or order alone.
The core API pattern
An event-driven streaming API usually has three layers. First, a connection opens for a single response (or a short-lived session). Second, the server pushes events as state changes: lifecycle markers (started, completed, failed), content deltas, and optional side channels such as reasoning traces or tool invocations. Third, the client maintains local state and applies each event as a pure update—append text, queue audio, flip a status flag—rather than re-fetching the whole response.
Design the client as a small reducer: given current UI state and an event, produce the next state. That keeps rendering predictable when events arrive out of visual order or when the user cancels mid-stream. Prefer idempotent application where possible (e.g., track sequence ids or append-only buffers) so reconnects and retries do not double-write content.
Building responsive UX on top of deltas
Text deltas should paint immediately, with cursor or skeleton feedback until a terminal event arrives. Audio deltas need buffering strategy: play as soon as a minimum buffer fills, or wait for a short initial segment so the first words are not choppy. Because text and audio may stream in parallel, sync them with shared timeline or turn ids rather than wall-clock arrival order.
- Map each event type to one UI handler; avoid a single catch-all parser.
- Show partial progress (typing indicator, waveform) only while non-terminal events continue.
- On error or cancel events, freeze partial output and surface a clear recovery action.
- Keep accessibility in mind: live regions for text, captions or transcripts when audio is primary.
Latency to first meaningful paint matters more than total generation time. Emitting small, frequent deltas improves perceived speed, but tiny fragments increase event overhead. Balance chunk size so the UI updates often enough to feel live without thrashing the main thread.
Implementation tradeoffs and practical guidance
Typed event streams add contract surface: clients must handle new event names gracefully (ignore unknown types, log them, or degrade). Version the event schema carefully and document which fields are optional on partial events. On the wire, JSON lines or similar framed messages are easier to debug than opaque binary frames, at some cost in size; compress at the transport layer if payload bulk becomes an issue.
Server-side, emit lifecycle events even when no content was produced, so clients can exit loading states cleanly. Client-side, treat the stream as the source of truth until a final “completed” event, then optionally reconcile with a stored snapshot if your product needs durable history. The pattern is not limited to one vendor’s naming: any API that separates what changed from raw bytes can deliver the same responsive LLM UX—typed deltas for text and audio are simply a clear, workable instance of that idea.