Free usage

In the countries below, free usage is 100 free hours of a 1 GB machine, as above. An account opened with Google starts it with no card. An account opened by email starts it once its owner adds a card under Auto top-up on Usage & billing: your bank checks the card, and Runtime does not charge it unless you turn auto top-up on. Each card starts free usage for one account. In other regions, machine time starts when the account buys credit, and buying credit unlocks the full free usage every month, in every region. Saved copies and disks are the same everywhere.

Andorra, Australia, Austria, Belgium, Canada, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hong Kong, Iceland, Ireland, Israel, Italy, Japan, Korea, Latvia, Lithuania, Luxembourg, Macao, Malta, the Netherlands, New Zealand, Norway, Portugal, Puerto Rico, San Marino, Singapore, Slovakia, Slovenia, Spain, Sweden, Switzerland, Taiwan, the United Kingdom and the United States.

The region is where the account was opened from; for an account opened before 29 October 2026, where its first visit to withruntime.com came from.

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

• Up to four sandboxes running at the same time, 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 four.
• At most 8 vCPU and 16 GiB at the same time across every sandbox and image build that is running.
• At most 5 sandboxes kept, running, paused or stopped. A create past that is refused with no_credit_kept_limit. Delete one to make room. Waking, resuming or deleting a sandbox you already keep is never refused.
• At most 50 sandboxes made a day (any 24 hours). Copies made by a fork count too. Past that limit, a create is refused with no_credit_daily_limit.
• At most 10 live API keys in the account, whoever made them. A new key past that is refused with no_credit_key_limit. Revoke one to make room. A revoked or expired key frees its place. Every key you already hold keeps working. The short-lived keys Runtime makes by itself, for the console, its terminals, image builds and the other work it runs for you, are not counted. Once the account adds credit, there is no limit.
• No scheduled job runs. It waits until the account holds credit.
• CPU is shared, never reserved. 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. So is a fork of such a sandbox.
• Sandboxes without credit download with no speed limit and upload at up to 10 Mbit/s each. They move 1 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 is suspended. So does a sandbox of an account that has never paid that connects to a mining pool, scans ports, or reaches very many different destinations in a few minutes, as a scan or a sweep does. 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. It pauses itself when idle, until the free usage runs out. Then it pauses, unless the account holds credit. In that 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 (300 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). That is apart from the table. The 5 GB of disks a month in the table pays for volumes past your first 10 GiB. A build uses the free usage: at most 2 vCPU and 4 GiB, 20 minutes and 10 builds a day. Only the time it builds is used. A build that fails through a fault of ours uses none.
• A scheduled job does not run without credit. It waits with blockedReason credits until the account holds credit. Once it does, each run is a sandbox like any other, and uses the free usage first.
• A sandbox without credit cannot reach cryptocurrency mining pools, on any port.
• 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 free usage. It 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 free 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 (the quantity less what is used; what is held is not taken off), month, renewsAt and freeUntil (when the free usage ends for an account that has never paid; null once it has paid).
• 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. It counts what running sandboxes hold until they end. A create without credit is refused with included_usage_used_up exactly when availableMs is 0. The field keeps its older name, so code that reads it goes on working.
• freeUsageHold says why the account has no free machine time, or is null. reason is hosting (opened from a data-center or VPN network), region (opened outside the countries listed above), card (opened by email, with no card saved yet), withheld (under review), no-source or unknown. message says the same in a sentence, with what starts the free usage. While it is set, the account has no free machine time (trial is null or its availableMs is 0), and a refused create's details.reason is the same reason.
• startupIncluded lists what Runtime for Startups includes for an accepted startup, one row per product. machine-cpu and machine-memory have period once: quantity, used, reserved and left. They are used after the month's free usage and before credit, and never renewed. What is left ends at expiresAt, 12 months after it was given. saved-copies and disks have period month: quantity GB added to each month's included storage until expiresAt, never used up, with keptGB, the GB kept now. Storage past it is charged at the published rates. startupLimits lists the concurrency limits that Runtime for Startups includes, buildsAtOnce and sandboxesAtOnce, until the same expiresAt. After it, null. The account is paid with no top-up until then. After that, it is paid once it holds credit it bought.

The old fields pot and potLimits still work for 30 days after this change ships, with a warning.

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

Code	What it means	What to do
no_credit_running_limit	Four sandboxes without credit are running; details.running names them	Stop or pause one; an SDK create waits for a slot
no_credit_total_limit	Running sandboxes and builds would pass 8 vCPU and 16 GiB; the message says what runs now	Stop or pause one, or wait for a build to end
no_credit_kept_limit	The account keeps 5 sandboxes, running, paused or stopped, and a create would make another	Delete one, or add credit
no_credit_daily_limit	50 sandboxes made in the last 24 hours	Reuse a sandbox, retry later, or add credit
no_credit_key_limit	The account holds 10 live API keys, and a new key would make another	Revoke one, or add credit
no_credit_domain_limit	Accounts on your company's email domain share eight running sandboxes without credit, all running	Stop or pause one, or add credit
no_credit_size_limit	The size asked for is larger than 2 vCPU, 4 GiB and 10 GiB of disk	Omit the size fields for the default
no_credit_build_limit	10 builds started in the last 24 hours	Reuse an image, or retry later
no_credit_capacity_full	The room servers keep for accounts without credit is full right now	Retry shortly; an SDK create waits
included_usage_used_up	The free usage is used and the account holds no credit	Add credit, or wait for the 1st (UTC) if it has paid
included_usage_unavailable	The account has no free usage: it goes once to each verified email address, and the owner's is unverified or already has it on another account; or the account was opened from a data-centre or VPN network, where it comes with credit	Verify your email, or add credit

Each of these responses says what was refused and the limit. Then, in its hint and in details.addCredit, it gives the one way past it: the account's owner adds credit. Credit added within 30 days of signing up is matched, up to $1,000 in total (how refusals look). An agent tells its person which limit it met. It never adds credit on its own. The exception is an account it opened with a wallet and no person pays for. There, the hint tells it to add credit itself (pay with stablecoins).

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.

Free 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. The amount can be any amount from $10, with no subscription. Credit you add within 30 days of signing up is matched, up to $1,000 in total (welcome match). There is nothing to switch. From then on:

• new sandboxes are paid, with paid limits (larger sizes, any port, public previews, persistence, more at the same time). They still use the free usage first, then credit;

• a paused sandbox without credit wakes on credit;

• a running sandbox without credit carries on on credit when the free 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 the same time from its first top-up. Paused ones are not counted. More are available on request (pricing).

• Refer a company and you both get up to $1,000, then 10% of what it spends for 12 months (referrals).

For what a sandbox may reach, see security.