Runtime vs Vercel Sandbox

• 80% cheaper CPU. Active CPU costs $0.025 an hour on Runtime and $0.128 on Vercel. Memory costs 65% less. Busier jobs save more. With both CPUs busy the whole minute, the example job costs $1.33 on Runtime and $5.68 on Vercel.
• It pauses itself when idle. After 300 seconds with no request, command, connection, traffic or CPU use, a Runtime sandbox pauses. While paused, it pays only paused storage, $0.08 per GB (10⁹ bytes) a month. The next request wakes it. Its processes keep running.
• A written uptime promise. Paid accounts get 99% API uptime a month, measured from outside. If a month falls short, 10% of that month's charges is returned as credit automatically (Uptime Promise).
• Memory survives a pause. A paused Runtime sandbox wakes with its processes still running, kept while you have credit. A stopped Vercel sandbox keeps its filesystem, and its processes start again.
• Forks keep memory too. A Runtime fork copies a running sandbox with its memory and running processes. A Vercel snapshot or fork captures the filesystem, so processes start again.
• Private ports by default. A Runtime preview gives a port an HTTPS address that needs a token unless you make it public. Vercel's exposed ports are reachable at a public URL.
• No platform to join. Runtime needs no hosting plan, team or project. Prepaid credit from $10 is the whole account.
• A one-line switch. withruntime/vercel runs code written for Vercel Sandbox's SDK, in JavaScript and Python: commands, files, ports, snapshots and persistent sandboxes, with no Vercel project or token. Credit you add within 30 days of signing up is matched, up to $1,000 in total.
• Single sign-on included. SAML or OIDC sign-in, SCIM, roles and an audit log come with every Runtime account (single sign-on). Vercel sells SAML single sign-on as an add-on for Pro teams and keeps directory sync for Enterprise.
• Your agent sets itself up. It runs npx withruntime sandboxes run -- ..., shows you a link, and starts once you approve in the browser. No API key goes into a prompt or a config file. The MCP server reuses the same connection.

Also included: a code interpreter, network allow and deny lists, secrets the sandbox never sees, custom images, volumes backed up daily, a Linux desktop, metrics, webhooks, OpenTelemetry export, S3, R2 and GCS bucket mounts, MCP servers from a catalog, and identity tokens for AWS and Google Cloud. Paid accounts add custom domains, TCP ports, dedicated outbound addresses and WireGuard private networks. See products.

Vercel's figures come from its public pricing and documentation, checked 25 October 2026, at the rates of its default iad1 region.

Take 1,000 runs of a 2 vCPU sandbox with 4 GiB on Runtime and 4 GB on Vercel, which gives 2 GB per vCPU. Each run lasts 60 seconds and keeps the CPU busy for 20 CPU-seconds. This is an agent that spends most of its time waiting for a model.

• Saving: 70%, or $1.49 per 1,000 runs.
• Per month: at 100,000 runs, $63.89 on Runtime against $212.44 on Vercel.
• Busier work: with both CPUs busy for the whole minute, $1.33 on Runtime against $5.68 on Vercel, a 77% saving.

A GiB is about 7% larger than a GB, so Runtime's memory figure covers slightly more. Creations, network, storage, plan fees, taxes and free allowances are excluded from both. On Runtime, inbound traffic is free. Each account's first 100 GiB out a month is free, then $0.02 per GB (10⁹ bytes). See pricing for Runtime's terms.

Give your coding agent the one instruction in migration. It replaces the Vercel calls on a branch, tests them on the free usage, and tells you what you save each month. Your old code stays on the main branch until you merge.

Change one import

Runtime's SDK runs code written for Vercel Sandbox's SDK. Change the import and set RUNTIME_API_KEY, or run npx withruntime login once:

TypeScriptimport { Sandbox } from "withruntime/vercel"; // was: from "@vercel/sandbox"

Pythonfrom withruntime.vercel import sandbox  # was: from vercel import sandbox

Sandboxes get Vercel's defaults: 2 vCPUs with 2048 MiB each, a 5-minute timeout, and persistence. So stop() pauses a sandbox, and the next call or Sandbox.get({ name }) wakes it. Ports listed at create get public addresses. domain(port) returns the address for that port. Sandboxes use the free usage first, then prepaid credit.

With no timeout, a sandbox has no time limit: it runs while it works. A timeout over an hour works too. The sandbox object moves Runtime's hour-long limit on toward it while your program runs. Users and groups (createUser, asUser) and list filters, sorting and cursors work as on Vercel. A call Runtime handles differently, such as Drives or other regions, throws NotSupportedError before anything happens. It names what to use instead. VERCEL.md in the package lists every mapping.

Or port the calls

Vercel Sandbox:

JavaScriptimport { Sandbox } from "@vercel/sandbox";const sandbox = await Sandbox.create();const command = await sandbox.runCommand("echo", ["hello"]);console.log(await command.stdout());await sandbox.stop();

Runtime:

TypeScriptimport { Sandbox } from "withruntime";const box = await Sandbox.create();try {  console.log((await box.exec("echo hello", { check: true })).stdout);} finally {  await box.stop();}

• Regions and scale. Vercel runs sandboxes in 19 regions, with up to 10,000 concurrent sandboxes on Pro. Runtime runs in one US region.
• Your app already lives on Vercel. Sandboxes then share its account, billing and observability.

Checked 23 September 2026; single sign-on and the firewall checked 27 September 2026.

• Vercel Sandbox pricing and quotas
• Vercel SAML single sign-on
• Vercel Sandbox firewall
• Understanding Vercel Sandboxes
• Runtime pricing, security and products