Limits and concurrency

Is there a free-tier quota?

Yes. The free tier includes $5.40 of usage credit per month (plan base fees on paid tiers convert 1:1 into credit the same way). Two thresholds matter:

• At 80% of the credit you get a heads-up email.
• At 100%, compute stops: running sandboxes, apps, and databases are paused/hibernated, and new creates return 402 Payment Required.

Nothing is deleted. State is preserved exactly as it was; the pause lifts when you add a payment method or when the credit resets at the start of the month. Details in Billing.

How long does a sandbox live by default?

Every sandbox has a TTL — wall-clock seconds until the orchestrator kills it. The default is 1 hour, and the countdown is refreshed by any API activity on the sandbox, so an idle non-persistent sandbox is reaped when its TTL runs out. You can set it at create time (ttl_seconds) or change it later:

pandastack sandbox set-ttl <id> --ttl 7200

Setting persistent: true opts the sandbox out of the TTL entirely:

pandastack sandbox set-persistent <id> --persistent true

A persistent sandbox is never reaped, but the server-side idle sweeper hibernates it after about 5 minutes of inactivity — hibernated compute bills nothing, and the sandbox wakes implicitly on the next API request. See Lifecycle and Scale to zero.

What CPU and RAM does each sandbox get?

Every sandbox gets 8 burstable vCPUs, on all plans and all templates. The 8 vCPUs are burst capacity — under host contention, cgroup weights share cores fairly — and you are billed only for active CPU-seconds actually used.

RAM is fixed by the template, because a Firecracker snapshot bakes the guest's memory size:

You cannot ask for a different RAM size on an existing template — pick the template whose size fits, or build a custom template. Plans cap the largest per-sandbox RAM you can use: 4 GiB on Free, 16 GiB on Pro, 64 GiB on Team.

How many sandboxes can I run at once?

There is no single global number — three per-workspace ceilings apply, and each returns a distinct 429 when hit:

• Concurrent sandboxes (max sandboxes reached) — delete idle sandboxes.
• Hourly creates (hourly create limit exceeded) — the response body includes limit_per_hr and used_last_hr.
• Aggregate CPU/RAM (workspace resource quota exceeded) — the body includes the used and max values.

If your workload needs higher ceilings, contact hello@pandastack.ai.

Is there an API rate limit?

Yes: 50 requests burst, 25/sec sustained per workspace. A rate-limited request returns 429 with Retry-After: 1. This is separate from the create quotas above.

I got a 503 "no compute capacity available" — what does that mean?

It means capacity, not an outage: no compute node could take the request at that moment (the same condition can also surface as 502 no available compute node — see the error reference). Fleet capacity is bounded by memory — each sandbox reserves its template's full baked RAM — so under load this is the error you see first.

It is transient: retry with exponential backoff, honoring the Retry-After header when present. If it persists for minutes, delete sandboxes you no longer need and contact support. Note that creates are not idempotent — if a create's response was lost, list your sandboxes and reconcile rather than blind-retrying.

Are there limits I should design around rather than ask about?

Two practical ones:

• Memory is the binding constraint. Concurrency on any fleet is governed by RAM, not sandbox counts. Smaller templates (code-interpreter, agent at 2 GiB) pack roughly twice as densely as 4 GiB ones.
• Hibernate instead of holding. A hibernated sandbox costs no compute and no quota headroom for CPU-hungry work. If your agent works in bursts, hibernate between turns and wake on demand.