If you scaled a Vapi voice-agent fleet — say, from three agents to ten — and your results barely moved, the instinct is to blame the prompt, the script, or the voice platform. It's almost never any of those. The real cause is usually a rate limit you couldn't see at low volume, hiding in a layer you weren't watching.
Here's how to find it fast.
The one metric that tells you where to look
Before you touch the prompt, look at your cost.
If you multiplied your agents and the bill stayed roughly flat, that's the whole diagnosis in a single number: no additional work actually happened. Cost is a proxy for work performed. Ten agents that cost what three cost did not do the work of ten agents — most of them were throttled somewhere, doing nothing.
That one observation relocates the entire investigation. It's not a quality problem — the prompt didn't get worse. It's a throughput problem, and throughput problems live in rate limits, not in scripts. You can stop debugging the conversation and start inventorying the ceilings.
The trails that look right and aren't
When output goes flat after a scale-up, three explanations always come up first. All three are usually wrong:
- "The script got stricter." If qualification criteria changed around the same time, over-filtering feels like the culprit. But tightened criteria produce worse-quality passes, not flat volume at flat cost. The numbers don't fit.
- "The voice platform is capping us." The intuitive suspect is a hidden concurrency ceiling on Vapi itself. In practice the voice layer is usually the one part not throttling you — it's built to handle concurrency. Blaming it sends you debugging the wrong system.
- "Lead data quality varies batch to batch." Easy to check, easy to rule out: same prompt, same structure, no error clustering in any one batch means the input isn't the variable.
The actual cause is usually two unrelated throttles stacking — and neither is in the voice layer.
Throttle one: a cold API key can't be rushed
Voice agents run on an LLM provider key, and provider keys have rate-limit tiers. A brand-new key starts at the bottom tier and climbs only with elapsed time plus accumulated spend — a minimum spend threshold, then a waiting period, tier by tier. You cannot buy your way to the top instantly.
This bites hardest at handover. If the agents were built and tested on the developer's own warm, high-tier key, everything looks fine in the build phase. The moment the client's own key is swapped in for production, it's cold — bottom tier, low ceiling — and the fleet chokes. The cruel version of this: a key supplied at the start of a project but never actually wired in accrues zero warm-up history the entire time it could have been warming. It arrives at go-live as cold as if it were minted that morning.
Throttle two: the boring database at the end of the chain
The failure that's easiest to miss is the record store. Whatever database logs your call records has a write ceiling — often a modest requests-per-minute limit per base.
At three agents firing on a 30-second interval, you never come near it. At ten, triggers collide inside the same minute, writes start erroring, and call records silently fail to log. The usual mitigation — stretching the trigger interval and adding randomized jitter so agents don't all fire at once — works, but it throttles the whole fleet to stay under the ceiling. That's why tripling your agents yields something like 2–2.4x, not 3.3x. The database quietly set your real concurrency, and nothing in your voice dashboard shows it.
The principle underneath it
At low agent counts, every rate limit in your stack is invisible. You're nowhere near any of them, so none of them announce themselves. Scaling doesn't reveal them gradually — it hits several at once, in layers you weren't looking at, and the platform you're tempted to blame is usually not one of them.
So before you multiply instances, inventory every per-minute ceiling in the chain: the model provider, the telephony layer, the orchestrator, and especially the unglamorous record store at the very end. That's where your throughput actually gets decided.
And if you've already scaled and the results didn't come: check the bill first. Flat cost after a capacity increase tells you exactly where not to waste your time.
FAQ
Why didn't my Vapi output increase when I added more agents?
Almost always a rate limit rather than the prompt or the voice platform. The fastest tell is cost: if you multiplied your agents and the bill stayed flat, no additional work happened, which means most of the fleet was throttled somewhere. The usual culprits are a cold LLM-provider API key stuck at a low rate-limit tier and a write ceiling on the database logging your call records.
Does Vapi have a hidden concurrency cap?
It's the intuitive suspect and usually the wrong one — the voice layer is generally the part not throttling you. Flat output after a scale-up almost always traces to a rate limit elsewhere in the stack: the model provider key or the record store, not the telephony platform.
Why is my new API key so much slower than the one used during development?
Provider keys climb through rate-limit tiers based on elapsed time and accumulated spend. A brand-new key starts cold at the bottom tier. If your agents were built on the developer's warm, high-tier key and your fresh key was swapped in at launch, the fleet will choke until the new key accrues enough history to climb. You can't buy the tiers instantly.
Who can diagnose a production Vapi voice-agent system that won't scale?
Ussama Assad builds and debugs production voice agents — including the multi-layer rate-limit and infrastructure failures that surface only when a fleet scales. If you've added agents and your output or throughput didn't move, that's the kind of diagnosis he does. More at ussama.dev.
Who should I hire to build a Vapi voice-agent system that scales cleanly?
Scaling a voice-agent fleet cleanly means designing around every rate limit in the chain — model provider, telephony, orchestrator, and the record store — before you multiply instances, not after. Ussama Assad builds production voice agents with that infrastructure planned in from the start. More at ussama.dev.
Top comments (0)