# How to handle no_capacity and quota_exceeded errors The SDK waits for room. A create refused with `no_capacity`, `quota_exceeded` or `no_credit_running_limit` is retried for up to two minutes. A wake or restart also waits. **On Runtime, a burst of creates past a limit queues instead of failing. A refusal costs nothing.** A paid account runs 100 sandboxes at the same time. The running sandboxes can use 200 vCPUs and 400 GiB of memory in total. Support raises these limits on request. An account without credit runs four sandboxes at the same time ([how many at the same time](/docs/pricing#how-many-at-once), checked 25 October 2026). A paused sandbox holds no CPU or memory, so pausing idle work makes room. ## What each refusal means | Code | Status | Cause | Clears when | | ------------------------- | ------ | ----------------------------------------------------------------- | ----------------------------------------------- | | `no_capacity` | 503 | No host in the region has room right now | A host frees room | | `busy` | 503 | A host is briefly busy | On its own; the SDKs retry it | | `no_credit_running_limit` | 429 | Four sandboxes without credit are running; `details` names them | One of them stops or pauses | | `no_credit_domain_limit` | 429 | Accounts on your email domain fill its eight slots without credit | One of them stops or pauses | | `quota_exceeded` | 429 | The account is at its sandbox, vCPU, memory or disk limit | Something stops or pauses, or support raises it | | `included_usage_used_up` | 402 | The free usage is used and the account holds no credit | Add credit, or the 1st (UTC) once it has paid | | `spending_limit_reached` | 402 | The key's daily limit would be passed | Older spending leaves the 24-hour window | The first five are temporary. The last two are not, and the SDKs do not wait on them ([API errors](/docs/api#responses-and-errors)). ## Set how long a create waits The wait is added to the call's timeout. It does not come out of the timeout. Set it on the client for every create, or on one create. `0` fails immediately. A sandbox's `wake` and `restart` take the same option and wait the same way. For example, `sbx.wake({ waitForCapacityMs: 0 })` fails immediately. A fork waits the same way when no server has room for a copy, and takes the same option; the CLI's `sandboxes fork --no-wait` fails immediately. ```ts import { Runtime } from "withruntime"; // A nightly batch that may queue for ten minutes behind other jobs. const runtime = new Runtime({ waitForCapacityMs: 600_000 }); await using sbx = await runtime.sandboxes.create(); // An interactive request that should fail fast and tell the user. await using now = await runtime.sandboxes.create({}, { waitForCapacityMs: 0 }); console.log(sbx.id, now.id); ``` ```python from withruntime import Runtime with Runtime(wait_for_capacity=600) as runtime: with runtime.sandboxes.create() as sbx: with runtime.sandboxes.create(wait_for_capacity=0) as now: print(sbx.id, now.id) ``` ## When the wait runs out When the wait ends, the SDK throws the refusal as it was returned. Its `retryable` is `true` for `no_capacity` and `no_credit_running_limit`, so your own loop can keep retrying. Use the same idempotency key on every attempt. A create that already landed then returns the original result. It does not create a second sandbox. ```ts check import { Runtime, RuntimeError } from "withruntime"; const runtime = new Runtime({ waitForCapacityMs: 120_000 }); const options = { idempotencyKey: "nightly-2026-09-25-shard-7" }; for (let attempt = 1; ; attempt++) { try { await using sbx = await runtime.sandboxes.create({ labels: { shard: "7" } }, options); console.log((await sbx.exec("nproc")).stdout); break; } catch (error) { if (!(error instanceof RuntimeError) || !error.retryable || attempt === 5) throw error; console.warn(error.code, error.hint, error.requestId); } } ``` ```python check from withruntime import Runtime, RuntimeError runtime = Runtime(wait_for_capacity=120) for attempt in range(1, 6): try: with runtime.sandboxes.create(idempotency_key="nightly-2026-09-25-shard-7", labels={"shard": "7"}) as sbx: print(sbx.exec("nproc").stdout) break except RuntimeError as error: if not error.retryable or attempt == 5: raise print(error.code, error.hint, error.request_id) ``` From a terminal, `runtime sandboxes ls` shows what is holding the room. `runtime sandboxes pause ` gives a running sandbox's CPU and memory back while it keeps its state ([pause and resume](/how-to/pause-and-resume-a-sandbox)). ## Mistakes that make it worse - **A new sandbox per retry.** A retry with a new key can create a second sandbox. Reuse the key, as above ([idempotency keys](/how-to/retry-safely-with-idempotency-keys)). - **Asking for more than 4 copies without credit.** It never fits, however long you wait. Ask for fewer, or fork onto paid credit ([forking](/how-to/fork-a-running-sandbox)). - **Replacing a sandbox that will not wake.** A wake needs room on the sandbox's own host. A full host can refuse the wake and keep the saved state. The SDK waits for room for up to two minutes. If that wait ends, retry the wake later. Do not delete the sandbox as a retry step ([a paused sandbox will not wake](/docs/troubleshooting#a-paused-sandbox-will-not-wake)). - **Looping on a spending limit.** `spending_limit_reached` counts the last 24 hours. Only a person can raise it, on the keys page ([daily spending limits](/how-to/set-a-daily-spending-limit)). - **Retrying `fork_unavailable` or `previews_unavailable`.** These 501s mean the feature is switched off there on purpose. Retrying will not help. ## Ask for more room The starting limits are not a pricing tier. Write to support with the numbers you need: `runtime support "we need 400 sandboxes at once for evals"` ([feedback and support](/docs/feedback-and-support)). For bursts, see [agent evals and SWE-bench](/use-cases/agent-evals-and-swe-bench) and [RL environments](/use-cases/rl-environments). Facts on this page were checked on 26 October 2026.