How to handle no_capacity and quota_exceeded errors

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, checked 25 October 2026). A paused sandbox holds no CPU or memory, so pausing idle work makes room.

What each refusal means

The first five are temporary. The last two are not, and the SDKs do not wait on them (API 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 never waits.

TypeScriptimport { 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);

Pythonfrom withruntime import Runtimewith 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.

TypeScriptimport { 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);  }}

Pythonfrom withruntime import Runtime, RuntimeErrorruntime = 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 <id> gives a running sandbox's CPU and memory back while it keeps its state (pause and resume).

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).
• Asking for more than 4 copies without credit. It never fits, however long you wait. Ask for fewer, or fork onto paid credit (forking).
• 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).
• 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).
• 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). For bursts, see agent evals and SWE-bench and RL environments.

Facts on this page were checked on 26 October 2026.