Sandbox pricing and limits

Sandboxes are paid from the same prepaid balance as servers. There's no subscription and no card on file: you top up, sandboxes draw from it, and when it's empty they stop. This page is the arithmetic behind that. For what a sandbox is, start with Sandboxes; for the code side, the SDK reference.

What you pay for

The price of a sandbox is the price of the vCPU and RAM its tariff reserves:

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

You pay for the reservation, not for CPU actually burned. A sandbox that sits idle costs the same per second as one that's compiling. Outbound traffic isn't billed. Live prices, without a token: GET /sandboxes/tariffs.

Ephemeral: per second, 60 seconds minimum

An ephemeral sandbox is billed for every second it exists, from creation to deletion, with a minimum of 60 seconds per sandbox.

The third row is the one people miss: the idle timeout counts. Delete the sandbox when you're done (the SDK's with block does it for you), or set idle_timeout low.

Persistent: per started hour, with a monthly cap

A persistent sandbox keeps its disk between sessions, for up to 30 days. Each started hour is billed in full: 61 minutes cost two hours. In return, a calendar month (UTC) never costs more than 730 hours minus 25%, which is the last column of the table above. A standard sandbox that runs all month costs $36.14, not $48.18.

While a persistent sandbox is paused (see below), it isn't billed.

When the balance runs out

1. New sandboxes are refused with 402 insufficient_balance.
2. Ephemeral sandboxes already running finish as usual, at their idle timeout or TTL.
3. Persistent sandboxes are paused after 24 hours if you haven't topped up. Pausing saves the sandbox to a snapshot on disk; a paused sandbox costs nothing.
4. Top up and they resume on their own, usually within a minute. Commands sent to a paused sandbox get 409 sandbox_paused meanwhile.
5. Paused snapshots are kept for 14 days. After that the sandbox is deleted and its id returns 410 sandbox_deleted.

The balance never goes below zero.

Spending caps

By default there is no cap. You can set a daily and a monthly limit, in dollars, in the dashboard or over the API:

curl -X PUT https://api.eqvps.com/api/v1/eqvps/sandboxes/budget \
  -H "Authorization: Bearer $EQVPS_API_KEY" -H "Content-Type: application/json" \
  -d '{"daily_usd": 2, "monthly_usd": 20}'

Both fields are required; null means no limit. Days and months are counted in UTC. When a cap is reached, new sandboxes get 429 budget_exceeded (with limit_usd, spent_usd and resets_at in the response), running ephemeral sandboxes are deleted and persistent ones are paused with their disk kept. They resume when the period resets or you raise the cap. Unlike pauses for an empty balance, a budget pause isn't deleted after 14 days.

If an AI agent creates sandboxes on its own, set a cap. It's the difference between a bad night and a bad month.

The $1 trial

A new account gets $1 of sandbox credit the first time it creates a sandbox without enough balance. That's about 30 hours of small or 60 hours of micro. The credit lasts 14 days, works only for sandboxes, is spent before your own money and can't be withdrawn. One trial per account.

All quotas in one place

The CPU rule exists because sandboxes share hardware. An ephemeral sandbox that breaks it is stopped; a persistent one is slowed down. Bursty work never comes near it. Hours of full-load computation belong on a VPS, where you rent the cores for the month.

Checking what you've spent

usage() in the SDK, or GET /sandboxes/{id}/usage, shows a sandbox's running seconds, CPU seconds used, outbound bytes, billed_usd and estimated_total_usd. Charges land on the balance in hourly batches, so the dashboard can lag the live figure by up to an hour. To try the numbers on a real sandbox, the sandbox page has everything you need to start.