Limits
Build limit-aware API clients before increasing capacity.
Sandbox limits protect capacity during private beta. Good clients expose usage and blocked states before users hit a confusing failure.
Sandbox limits
| Area | Default free sandbox | Product behavior |
|---|---|---|
| Videos | 2 | Show add-video disabled state and request path |
| Active jobs | 1 | Queue or reject clearly |
| Capture seconds | 20 per execution | Explain bounded CPU-first execution |
| Ask queries | 5/month | Show current usage before error |
| API calls | 100/month | Use billing state endpoint |
| Storage | 50MB | Explain retention and cleanup |
Limit handling pattern
Call /api/product/billing/state before starting large actions. If a user is near quota, show a disabled state or request-capacity CTA. Do not let a long-running workflow fail silently after the user has uploaded footage.
Higher limits should be tied to a workload description: source type, expected hours, retention, latency, risk level, and whether human review is required. That information prevents compute surprises.