Scaling Retell AI Concurrency: Handling 10,000 Concurrent Calls Without Dropping Audio

Retell’s own marketing states it directly: “one Retell agent can answer 10 or 10,000 calls simultaneously, capacity scales with API calls, not headcount.” Retell’s own concurrency documentation tells a more precise, more useful story underneath that claim: concurrency limits are real, enforced per workspace, and a standard pay-as-you-go workspace starts with a default quota of just 20 concurrent calls, a hard ceiling with no grace period until you explicitly configure otherwise.

Both things are true at once. The platform genuinely can handle 10,000 concurrent calls. It doesn’t do it by default, and treating “unlimited concurrency” as something that happens automatically is exactly how a scalable voice ai architecture project gets surprised by a concurrency_limit_reached error during the first real traffic spike. This article covers what Retell’s own documentation says actually has to be configured to hit real scale, and what the surrounding infrastructure, high concurrency voice streaming, media stream web sockets handling, and enterprise voice load balancing, needs to look like to support it. It’s the same pattern we’ve found throughout Retell’s own documentation: the marketed number is real, and the engineering required to reach it reliably is a separate, deliberate project.

What “10,000 Concurrent Calls” Actually Requires to Configure

Retell’s own documentation is specific about what concurrency actually means and how it’s controlled: it’s the number of simultaneous active voice calls your system handles at any given moment, quotas apply per workspace rather than per account, and each workspace has its own reserved inbound capacity and burst settings that traffic in a different workspace never touches.

The default pay-as-you-go quota of 20 concurrent calls is nowhere near 10,000, and getting from one to the other isn’t a matter of the platform scaling itself. It’s an explicit dashboard configuration change, adjusting the concurrency limit, and for higher-volume needs, a move to Enterprise, which is the tier where dedicated infrastructure and guaranteed capacity actually live. A scalable voice ai architecture built on Retell for real volume needs this planned as a deliberate infrastructure decision during setup, not discovered as a blocker during a launch.

High Concurrency Voice Streaming: The Separate CPS Limit Nobody Budgets For

Concurrency, how many calls are active at once, is only half of what Retell’s own documentation tracks. There’s a second, separate limit: Calls Per Second, or CPS, tracked independently for each telephony provider, Telnyx, Twilio, or a custom SIP connection, and this is exactly the kind of limit that gets missed by a team that only planned around the concurrency number.

A high concurrency voice streaming deployment can have plenty of concurrency headroom and still fail under a traffic spike if the CPS limit for the underlying telephony provider is set too low for how fast calls actually arrive in a burst, a marketing campaign landing, a service outage driving a surge of inbound calls, a batch outbound campaign firing all at once. Retell’s own documentation notes that Custom Telephony CPS scales with concurrency, meaning a higher CPS setting there may require a higher concurrency allocation to match, and provides a calculator that takes actual traffic inputs, calls per busy hour, average duration, pickup rate, and returns a recommended concurrency, inbound reservation, and CPS setting with headroom built in for spikes.

Media Stream WebSockets: Why Concurrency at Scale Is a Connection Management Problem

Every active call on a real-time voice platform corresponds to a persistent, open media stream web sockets connection streaming audio in both directions for the full duration of that call. At 10,000 concurrent calls, that’s 10,000 simultaneous, long-lived connections your infrastructure, and everything it talks to, STT, LLM, TTS, needs to hold open reliably at once, not 10,000 quick request-response cycles.

This is where audio quality actually starts degrading under load, and it’s rarely the AI model itself. It’s connection-level resource contention: a server running out of available connections, a downstream service that handles occasional bursts fine but chokes when thousands of persistent connections all need a response within the same tight latency window, or memory pressure from holding that many open sockets and their associated buffers simultaneously. A scalable voice ai architecture treats connection capacity, not just raw compute, as a first-class resource to plan and monitor, since a system can have plenty of CPU headroom and still drop audio the moment it runs out of available connection slots.

Enterprise Voice Load Balancing: Distributing 10,000 Calls Without a Single Point of Failure

