Text-to-Speech APIs
LMNT vs ElevenLabs: how do concurrency limits, rate limits, and load testing compare for a production voice agent?
6 min read
Most teams discover concurrency and rate limits the hard way—during a live traffic spike, a demo with an exec, or a launch event where the voice agent suddenly starts dropping calls. If you’re deciding between LMNT and ElevenLabs for a production voice agent, you’re really choosing how your system behaves under load, not just how good a single voice sounds in isolation.
Quick Answer: LMNT is built to run production voice agents without getting throttled—there are no concurrency or rate limits, so you can load test and scale without hitting a hidden ceiling. ElevenLabs offers strong voices but enforces API limits and concurrency constraints that you need to architect around, especially for real‑time, multi-session agents and games.
Why This Matters
For a production voice agent, concurrency, rate limits, and load testing aren’t ops details—they define your product’s ceiling. They determine whether you can handle:
- 1,000 simultaneous users in a game event,
- a bursty day in customer support,
- or classroom-scale usage for an AI tutor.
If your TTS provider starts returning 429s, adds jitter at high QPS, or quietly throttles streaming sessions, the agent experience breaks: delayed turn-taking, clipped speech, and dropped conversations. Choosing between LMNT and ElevenLabs on concurrency and rate limits is really choosing how safe you are to grow.
Key Benefits:
- Predictable scaling: LMNT’s “no concurrency or rate limits” model lets you design for business-level throughput, not vendor-enforced ceilings.
- Real load testing: You can safely run stress tests, soak tests, and failover drills against LMNT before you launch, instead of guessing how it behaves at scale.
- Lower integration risk: With fewer hidden limits, your architecture stays simpler—fewer queues, retries, and complex throttling logic to work around the TTS provider.
Core Concepts & Key Points
| Concept | Definition | Why it's important |
|---|---|---|
| Concurrency limits | The maximum number of simultaneous requests or active streams a provider allows at once. | Caps how many users your agent can serve in real time before calls get queued, rejected, or degraded. |
| Rate limits (QPS/RPM) | The number of requests or tokens you can send per second or minute without being throttled. | Controls how bursty your traffic can be—crucial during spikes (campaigns, events, classroom start times). |
| Load testing | Systematic stress, spike, and soak tests that simulate real usage at scale before launch. | The only safe way to verify latency, stability, and error behavior for your agent before real users hit it. |
How It Works (Step-by-Step)
The decision between LMNT and ElevenLabs for production agents usually follows this path:
-
Define your concurrency envelope
- Estimate peak simultaneous users and sessions: calls, chats, or game clients.
- Break it down: active speaking time vs idle, messages per minute, and expected burst size (e.g., “300 classrooms starting at the top of the hour”).
- Translate that into voice workloads: concurrent streaming connections, characters/second, and per-region traffic.
-
Map provider constraints onto your architecture
- With LMNT, you start from a simple assumption: no concurrency or rate limits and 150–200ms low-latency streaming that’s already being used in production by teams like Khan Academy, HeyGen, Vapi, Vercel, and Unity.
- With providers that enforce strict concurrency or QPS caps (like ElevenLabs), you typically add:
- request queues,
- backoff/retry handling,
- multiple API keys or accounts to increase limits,
- and defensive logic in your orchestrator to avoid hitting 429s or hard throttles.
-
Run targeted load tests before launch
- Try LMNT in the free Playground to dial in voice quality, languages (24 of them, including mid-sentence code-switching), and cloning (5-second recordings) for your agent.
- Move to the Developer API and spin up a load test that simulates your real traffic:
- For agents and support: lots of short, frequent turns.
- For games: many concurrent users, each streaming intermittently.
- With LMNT’s “no concurrency or rate limits” positioning and “we’ll scale with you” assurance, you can progressively raise load until you match or exceed your real peak scenarios, without negotiating temporary caps just to run the test.
Common Mistakes to Avoid
-
Ignoring limits until after launch:
Teams often start with great-sounding voices in a small dev environment and only check concurrency and rate limits when they start seeing 429 errors in staging—by then, your architecture is already committed.
How to avoid it: Treat concurrency and rate limits as first-class requirements. Evaluate vendor policies in parallel with voice quality and latency before you write integration code. -
Load testing against unrealistic patterns:
It’s easy to test “one user hammering the API” and miss how the system behaves with hundreds of short-lived sessions.
How to avoid it: Design tests around your actual usage shape—lots of concurrent, low-latency turns for conversational agents, and bursty join/leave patterns for games and tutors.
Real-World Example
Imagine you’re building a real-time voice agent for a language learning platform. A typical Monday morning looks like this:
- 2,000 active students globally
- 300–500 concurrent 1:1 lessons at peak
- Each lesson: short back-and-forth turns every 3–5 seconds
- Students are distributed across languages (English, Spanish, French, etc.), with some code-switching mid-sentence
With a provider that enforces concurrency and rate limits:
- You need to know the maximum concurrent streams and QPS you’re allowed.
- You likely build an internal throttler so that when you’re close to the limit, you start queuing text for TTS or degrading features.
- During a surprise spike (e.g., a viral TikTok leads to a 3x sign-up surge), your voice agent suddenly hits vendor caps: new TTS streams fail or lag, turn-taking breaks, and learners notice the delay.
With LMNT:
- You architect around no concurrency or rate limits and a 150–200ms streaming latency budget that’s suitable for live conversation.
- You can run a full-scale spike test—simulate 1,000 concurrent lessons—against LMNT’s API before launch to validate that voice stays natural under load.
- Because LMNT is already “trusted by” production teams like Khan Academy and Unity, you’re building on an infrastructure that’s proven in real usage, not just toy demos.
The result: your voice agent remains responsive and conversational even when usage spikes, without bolting on complicated rate-limit workarounds.
Pro Tip: When load testing, always measure turn-level latency (time from user’s message to audio start) rather than just raw API response time. For LMNT, target that 150–200ms window across a range of concurrent sessions to confirm your full stack—not just the TTS—is staying within conversational bounds.
Summary
For a production voice agent, the biggest difference between LMNT and ElevenLabs isn’t just voice quality—it’s how they behave when you scale.
- LMNT is designed for conversational apps, agents, and games with no concurrency or rate limits, 150–200ms low-latency streaming, and studio-quality voice clones from a 5-second recording across 24 languages. That makes large-scale load testing and real-world traffic spikes predictable.
- Providers with stricter concurrency and rate limits require more complex architectures and careful traffic shaping—you spend more time fighting ceilings than tuning the agent’s behavior.
If you want your voice agent to feel trustworthy in production, choose the stack that lets you test, spike, and grow without hitting invisible walls.