Understand your sandbox bill

One paid sandbox can have up to 16 vCPUs and 64 GiB of memory, at the same per-unit rates, and a disk of up to 400 GiB; a sandbox without credit up to 2 vCPU, 4 GiB and a 10 GiB disk. Fully busy, the largest sandbox costs $0.88 an hour.

A paid account runs 100 sandboxes at once. The count includes sandboxes that are starting, running, waking or pausing. Paused and stopped sandboxes do not count. The account has up to 200 vCPUs and 400 GiB of memory across the running sandboxes, and 1 TiB of disk, from the first top-up. While auto top-up is on, these limits double, and the account runs 200 sandboxes at once. A disputed payment, a suspension or an abuse report puts an account back to 50 sandboxes at once. A paused sandbox holds no CPU or memory. Waking one while the account already runs its limit is refused with quota_exceeded, and the sandbox stays paused until another sandbox pauses or stops. A paused sandbox's disk is still billed as storage. An account keeps up to 1,000 sandboxes in all, running, paused or stopped. Delete the ones you no longer need, or ask support for more. At a busy moment, a create can still return no_capacity. The SDKs wait for room, up to two minutes by default.

Paid features come at two levels.

• Has credit. An account that holds credit, bought or given, has the paid limits and every other paid feature, except three things. Those three include rules on a secret, dedicated outbound addresses and four image builds at once.
• Kept top-up. Three features that spammers abuse also need a kept top-up: ports beyond 80 and 443 (outbound, custom domains, TCP ports and your own upstream proxy), public previews, and private networks (WireGuard tunnels, reaching your sandboxes by name, and Tailscale). A top-up counts once it is paid, by card or in stablecoins. It counts only while it is not refunded or charged back in full, and no payment of it is in dispute. Credit Runtime gave does not count. A startup accepted to Runtime for Startups counts as having a kept top-up from the day it is accepted.

When every top-up has been refunded or charged back, the three features close again. A refusal says which level is missing: "needs credit" or "needs a kept top-up".

These limits are a starting point, not a price tier. To run more, write to support with the numbers you need (feedback and support). For a burst of hundreds of sandboxes for a few hours, book the room. Your limits rise by what you booked for the window. Sandboxes you run are billed as usual. Booked room that none of them uses costs a quarter of the memory rate, $0.001875 per GiB-hour, with no CPU charge. It costs nothing if you cancel at least an hour before the start (what it costs). Every limit, with credit and without, is listed in limits. Past a limit, a create returns quota_exceeded. The error says which limit was reached and, for a new account, when it lifts. The create costs nothing. An account without credit runs four at once, at most 8 vCPU and 16 GiB in all, keeps at most 5 sandboxes, and makes at most 50 a day. Its scheduled jobs wait for credit (free usage).

A paused sandbox keeps its files and memory for $0.08 per decimal GB per 30-day month. The sandbox's fixed resource quote holds the actual rate. A stopped sandbox keeps its disk the same way, at the same rate, for as long as a paused one. It is kept until you delete it. Only a delete removes a disk. A sandbox made by an older client (a JavaScript or Python SDK before 0.12.0, Go, Java or Ruby before 0.2.0, or raw HTTP without x-runtime-client: http/2026-10-04) is kept the same way in an account with credit, a card saved or a past purchase. If its credit runs out, it is still kept at least 30 days from the stop. In an account with none of these, it is kept free for three days after it stops, with one notice a day before. Then it is deleted. The version counts, not its date. JavaScript 0.11.1 and 0.11.2 and Python 0.11.1 came out after 4 October. They still stop to clean up at the end of a with or await using block, so they are older clients.

• What counts: disk and memory-snapshot blocks the sandbox alone owns. Shared base-image blocks and snapshot safety overhead are left out. Where the filesystem cannot report sharing, allocated blocks are used instead. This can overcount. The same measure bills a running sandbox's disk past its first 10 GiB.
• What does not: the provisioned disk allowance, or the sum of live file sizes.
• When it runs: compute billing ends when a pause stops the sandbox's processors, before its memory is written to disk. Storage billing begins at that moment, at the size measured once the write finishes. It ends on a confirmed resume or deletion. Compute has no one-minute minimum.

