Pricing

How billing works#

Sandal bills per second, not per hour and not per "instance-month." Three primitives drive every invoice:

• Active CPU, metered while a sandbox, runner, or simulator is actually scheduled and running work. Idle CPU inside a running sandbox (e.g. waiting on I/O) is not billed at the active rate.
• Provisioned RAM, metered for however long memory is reserved, whether the sandbox is busy or idle. This is what keeps a sandbox "warm" and ready for a sub-200ms claim.
• Paused / hibernated = $0, call sb.pause() (or let a sandbox idle past its TTL into a snapshot) and both active-CPU and provisioned-RAM billing stop. You pay only for the encrypted snapshot's storage, billed separately at a flat per-GB-month rate.

Because we run on Hetzner, OVH, Leaseweb, and dedicated Mac minis instead of hyperscaler on-demand pricing, the underlying compute cost is a fraction of what AWS/GCP-based sandbox platforms pay, and we pass that through directly.

$ npx sandal init

Sandboxes (Firecracker microVMs)#

Billed per second for every second a machine is running. Every sandbox is its own kernel, no shared-kernel discount, no shared-kernel risk.

Custom shapes (GPU-attached, >32GB RAM) are available on request, talk to us.

Fork operations (sb.fork()) create a new billing entity from a shared base snapshot; you're charged for the child's active time only, not a copy of the parent's history.

GitHub Actions runners#

Drop-in runs-on: label swap. JIT-registered per job, billed per minute of job runtime, no monthly minute bundles to track separately from usage.

Runner pools (sandal.runners.pools.create) with minWarm keep N runners hot to eliminate cold-start queueing; warm-held runners bill at the provisioned-RAM rate only, not the full active rate, while idle in the pool.

iOS / Android simulators#

$0.015 per active minute, streamed at 60fps. "Active" means a session is attached (via <RemoteControl/>, Appium, or ADB), a simulator sitting warm with no client attached is not billed as active.

Code interpreter#

Same Firecracker isolation and per-second billing as sandboxes, sized for short-lived execution: sandal-micro rates apply by default, billed to the second the interpreter session is open.

Credit packs#

Prepaid credit packs never expire. Buy once, draw down against any product (sandboxes, runners, simulators, interpreter) at the rate card above, no separate SKU per product.

Plan minutes#

Subscription plans bundle a monthly allotment of active-compute minutes at a lower blended rate than pay-as-you-go, with overage billed at standard rate-card pricing. Unused plan minutes do not roll over (use credit packs for banking usage across months).

See Limits for the full concurrency and start-rate table per plan.

Worked cost examples#

Single agent, always-on sandbox, one working day 4 vCPU / 8 GB sandbox, active 8 hours, paused the remaining 16 hours: 8h × $0.03/hr = $0.24/day (paused hours are $0).

CI migration: 500 Linux jobs/day, avg 6 min each 500 × 6 min × $0.003/min = $9.00/day ($270/mo), versus GitHub-hosted 2-core runners at $0.008/min for the same job mix ($720/mo), roughly 60% lower at this volume before any pool warm-start savings.

50 agents × 240 hours/month (a fleet of long-running coding agents)

Assume each agent's sandbox is active 50% of a 240-hour on-call window (the rest paused between turns) on a sandal-standard (4 vCPU/8GB) shape:

• Active compute: 50 agents × 120h active × $0.03/hr = $180/mo
• Paused hours: 50 agents × 120h paused × $0 = $0
• Total: $180/mo for 12,000 sandbox-hours of on-call agent capacity.

The same fleet held "always-on" (no pause) on a comparable hyperscaler-backed sandbox provider, no active/paused billing split, 24/7 instance-hour pricing, typically lands in the $1,700–$2,600/mo range for equivalent 4 vCPU/8GB instances, since idle time is charged at the full instance rate rather than $0. The gap is the whole point of active-CPU + provisioned-RAM metering: agents that pause between turns should cost nothing while paused.

Notes on evidence#

Every number on this page is generated from qualification runs against production rate cards, not marketing estimates. If a number here ever drifts from the live billing dashboard, the dashboard is correct, file an issue and we'll fix the page.