Per-second billing, explained: why a 20-second sandbox costs $0.00055

"Billed per second" is one of those phrases that sounds complete and isn't. Behind it sit several decisions that change what you pay: what is being metered, when the clock starts and stops, whether there is a minimum, how fractions of a cent are handled, and when money actually leaves your balance.

This post writes down our answers, with the arithmetic, for code sandboxes. The goal is that you can predict a bill to the cent before you run anything, and recognise the point where per-second billing is the wrong model for your workload.

The unit: reserved vCPU and RAM

A sandbox's price is the price of the resources its tariff reserves:

• $0.040 per vCPU-hour
• $0.013 per GiB of RAM per hour

The small tariff (0.5 vCPU, 1 GB) therefore costs 0.5 × 0.040 + 1 × 0.013 = $0.033 an hour, or about $0.0000092 a second. The largest, max (8 vCPU, 16 GB), costs $0.528 an hour.

We meter reservation, not consumption. A sandbox waiting for its next command costs the same per second as one compiling a project. Metering actual CPU would look fairer on paper, but it makes the price impossible to know in advance, and the capacity is held for you either way. Outbound traffic isn't billed.

The clock: creation to deletion

An ephemeral sandbox is billed from the moment it is created until it is deleted. That includes time it spends idle before the idle timeout removes it, 300 seconds by default.

This is where most surprises come from. A script that takes two minutes, in a sandbox nobody deletes, is billed for seven: two of work and five waiting for the timeout. The fix is boring: delete the sandbox when you're done (the SDK's with block does it for you) or lower the idle timeout.

The minimum: 60 seconds per sandbox

Every ephemeral sandbox is billed for at least 60 seconds of its lifetime. Starting a microVM, attaching its disk and network and tearing it all down again costs the same whether the code inside runs for one second or fifty.

The minimum is applied once, when the sandbox ends, and only if its total lifetime was shorter than 60 seconds. There is no per-hour or per-command minimum on top.

Accrual and debit: micro-dollars and whole cents

Here is the part that "per second" usually doesn't tell you. The sandbox host records usage in hourly buckets, one per sandbox. Once a minute, the billing job collects the buckets that have closed, prices them and debits the balance.

Pricing happens in millionths of a dollar. The debit happens in whole cents. Whatever is left under a cent stays on your account and is added to the next debit; it isn't rounded up per sandbox or per hour.

That matters at small scale. A hundred 20-second sandboxes accrue 100 × $0.00055 = $0.055. You are debited five cents, and half a cent waits for the next batch. If each sandbox were rounded up to a cent, the same work would cost a dollar.

Two more properties are worth knowing:

• Each bucket is charged exactly once. The usage record and the debit are written in one database transaction, keyed by sandbox and hour. A retried run or a lost confirmation can't charge twice.
• Outages delay charges, they don't lose or duplicate them. If the billing side can't reach the sandbox host, nothing is confirmed, buckets wait, and they're charged when the connection returns.

The consequence is that the dashboard can lag the live figure by up to an hour. For the live number, GET /sandboxes/{id}/usage returns billed_usd and an estimated_total_usd for the sandbox so far.

Persistent sandboxes: per started hour, with a cap

Persistent sandboxes keep their disk between sessions, for up to 30 days. They are billed per started hour: 61 minutes are two hours. In exchange, a calendar month (UTC) never costs more than 730 hours minus 25%.

For the standard tariff that cap is $36.14 a month instead of $48.18. While a persistent sandbox is paused, it isn't billed at all.

When the balance runs out

The balance never goes below zero. New sandboxes are refused with 402 insufficient_balance. Ephemeral sandboxes already running finish at their idle timeout or TTL. Persistent ones are paused after 24 hours without a top-up and resume on their own when you add funds. Paused snapshots are kept for 14 days. After that the sandbox is deleted and its id returns 410 sandbox_deleted.

If an AI agent creates sandboxes for you, set a daily and monthly cap. Hitting a cap returns 429 budget_exceeded with the time it resets, which a program can act on.

Where per-second billing loses

Per-second billing is excellent for work measured in seconds and minutes. It gets worse the longer the work runs.

The crossover is roughly where a workload runs more than a few hours a day. Past that point you're paying for flexibility you don't use, and a server rented by the month is cheaper per hour by a wide margin. The fair way to think about per-second billing is as a price for not having to plan capacity, not as a discount.

A quick way to estimate

Price per hour of the tariff × seconds the sandbox will exist ÷ 3600, with 60 seconds as the floor. Add the idle timeout if you won't delete it yourself. For persistent sandboxes, round each session up to whole hours and stop at the monthly cap.

The full rules, quotas and the budget API are in sandbox limits and billing; the calls used above are in the SDK reference. If you're wondering what you're actually renting by the second, Firecracker microVMs explained covers that, and what AI agents need from infrastructure looks at why the billing model matters so much once software, not people, is creating the machines.