Skip to main content
GET /v1/agent/limits reports what the calling key is allowed to run and what it is running. use it to queue callers gracefully instead of discovering a 429 mid-flow.
curl

​
response

​
integer
how many calls your plan may run at once.
​
integer
how many are running right now.
​
string
your billing mode. this is what decides how a call is paid for:
  • payg — calls are billed per second from your credit balance.
  • unlimited — you are on a concurrency plan; calls run on its slots and cost nothing per second.
a legacy credit mode may also appear on older accounts and bills like payg. see billing for the full comparison.

​
on a concurrency plan, this is your only ceiling

if plan is unlimited, concurrency_limit is the whole story: calls cost nothing per second, and the limit is what stops them. a credit balance sitting in the account is not a fallback — a call that arrives with every slot busy is refused with 429, it is not charged to your credits instead. if plan is payg, there are two ceilings and you can hit either: this one (429) and your balance (402 insufficient_balance).

​
the pay-as-you-go default: 4 slots

without an active subscription you are pay-as-you-go, and that comes with 4 concurrent slots out of the box — nothing to buy, nothing to configure. there is no separate “TTS limit” and “agent limit”: it is one number for the whole account, in the sense described just below. a subscription raises it — each plan carries its own concurrency — and when a subscription ends the account reverts to 4 immediately. limit changes apply from the next request; capacity is read live, never cached.
the things sharing those 4 slots hold them for very different lengths of time. a TTS request occupies a slot for the seconds it takes to synthesize; an agent call occupies one for the entire call. four long calls will starve a batch TTS job, and vice versa.

​
capacity is account-wide

active_requests counts everything on the account, not just voice agents: TTS requests, dashboard sessions and API calls all draw on the same pool. a batch TTS job can therefore be the reason an agent call is refused. that is also why this endpoint is the right thing to check: it measures exactly what a 429 is measured against.

​
using it

python
this is a snapshot, not a reservation. between your check and your start, another call can take the last slot — so handle 429 concurrency_limit_exceeded on the start anyway. the check reduces how often you hit it; it does not replace handling it.

​
raising your limit

concurrency comes from your plan. change it in billing, or write to api@rumik.ai if you need more than the plans offer.