Voice AI Hit $500M ARR. Dead Air Isn't Fixed

ElevenLabs confirmed this year it crossed $500 million in annual recurring revenue, up from roughly $330 million at the end of 2025 — four months to add $170 million, almost entirely on the back of enterprise contracts with companies like Deutsche Telekom, Revolut, and Klarna putting voice AI in front of real customers at real scale. In the same window, OpenAI shipped GPT-Realtime-2, a native speech-to-speech model built specifically to kill what it calls the dead-air problem: the awkward multi-second silence that happens while a voice agent is calling a tool, checking a database, or figuring out what to say next, and that makes every caller either hang up or start talking over the agent. Two headlines, same week, same underlying story: voice AI just became something enterprises trust with production call volume. The dead-air fix is real. It's also only half the problem, and it's the half OpenAI controls.

What GPT-Realtime-2 Actually Fixed

The old failure mode was structural. Most voice AI stacks were pipelines: speech-to-text, then a language model, then text-to-speech, each step adding latency and each handoff a place for silence to creep in. Ask the agent to check an order status and update a delivery date, and you'd get three seconds of nothing while it called two separate tools in sequence, because nothing in the pipeline was designed to talk while it worked. GPT-Realtime-2 is a native speech-to-speech model that can call multiple tools at once and narrate what it's doing while it does — so instead of silence during a multi-step task, the caller hears something closer to a human thinking out loud. OpenAI's own benchmarks put natural-feeling response time at around 600 milliseconds, with anything past 800 milliseconds starting to feel like the system is stuck. That's a genuine architectural improvement, and it's the reason enterprises are suddenly comfortable routing real call volume through voice AI instead of keeping it in a bundled-feature pilot.

Why Most Deployments Won't Feel the Fix

A faster, chattier base model doesn't automatically make your voice agent faster. It makes the model's own thinking faster. Everything the model has to wait on before it can speak — your CRM lookup, your scheduling system, your payment processor, your knowledge base retrieval — still runs at whatever speed your integration was built to run at, and none of OpenAI's latency work touches a single millisecond of that. A business that swaps in GPT-Realtime-2 but keeps a three-second database round-trip behind every tool call has traded one kind of dead air — the model thinking — for another kind that's arguably worse, because now the model has started narrating and then gone quiet mid-sentence waiting on your backend instead of its own reasoning.

• Backend and CRM lookups that were never load-tested for voice-speed response times, only for the slower tolerance of a web form
• Fallback logic that routes to dead air or hold music instead of a spoken acknowledgment the moment a tool call is going to take more than a beat
• Knowledge base retrieval that re-runs a full search on every turn instead of caching what the call has already established
• No monitoring that isolates hang-ups and interruptions caused specifically by silence gaps, as opposed to the caller simply getting what they needed
• A pilot that was benchmarked once at launch and never re-tested against real call volume, real network conditions, or a real backend under load

A Realistic Scenario

A Wizeb client running a voice AI line for appointment scheduling at a multi-location dental group had already adopted a newer real-time model, expecting the latency complaints in their call transcripts to disappear. They didn't. Callers were still hanging up mid-call at almost the same rate as before the upgrade. The model's own response time had improved exactly as advertised — the problem was everything downstream of it. Checking appointment availability meant a synchronous call to a practice-management system that averaged 2.4 seconds per lookup, with no caching and no spoken filler while it ran, so the agent would start a sentence, go silent for over two seconds, and then finish it — which felt more broken than a slower but consistent agent would have. We added a cached availability layer refreshed every 60 seconds instead of queried live per call, wired in short spoken acknowledgments for any lookup projected to take over 700 milliseconds, and set up call-level monitoring that flagged silence gaps over one second as their own tracked event, separate from general call abandonment. Hang-ups during the scheduling step dropped 44% in three weeks, with no change to the underlying voice model at all.

How Wizeb Approaches This

When Wizeb builds or audits a voice AI deployment, we treat the model's response time and your integration's response time as two separate budgets that both have to hold, not one number that gets better because the vendor shipped a new model. That means load-testing every backend call the agent depends on at actual call volume, building spoken acknowledgments for any lookup that can't be made instant, caching what's safe to cache instead of hitting a live system on every turn, and instrumenting calls to isolate silence-caused hang-ups from every other reason a caller leaves. A faster foundation model is a real gift if the rest of the stack is built to use it — and an invisible upgrade, or worse, if it isn't. Start at wizeb.com/services/voice-ai.

Three Questions Before You Upgrade the Model and Call It Fixed

1. 1Have you load-tested every backend call your voice agent depends on at real call volume, or only benchmarked the model itself?
2. 2Do you track silence-caused hang-ups as their own metric, separate from general call abandonment — or would you actually know the difference today?
3. 3If a lookup is going to take more than 700 milliseconds, does your agent say something while it waits, or just go quiet?