Realtime Videos · Resources
Billing and limits
What is metered, when metering starts and stops, and the limits that apply during the preview.
How metering works
| Rule | Detail |
|---|---|
| Unit | Seconds of wall-clock time, rounded up. |
| Starts | When the pod accepts the session (started_at; status ready). Not when your client connects. |
| Stops | When the session ends: your DELETE, a duration cap, or the pod ending it. |
| Queued time | Free. queued and starting sessions are not billed. |
| Pod failure | Billing stops at the last time we confirmed the pod was healthy (polled every couple of seconds), not at the time we noticed. |
Reading usage
GET /v1/realtime/sessions/{id} returns usage.seconds, which grows while the session is live and is final once it ends. DELETE returns the final value.
Limits in the preview
| Limit | Value |
|---|---|
| Queue wait | 120 s by default, then failed with capacity. |
| Session length | 600 s by default; max_duration_s can only lower it. longlive-1.3b is limited to 240 s. |
| Request body | 1 MB. |
| Concurrency per model | Set by how many pods an operator runs, one session per pod. Not an account setting. |
| Per-account quotas | Not enforced. There is no per-key concurrent-session or sessions-per-minute limit yet. |
- Because capacity is shared and small, expect queueing under load. Handle
queuedandcapacityin your client. - Moderation, regions, and an uptime SLA are not part of the preview.