Home / Docs / Limits · also: Quickstart
Limits
Defaults during the public beta. The beta is free — every account starts with a one-time grant of 100 sandbox-hours.
Account quotas
| Item | Default |
|---|---|
| Credit | 100 sandbox-hours of running time, one-time (no monthly reset) — paused time doesn't consume it |
| Concurrent running sandboxes | 5 |
| Concurrent paused sandboxes | 50 |
Idle auto-pause
- A running sandbox with no recorded activity for 300 s pauses automatically. The threshold is one global setting, not per-sandbox — and CPU usage is not part of the decision, so background computation pauses too.
- Exception — paused quota full: auto-pause only runs while your account has paused-sandbox quota left. If your 50 paused slots are full (user-paused sandboxes count too), an idle sandbox is not paused: it stays running, keeps consuming running time, and is retried on the next sweep until a paused slot frees up.
- An open connection streaming to or from the sandbox counts as activity.
- Pause keeps full memory and running processes; the next request to the sandbox's endpoints resumes it — measured ~160 ms.
- No session length cap on the gateway side. The v2 API defaults
timeoutto 300 s; set it at create time or change it later withsetTimeout. - Paused time doesn't consume your hours — only running time does.
Network policy
- Internet on by default — sandboxes can reach the public internet outbound (model APIs, package registries, git hosts).
- SMTP egress is blocked (ports 25, 465, 587).
- Shared egress IP (NAT). Sustained high CPU use (e.g. cryptomining) is detected automatically: the sandbox is paused, and repeated findings suspend the account.
When you hit a limit
- Over the running-sandbox cap →
429with your current count and the limit. - Credit exhausted →
402; running sandboxes are paused, not deleted. - Platform saturated → create requests queue briefly, then
503+Retry-After. We return honest errors instead of degraded sandboxes.
Also see: quickstart · benchmarks