Vercel Sandbox's Active-CPU Meter vs a €4.99 Hetzner Box: the Breakeven Is 8 Sessions a Day

Vercel will sell you compute by the second your code is actually executing — and bill the memory for every second it merely exists. That asymmetry is the whole story of Vercel Sandbox pricing, and once you do the arithmetic on it, a steady stream of AI-agent sandbox sessions crosses the cost of an owned Hetzner box at roughly eight sessions a day.

Vercel Sandbox went generally available on January 30, 2026: Firecracker microVMs for running untrusted or agent-generated code, with per-session isolation, snapshotting, and an SDK. The pricing meter is genuinely clever — Active-CPU billing means the long pauses while an agent thinks, waits on a tool result, or idles between commands cost nothing on the CPU line. But the meter has four lines, not one, and only the CPU line is active-metered. Run the numbers on the shape a deploy-from-chat workflow actually produces — short sessions, low CPU duty cycle, memory provisioned the whole time — and the "you only pay when the CPU is busy" pitch loses to flat hardware fast.

The meter, exactly​

Four billable dimensions, from Vercel's Sandbox pricing (Pro rates; Hobby includes a small monthly allotment of each):

Session caps bound the shape further: 45 minutes maximum on Hobby, up to 5 hours on Pro/Enterprise (the SDK README cites up to 24 hours), with a ~5-minute default timeout. At launch the service ran in a single region (US East). No GPU tiers — this is CPU-only sandboxing.

The design intent is clear and honest: agent workloads are bursty inside a session — a flurry of tool calls, then seconds of model thinking — and wall-clock billing would charge for all that dead air. Active-CPU metering fixes exactly that. What it does not fix is the memory line, which accrues for every minute the sandbox is alive whether the CPU is hot or not.

The catch hiding in the price list: memory bills wall-clock​

Take the canonical deploy-from-chat session: a 10-minute sandbox, 2 vCPU / 4 GB, of which the CPU is actually executing for about 2 minutes (a 20% duty cycle — generous to Vercel, since model think-time dominates real agent loops):

Memory — the line nobody quotes — is 62% of the bill. The active-CPU discount applies to the smaller half of the cost, while the larger half meters the idle time the headline feature was built to forgive. That is not a flaw in the product; idle RAM really is reserved capacity. But it means the effective price of a sandbox session is dominated by how long the session stays alive, not how hard it works — which is uncomfortably close to wall-clock billing wearing a friendlier name.

The sensitivity runs one way. Hold the 10-minute session fixed and vary the duty cycle (transfer excluded for clarity):

Even at near-zero CPU usage the session cannot get cheaper than ~$0.014 — the memory floor. Active metering compresses the CPU slice; it cannot touch the floor.

The breakeven: about eight sessions a day​

Now price the same workload as ordinary scheduled pods on owned hardware. A Hetzner CX23 (2 vCPU, 4 GB — the post-January-2026 successor to the deprecated CX22) costs €4.99/month, roughly $5.40, with 20 TB of included traffic and hourly billing capped at the monthly price.

How many sandbox sessions fit on it? At 100 sessions a day × 10 minutes each, the fleet carries 1,000 session-minutes a day — an average concurrency under one session. A single CX23 absorbs that with headroom; a CPX31-class box (4 vCPU / 8 GB, on the order of €11/month) absorbs several times it.

Monthly Vercel cost at ~$0.024 per session:

The breakeven lands around 225 sessions a month — roughly eight 10-minute sessions a day. Past that, every additional session is pure margin to the meter and pure free capacity to the box. At 100 sessions a day the meter costs 13× the flat box; at 1,000 a day, 130×.

Push to the continuous extreme and the gap stops being a gap and becomes a category error. One always-on 2 vCPU / 4 GB sandbox-equivalent at a 30% active duty cycle: CPU = 2 × 730 × 0.3 × $0.128 ≈ $56.06, memory = 4 × 730 × $0.0212 ≈ $61.90 — roughly $118/month against €4.99. More than 20×, for capacity that never sleeps either way.

Context from the neighbors: the ~40% crossover​

Vercel is not the only meter in this market, and the comparison sharpens the point. E2B and Daytona bill roughly $0.0504/vCPU-hour plus $0.0162/GiB-hour on wall-clock per-second metering — cheaper per unit than Vercel, but charging idle CPU too.

For our 10-minute reference session, E2B's CPU line is fixed at 2 × (10/60) × $0.0504 = $0.0168 regardless of duty cycle, while Vercel's CPU line scales with activity. They cross where 2 × (a/60) × $0.128 = $0.0168 — at about 3.9 active minutes, i.e. a ~40% duty cycle. Below ~40% duty, Vercel's active meter beats E2B/Daytona wall-clock; above it, plain per-second billing wins. Modal sits off to the side at ~$0.1419/core-hour with per-second billing — and remains the only one of the four with first-class GPU sandboxes.

But notice what none of them escape: the memory floor. E2B's memory line for the same session is 4 × (10/60) × $0.0162 = $0.0108 — actually cheaper per GB-hour than Vercel's $0.0141.

Every managed sandbox meter charges something for session lifetime, because reserved RAM is reserved RAM. The meters differ in how they price busyness; they agree in charging for aliveness. Only owned hardware — where idle capacity is a sunk cost, not a line item — sidesteps the question entirely, which is the same conclusion this list's E2B/Daytona/Modal entry already mapped for continuously-running compute.

Where Vercel still wins, honestly​

None of this makes Sandbox a bad product. Below the breakeven — a side project generating a handful of agent sessions a day, a demo with bursty trickle traffic, a team whose sandbox demand is zero most weeks and spiky during a launch — the meter is cheaper than any box, with zero ops, per-session Firecracker isolation stronger than anything a shared pod pool gives you by default, and scale-to-zero that an owned fleet can only imitate with node autoscaling and patience.

The free allotment stretches the meter further than it looks: 5 Active-CPU-hours a month covers roughly 75 of our reference sessions on the CPU line (each burns 2 × 2/60 ≈ 0.067 CPU-hours), with 420 GB-hours of memory covering far more. A weekend experiment may never leave free tier. The 45-minute Hobby cap even enforces a healthy discipline: chunk long agent runs into short sessions, which is also the shape that minimizes the memory floor.

The honest decision rule is a volume question, not a technology verdict. If your sandbox demand is sporadic, buy the meter — Active-CPU pricing genuinely is the cheapest way to run five sessions a week. If your deploy-from-chat workflow succeeds — steady daily sessions, a team of agents doing real work — the meter becomes a success tax, and the same sessions as scheduled pods on a Cluster-API fleet you own cost a flat few euros whether they run eight times a day or eight hundred.

"You only pay when the CPU is busy" is true, and it is also incomplete. You pay for memory whenever the session is alive — and sessions, unlike CPU bursts, are alive most of the time.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent sandbox sessions are just scheduled pods on a Cluster-API fleet you control: no per-second meter, no memory floor, no success tax. Star the repo on GitHub or deploy your first app today.