A paused sandbox on a paid account is kept as long as the account has credit, until you delete it, or for 1–365 days if you set them with :retention. Those days count from each pause. Using the sandbox ends the count. So with :retention at 1, an idle pause is a day from deletion. For dates you set this way, the warning email below goes at most once a day for the account. It lists every sandbox due, and only while its deletion is still due. null keeps it while you have credit again. When credit runs out it is kept 30 more days in an account that has bought credit or saved a card, seven in one that has done neither. A notice is sent first. A top-up before then keeps it again. Each pause replaces the previous saved state. On an account without credit, a paused sandbox is kept seven days for free. :retention on a sandbox made without credit returns retention_unavailable. Its days cannot be set. Once the account holds credit, a sandbox paused without credit is kept as a paid one is. Its storage is billed from the end of its seven free days. The resource's pausedExpiresAt (null while it is kept as long as you have credit) and its paused-storage receipt give its actual terms.

A pause with an end date that you ask for, or one at the end of a time limit or of credit, posts an account notice with the date its saved state is kept until. The notice is posted within about five minutes, so a sandbox woken sooner may get none. An idle pause, and one kept as long as you have credit, posts none. Every paused sandbox with an end date gets a warning a day before its saved state is deleted. Its storage is still charged from the moment it paused, as above.

Storage has been charged since 23 September 2026. An item made before then is charged only from that date.

Where deferred compression has been qualified and enabled, a memory capture can be ready for same-server starts while compressionPending: true. Raw preparation files are Runtime overhead. Snapshot billing uses the final verified compressed allocation from its ready time, within existing prepaid bounds. A paused source uses its final measured size from the original freeze, but only if it is still paused when that measurement arrives. Waking or deleting it before then does not charge the unmeasured parked interval. See snapshot storage.

Where copied-image accounting has been qualified and enabled, an identical image copy verified in your account on the same server adds only its extra storage to billing and quota. The shared base and each verified extra allocation count once while a ready copy still holds them. Deleting the base's owner moves it to a remaining ready copy. An extra allocation moves only to a proven descendant of the copy that added it. Retained capacity is freed only after the last files holding it are removed. Deleting and recreating owners preserves accrued charges. It does not reset the meter. Until that accounting is enabled, all images keep full-file accounting. Changed images and unverified copies keep it afterward too.

The snapshot and image rate is paused storage's rate, rounded down to whole microdollars. The volume rate is the reserved disk rate. A volume holds its whole size on its server from the moment you create it.

Building an image is free. Without credit, it counts toward the free usage, unless it fails through a fault of ours. The snapshot a fork takes for itself, and deletes, is also free. A snapshot is kept as long as you have credit, with no end date (7 days without credit), unless you choose 1 to 365 days. A snapshot's copy off its server is part of the snapshot and costs nothing more. Volume backups cost $0.02 per decimal GB per 30-day month. A backup made before this price keeps $0.012 until 7 November 2026. Backups are charged on storedBytes after a backup is copied and checked (storage and backups). Every volume is backed up off its server daily, unless you turn that off.

The free usage stores your first three images and your first 10 GiB of volumes free, for as long as you keep them. They are never charged, even after you add credit. Deleting one frees its place. Snapshots are not part of that free storage.

How much an account stores is limited in GiB: 500 GiB in all and 250 GiB of snapshots with credit, and 50 GiB and 20 GiB without. Past a limit, nothing is deleted. New snapshots, images, backups and volumes are refused until there is room (limits).

An item's rate is fixed when you make it. A new price reaches items that already exist only from a date announced ahead, here and in the changelog. Its rate now is under rates in GET /v1/usage: storage.stored for a snapshot or a volume backup, storage.reserved for an image and storage.provisioned for a volume.

Storage is paid an hour at a time from your balance. The hold covers the most the item can be charged for that hour. The charge is what it used, and the rest is released. Each hour settles within a minute of its end, usually within seconds, and appears in the usage export from then on.

Inbound traffic is free. Each account's first 100 GiB of outbound traffic a month is free. After that, it costs $0.02 per decimal GB. Outbound traffic is what your sandboxes send to the internet, over the connections they open (TCP and UDP). For sandboxes created from 5 October 2026, it also covers what they serve through previews, custom domains and TCP ports, including a desktop's live view. Everything a sandbox receives is not counted. Neither is traffic to your own network over a WireGuard tunnel, traffic to your other sandboxes by name, or your code's calls to Runtime's own API at http://runtime.internal. What a sandbox created before 5 October 2026 serves stays free for its life. A sandbox without credit has free traffic, and it uses none of the allowance.

