Included usage

The limits below hold while the account holds no credit. Once it does, its sandboxes have paid limits and still use the included usage first (after you add credit).

• Up to eight sandboxes running at once, each up to 2 vCPU and 4 GiB of memory, with up to 10 GiB of disk (4 GiB by default). Paused sandboxes do not count toward the eight.
• At most 16 vCPU and 32 GiB at once across every sandbox and image build that is running.
• CPU is shared, never reserved, and its guaranteed floor (cpuFloorMillis) is at most 250 thousandths of a vCPU; the default is 50. A create that asks for more is refused with no_credit_size_limit, naming each field, and so is a fork of such a sandbox.
• Sandboxes without credit download with no speed limit and upload at up to 50 Mbit/s each, and move 5 GiB a day in all, in and out together. While a server's link is full, a paid sandbox gets four times a sandbox without credit's share of it.
• A sandbox without credit that keeps trying to reach internal or cloud metadata addresses has its network cut and the account suspended. One that holds its CPUs flat out for 30 minutes is slowed to half a core for the rest of its run.
• Previews of a sandbox without credit are private: a link carries its token. Public previews need a kept top-up: one paid and not refunded. Credit given alone does not open them (pricing).
• A sandbox runs while it works and pauses itself when idle, until the included usage runs out; then it pauses, unless the account holds credit, in which case it carries on on credit. There is no time limit unless you set one with timeoutSeconds (60 to 86,400); one longer than the usage left is cut to it. Idle means nothing happening in it for idlePauseSeconds (60 seconds by default): no request, no command, terminal, SSH session or port forward open, no CPU use and no traffic; a browser tab left open on a preview does not count. Wake it to keep going.
• Your first three images and first 10 GiB of volumes are stored free, for as long as you keep them (pricing). A build uses the included usage: at most 2 vCPU and 4 GiB, 20 minutes and 10 builds a day, with only the time it builds used, and none when it fails through a fault of ours.
• A scheduled job's runs use it too, each a sandbox without credit within the same size and count. A run it cannot take waits with blockedReason credits until the account holds credit or the month renews.
• A sandbox without credit reaches the internet on ports 80 and 443 only. Other ports, such as a database's or git over SSH, need a paid sandbox of an account with a kept top-up.

Over HTTP, a create is POST /v1/sandboxes. This body names the defaults; an empty body is the same:

JSON{  "vcpu": 2,  "memoryMiB": 4096,  "diskMiB": 4096,  "cpu": "shared",  "cpuFloorMillis": 50}

Paste the setup prompt from Get started. The agent runs everything on the included usage, switches any sandbox code the project has on another provider, and tells you what you would save each month.

You do not have to ask for it. create() uses the included usage while the month has some left, sized to fit.

TypeScriptimport { Runtime } from "withruntime";const runtime = new Runtime();const sbx = await runtime.sandboxes.create({ vcpu: 1, memoryMiB: 2048 });try {  console.log(sbx.info.funding, sbx.info.endsAt);} finally {  await sbx.stop();}

Use a region listed for your account. Leave region out for the default.

Read it with npx withruntime usage, or GET /v1/usage:

• allowances has one row per product: pool, unit, quantity, used, reserved (held for what runs now, given back unless used), left, month and renewsAt.
• trial is the machine time a new sandbox without credit can still run, in milliseconds: availableMs, with offer (monthly, or hours for an account given free hours before 5 October 2026) and renewsAt. The field keeps its older name, so code that reads it goes on working.

In the browser, Usage & billing shows what each product used this month and what is left.

These codes were named trial_busy, trial_capacity, invalid_trial, trial_domain_limit, trial_build_limit, trial_exhausted and trial_unavailable before 5 October 2026 (changelog).

Requests sent at the same moment are admitted in no set order, so any one of them may be the one refused. Shared mail providers such as gmail.com, outlook.com and icloud.com have no domain limit. Temporary inbox services such as Guerrilla Mail and Mailinator cannot open an account.

Included usage cannot be cashed out, refunded, carried over or gained by signing in again.

Add credit and keep going. An owner, admin or billing member adds prepaid credit at Usage & billing, any amount from $10, with no subscription. There is nothing to switch: from then on

• new sandboxes are paid, with paid limits (larger sizes, any port, public previews, persistence, more at once), and still use the included usage first, then credit;

• a paused sandbox without credit wakes on credit;

• a running sandbox without credit carries on on credit when the included usage ends, without pausing.

• A paid sandbox runs the same way: while it works, until you stop it, it idles into a pause, or credit or a spending limit runs out. persistent keeps one running with no idle pause. A stop keeps a sandbox's disk until you delete it.

• A paid account runs 100 sandboxes at once from its first top-up, paused ones not counted, and more on request (pricing).

• Refer a company and you both get credit matching its first top-up, from $25 to $500 each (referrals).

For what a sandbox may reach, see security.