Limits
The free-tier caps, the two rejections that enforce them, and how the session duration cap is resolved.
Three limits can stop a realtime session from starting or shorten one that does. This page lists the values and the exact rejection each one produces. For what your usage costs once a session runs, see What is metered; for the numbers behind a live workspace, the usage dashboard. There is no per-request rate limit on the API today — the only frequency ceilings are the session limits below.
Free-tier caps
An organization that hasn't moved to a paid plan carries three caps. Two of them reject a session start; the third silently shortens the session. All three, and the voice grant behind them, belong to the organization and are shared across every workspace it owns.
The following table lists the free-tier caps and their defaults.
| Cap | Default | Effect at the limit |
|---|---|---|
| Voice grant | 30 minutes | Session start is rejected with 402 free_minutes_exhausted. |
| Concurrent sessions | 2 | Session start is rejected with 429 concurrent_session_limit. |
| Session duration | 30 minutes | The server caps the session's max_session_seconds at this value, whatever you requested. |
The voice grant is one-time per organization, not a monthly allowance — it does not refill at the start of a billing period. Once it is spent, the organization needs a paid plan to start further sessions. A paid organization skips all three caps.
Rejection bodies
Both rejections arrive as non-2xx responses to the session-start call, in the standard external error envelope. Each carries a code plus the numbers behind the decision, so you can render a useful message instead of a generic failure.
402 — the voice grant is spent:
{
"error": {
"type": "api_error",
"message": "Free voice minutes are exhausted for this organization.",
"code": "free_minutes_exhausted",
"granted_minutes": 30,
"used_minutes": 30
}
}429 — too many sessions are already live:
{
"error": {
"type": "api_error",
"message": "Concurrent session limit reached for this organization.",
"code": "concurrent_session_limit",
"limit": 2,
"active": 2
}
}Neither is retryable as-is: free_minutes_exhausted needs a plan change, and concurrent_session_limit clears only when one of the live sessions ends. Both surface through the SDKs as session-start failures — catch them where you call start(). See Errors.
Session duration
session.max_session_seconds on the session-start body is a request, not a setting. The server resolves the effective cap as the smallest of what you asked for, the agent's own cap, the free-tier per-session cap, and its own ceiling, then echoes the result on the ready frame. Read it from there rather than assuming your request was honored — on the free tier a requested 3600 resolves to 1800.
The accepted range is 60–14400 seconds. See Session limits for handling the end of a capped session.
Limit configuration
None of these values is workspace-configurable. There is no soft-cap, alert, or spend-limit setting to change; the free-tier values are deployment-wide defaults and the plan caps come with the plan.