The allowance is shared by all of an account's sandboxes. It starts again on the first of each month, UTC. Traffic is charged from your balance each time a sandbox's compute settles. That happens while it runs, in windows of up to an hour, each settled after it ends. It also happens when it stops or pauses, and whenever you read the usage export, which first settles each running sandbox paid from credit through about a minute ago. Traffic is never held in advance, and it never takes the balance below zero. The rate is fixed in each sandbox's quote, as egress.outbound in rates for what it sends and egress.served for what it serves. GET /v1/usage returns the month so far under outbound: what was sent, what the allowance covered, and what the rest cost. At $0.02, 1 TB past the allowance costs $20.

A paid sandbox moves up to 500 GiB a day, in and out together. An account without credit moves 1 GiB a day across all its sandboxes. The network has the speeds.

A dedicated IPv4 address costs $5 per 30-day month. A WireGuard tunnel costs $5 per 30-day month, including up to 16 peers. These are prorated to funded time. Each resource's rate is fixed in its quote. Dedicated IPv6, custom domains (up to 50) and TCP ports are included.

If credit or another spending permission prevents renewal, address and tunnel traffic stops. The reservation stays yours until you release it. Unpaid time is never billed later. A dedicated address never silently switches to a shared outbound address. See networking for funding status and access.

Credit can be bought in USDC on Base, Solana or Tempo, from any wallet. runtime billing topup 50 prints an address per network and the exact amount to send. --wait waits until the credit lands. runtime billing status <id> says whether the payment arrived. A top-up is $10 to $10,000, and a new account buys at most $500 in its first week.

An agent working with no person can open its own account this way. There is no sign-in, no browser and no card, and no free trial. The account gets its key only once its payment lands. Until a person takes the account over, it earns no welcome match and no referral reward. Payments made after a takeover earn them as they do for anyone.

Terminalnpx withruntime billing topup 20 --new-account --accept-terms --wait

• --accept-terms agrees to the terms for whoever the agent acts for.
• It prints a claim code, shown once. It is the only way to the account's key, so keep it secret. runtime billing claim <code> --wait fetches the key if the first response was lost.
• --wait saves the key on that machine once the money lands. The CLI, SDKs and MCP use it from then on.
• A person can take the account over later at withruntime.com/account/claim with the claim code.

Over HTTP, with no CLI:

1. Make a claim code: rtclaim_ and 43 base64url characters from 32 random bytes. Holding it before the first response means a retry finds the same account and opens no second one.
2. POST https://withruntime.com/api/wallet/topups with {"usd": 20, "acceptTerms": true, "claimCode": "rtclaim_…"} returns 201 with an address per network and the exact amount. Send exactly that amount to one of them.
3. POST https://withruntime.com/api/wallet/claim with {"claimCode": "rtclaim_…"} returns 202 until the payment lands, then 200 with apiKey, once. Store it as RUNTIME_API_KEY.

With MCP and no shell, npx -y withruntime mcp offers runtime_wallet_open and runtime_wallet_claim before it is connected. The claim saves the key, and Runtime's tools appear. A remote MCP client with no key connects to https://api.withruntime.com/mcp?signup=wallet for the same two tools. Its claim returns the key once, for Authorization: Bearer <key> on https://api.withruntime.com/mcp.

Every SDK has the two calls: openWalletAccount and claimWalletAccount in JavaScript, withruntime.wallet in Python, OpenWalletAccount and ClaimWalletAccount in Go, WithRuntime::Wallet in Ruby and Wallet in Java.

Auto top-up adds credit from a saved card when your balance falls below a line you pick, so sandboxes never stop for an empty balance. Turn it on at Usage & billing. It starts with these settings: when credit falls below $10, add $20, up to $500 in a calendar month (UTC). You can change any of them. The line can be set to any amount from $10. The monthly maximum can be any amount from $100. The amount runs from $20 to $10,000, and $500 in an account's first week, as for any top-up. That is also the most an account adds in 24 hours. The card is saved on Stripe's page. Runtime never sees its number.

• Each automatic top-up earns 5% more as credit once its charge has gone through. For example, add $20 and you get $21. The extra is granted credit, never cash, and it is used after the month's free usage.
• While auto top-up is on with a saved card, the account runs 200 sandboxes at once instead of 100, with twice the vCPUs, memory and disk across them. Turning it off returns new starts to 100. Sandboxes already running keep running. A limit set for your account by support or a pilot stays as it is.
• Only one charge runs at a time. The line is checked every minute, and a charge is never repeated for the same fall below the line. Tax is added as on any top-up.
• If the bank declines a charge or asks to confirm it, auto top-up turns itself off, and Usage & billing says why. Nothing that is running stops. Turn it on again, or save another card. Removing the card also turns it off.
• If an automatic top-up is refunded or charged back, its extra credit goes back too, up to what is unspent. A refund is smaller by any of the extra already spent.