At real scale, enterprise voice load balancing has to solve a problem that’s genuinely different from balancing stateless HTTP traffic. A voice call’s media stream web sockets connection is stateful and long-lived; you can’t simply route the next audio chunk from an in-progress call to a different backend instance the way you might route the next HTTP request to whichever server has capacity. Once a call is connected to a specific instance handling its STT, LLM, and TTS pipeline, that call generally needs to stay pinned to that instance for its duration.

That constraint shapes what load balancing actually has to do for voice specifically: distributing new incoming calls across available capacity intelligently at connection time, since that’s the one moment a routing decision can actually be made freely, then monitoring per-instance load continuously so a single overloaded node doesn’t silently degrade every call pinned to it. Combined with Retell’s own per-workspace concurrency and CPS controls, this is what actually turns a platform theoretically capable of 10,000 concurrent calls into a deployment that reliably delivers that capacity under real, bursty traffic rather than a smooth, unrealistic average.

What a Genuine Scalable Voice AI Architecture Requires

• Concurrency limits explicitly configured and tested against real projected traffic, not left at whatever default a platform ships with
• CPS limits set and validated separately from raw concurrency, since a burst of new calls can exceed CPS capacity even with concurrency headroom to spare
• Connection-level monitoring across the full pipeline, STT, LLM, TTS, and telephony, since audio degradation at scale is usually a connection or downstream service bottleneck, not a model quality problem
• Load balancing that accounts for the stateful, pinned nature of an active voice call, distributing intelligently at connection time rather than trying to rebalance mid-call
• Real traffic modeling, using actual calls-per-busy-hour and burst patterns, rather than an assumed smooth average that never matches how real call volume actually arrives

The Number on the Marketing Page Is Real. The Work to Reach It Isn’t Optional.

Retell’s own platform genuinely supports the scale its marketing describes, and the 10,000-call figure isn’t fabricated. What the marketing page compresses into one sentence, Retell’s own technical documentation spells out as a real configuration project: workspace-level concurrency limits raised deliberately, CPS tuned per telephony provider, and enough connection and load-balancing discipline underneath it all to actually hold that many simultaneous conversations without any one of them degrading. A scalable voice ai architecture is the sum of those specific, documented configuration decisions, not a property that shows up automatically because the platform’s homepage says it can.

Frequently asked questions

Does Retell AI actually support 10,000 concurrent calls by default?

No. Retell’s own documentation confirms pay-as-you-go workspaces start with a default quota of just 20 concurrent calls, a hard limit until explicitly raised. Reaching significantly higher concurrency requires deliberate configuration and, for large-scale needs, moving to Retell’s Enterprise tier, which provides dedicated infrastructure and guaranteed capacity- the foundation any real scalable voice ai architecture is actually built on.

What’s the difference between concurrency limits and CPS limits?

Concurrency measures how many calls are active simultaneously at any given moment. CPS, Calls Per Second, measures how quickly new calls can start, tracked separately per telephony provider. A deployment can have concurrency headroom to spare and still fail during a sudden burst of new calls if the CPS limit for its telephony provider is set too low for that burst.

Why does audio quality degrade under high concurrency even when the AI model itself is fine?

Because at scale, the bottleneck is usually connection-level resource contention, not model quality: a server running out of available WebSocket connections, a downstream service that handles moderate load fine but struggles under thousands of simultaneous persistent connections, or memory pressure from holding that many open sockets at once.

How is enterprise voice load balancing different from balancing regular web traffic?

A voice call’s connection is stateful and long-lived, generally pinned to one backend instance handling its STT, LLM, and TTS pipeline for the call’s full duration, unlike a stateless HTTP request that can be routed freely to any available server. Voice load balancing has to make its distribution decision primarily at connection time, then monitor per-instance load continuously rather than rebalancing mid-call.

How should a team actually plan concurrency and CPS settings before a launch?

Using real projected traffic data, calls per busy hour, average call duration, and expected pickup rate, rather than an assumed smooth average. Retell’s own concurrency documentation provides a calculator that takes these inputs and returns a recommended concurrency, inbound reservation, and CPS setting with headroom built in for realistic traffic spikes.

Bhavesh Modi

Project Manager – AI