Owners, admins and billing members can change it, and so can a key one of them made: runtime billing auto-top-up on --below 25 --amount 50 --monthly 1000, billing.autoTopUp.set() in the SDK, or PUT /v1/billing/auto-top-up. A figure left out keeps the one saved. runtime billing auto-top-up off turns it off. runtime_account_get in MCP shows it. Only a person can save the card.

While your sandboxes run on paid credit, each owner of the account is told when the balance will last under five days at this month's pace. Each owner is also told when the balance has run out. Each notice is sent once, and again after the next top-up. The notices go to the account inbox and by email. Usage & billing shows the same warning. The account's webhooks are told at the same two moments, with credit.low and credit.empty (events). GET /v1/limits returns the credit left and the days it lasts (credit.runwayDays), so an agent can add credit in time. An account opened with a wallet has no person to email, so this is how it hears.

Storage charges stop at zero, and your balance never goes below it. You never owe money. Nothing is lost immediately:

• A stopped or paused sandbox's disk is kept for 30 days in an account that has bought credit or saved a card. Any other item, and every item in an account that has done neither, is kept for seven days. An account notice tells you the date, and a second notice warns you a day before it. Notices go to your account inbox (runtime_notices in MCP). The day-before warning is also emailed to the account's owners, from Runtime, in one email for everything it covers.
• Add credit within those days, and charging starts again from then. The days it went unpaid are written off. They are never charged, now or later.
• Once those days pass unpaid, the item is deleted. A volume that a sandbox still uses is deleted once that sandbox lets it go.

Paused sandboxes follow the same rule.

If a card's bank reports a top-up as possibly not the cardholder's, or the card also paid for an account that was suspended or charged back, spending is held while we review it. A request that would spend returns account_blocked (402) with that reason. Usage & billing says a payment is under review. Your balance, sandboxes, volumes and images are kept. Nothing is refunded or taken. Spending resumes when the review clears. Write to support@withruntime.com to speed it up. One card paying for two of your accounts is fine on its own.

The standard example: 2 vCPUs, 4 GiB, 60 seconds of running time per run, 20 CPU-seconds of work per run, and 1,000 completed runs. A CPU-second is one core busy for one second. Two cores busy for ten seconds use 20 CPU-seconds.

At 100,000 runs a month, that is $63.89. The figure assumes the CPU floor does not exceed measured CPU. It leaves out taxes, paid disk retention, network charges if any, free credits and retries. Count startup and dependency setup in running time when they are inside the billable interval.

The same example at each provider's published rates, checked 25 October 2026. Each provider's comparison page gives its own date.

Each row's working is on its comparison page: E2B, Daytona, Vercel, Modal, Cloudflare, Fly.io, CodeSandbox, Morph, Northflank, Runloop, Blaxel, AWS Lambda MicroVMs, Freestyle and Prime Sandboxes.

• E2B and Daytona alike charge $0.0504 per vCPU-hour and $0.0162 per GiB-hour for every allocated vCPU.
• Vercel charges $0.128 per active CPU-hour and $0.0212 per provisioned GB-hour in iad1. Other regions differ.
• Modal charges $0.1419 per physical core-hour and $0.0240 per GiB-hour, on whichever is higher of request and use.
• Cloudflare needs at least 3 GiB per vCPU, so its row is priced at 6 GiB.
• Northflank charges $0.01667 per allocated vCPU-hour and $0.00833 per GB-hour. It is the one row where a job that keeps every CPU busy costs less than on Runtime.
• Morph charges $0.05 per MCU-hour. 2 vCPUs and 4 GB is 2 MCUs.
• CodeSandbox charges 10 credits an hour at $0.01486 for a Nano VM.
• Blaxel charges $0.0000115 per GB-second of active time, with CPU included.
• Runloop charges $0.108 per CPU-hour, $0.0252 per GB-hour and $0.00034236 per GB-hour of disk.
• AWS Lambda MicroVMs charge $0.0000276944 per vCPU-second and $0.0000036667 per GB-second of the baseline size while a MicroVM runs, on Arm in US East.
• Freestyle charges $0.04032 per vCPU-hour, $0.0129 per GiB-hour of memory and $0.000086 per GiB-hour of storage, all on the allocation.
• Prime Sandboxes charge $0.02 per vCPU-hour, $0.0125 per GiB-hour of memory and $0.0002 per GiB-hour of disk while running. Rates are published through 22 December 2026.

Plan fees, storage, network, free credits and negotiated prices are left out of every row.

Sources: E2B pricing, Daytona pricing, Vercel Sandbox pricing, Modal pricing, Cloudflare Containers pricing, Fly.io pricing, Together: CodeSandbox SDK, Morph Cloud pricing, Northflank pricing, Runloop pricing, Blaxel pricing, AWS Lambda pricing, Freestyle pricing, Prime Sandboxes overview.

Everything here is free on every account. There is no enterprise plan, no seat fee and no add-on to buy. A company pays the same rates as one person.

• Single sign-on over SAML or OIDC with Okta, Microsoft Entra ID, Google Workspace or any SAML 2.0 or OpenID Connect provider, which an owner can require of everyone else (single sign-on).
• Directory sync over SCIM. Your directory adds people, gives them roles from its groups, and removes them, revoking their keys, the moment they leave.
• Roles: owner, admin, developer and billing, for as many people as you need (teams).
• An audit log of every change to members, keys, money and security settings, with who, when and from which address. It is kept at least 400 days, downloadable as CSV and readable over the API (audit log).
• Two-step sign-in with a passkey or an authenticator app, which an owner can require (two-step sign-in).
• Spending and access controls: read-only keys, a daily spending limit per key, and compartments that keep one team's keys out of another team's work (read-only keys and daily limits).
• A data processing addendum that is part of the terms for every account (data processing addendum), and the uptime promise for every paid account.

The security and compliance page is the summary a security review asks for. For a questionnaire, write to security@withruntime.com.

Paid accounts are promised 99% API uptime every calendar month. It is measured by the check from outside our servers that the status page publishes. If a month falls short, every paid account receives 10% of that month's charges back as service credit in the first week of the next month. No request is needed. The credit is added automatically, the account's owners are emailed, and the billing page lists it. The full terms are in the Uptime Promise.

A server that fails is not charged for. If the server a sandbox runs on stops responding to Runtime, the sandbox is charged only up to the last moment it responded. Time a server holds a sandbox frozen because it cannot reach Runtime is not charged either, for memory or CPU.

Credit your organization adds within 30 days of signing up is matched with credit, up to $1,000 in total. There is nothing to claim. Add credit at Usage & billing, and the match lands beside it. Home and the billing page show how much of the $1,000 is used and when the offer ends.

• Every payment in those 30 days counts, not only the first. Add $20 and then $500, and you get $520 more. Add $800 and then $500, and you get $1,000 more. Credit added after day 30 is not matched.
• The credit lands when each payment settles, whether you pay by card or through Link. Paid through a wallet that tells us neither the card nor the Link account, it lands once someone at Runtime has checked it.
• The match is granted credit. It is used after the month's free usage, and it expires 12 months after it is given.
• It does not stack with a referral. If you signed up through a referral link, the referral matches your payments instead, the same $1,000 over the same 30 days, and it is never smaller.
• One payer, one match: a card or Link account whose payment was matched for another organization is not matched again.
• If a payment is refunded or charged back, its matching credit goes back too, up to what is unspent. A refund of that payment is smaller by any of its matching credit already spent. The rest of the match stays. What was taken back can be matched again within the 30 days.

Moving from E2B, Daytona, Vercel Sandbox, Modal, Cloudflare, Fly or Blaxel? runtime switch --from e2b records where you came from, so runtime compare and Runtime know what you left. Your credit is matched as everyone's is. runtime switch on its own shows the match: how much is used and left, and how long you have.

Once you have run on Runtime, runtime compare prices your own sandboxes both ways:

Terminalruntime compare --from e2b

It takes your settled sandboxes from the last 30 days (--days up to 90). It prices them at the rates you were quoted. It also prices the same vCPUs, memory and running time at the rival's published rates from the table above. Sandboxes that free usage paid for are priced at the standard rates. That is what the same work costs on paid credit, and the output says how many there were. Then it says what you save, and about how much that is a month. With no sandboxes yet, it prices an example and says so. It compares compute only. Storage, network, plan fees and free allowances are left out. The same figures come from GET /v1/usage/compare and the runtime_account MCP tool with action compare, in microdollars.

To compare a workload you have not moved yet, ask your agent:

“Compare my last 1,000 completed runs with Runtime. Use the same measured job behavior, include my current discounts and required features, show all inputs, and separate estimated savings from measured savings.”