Pricing & Limits

SeaCloud Sandbox usage is metered around reserved runtime resources, paused persistent storage, and network transfer. Billing uses the configured sandbox spec rather than opportunistic burst usage.

Resource Model

Reserved baseline, plus best-effort burst. Every sandbox reserves its full configured vCPU and memory — capacity is never oversubscribed, so your configured baseline is always available. When the underlying host has spare CPU, a running sandbox may opportunistically burst beyond its configured cores at no extra cost — billing is based on your configured spec, not measured utilization. Burst capacity is best-effort and not guaranteed; under contention every sandbox still receives its full reserved allocation. Do not design latency-critical paths around burst.

Metering Dimensions

Billing item	Metered when	Unit
CPU Running	Only after the sandbox is ready/running	vCPU-second
RAM Running	Only after the sandbox is ready/running	GiB-second
Sandbox Storage	Only while `paused`	GiB-hour
Data Transfer	When traffic is transferred	GB

Running sandboxes are not charged separately for storage. Temporary runtime storage is included in compute while the sandbox is running.

Pricing can vary by plan and deployment. Use Console billing data and the usage APIs as the source of truth for charged totals. The current usage_costs_usd value is computed from runtime CPU, runtime RAM, and data transfer usage; storage usage is exposed separately through storage usage fields and storage records.

Free Allowance

Item	Free allowance
Sandbox Storage	`10 GiB` per account

Pricing Example

Ten sandboxes, each configured as 1 vCPU + 1 GiB, running for 5 min:

CPU usage: 1 vCPU * 300s = 300 vCPU-s
RAM usage: 1 GiB * 300s = 300 GiB-s
Total for 10 sandboxes: 3000 vCPU-s and 3000 GiB-s
Storage while running: $0

Default Runtime Limits

These are the current platform defaults.

Limit	Default
Per-user held sandboxes	`20`
Per-user `running + starting` sandboxes	`10`
Sandbox start rate	`1 QPS`
Max continuous sandbox runtime	`3600s`

Create/start requests above the start-rate guardrail return 429. Use bounded retry with backoff instead of parallel retry storms.

Default Resource Limits

Resource	Current contract
Sandbox CPU	`1-8` vCPU, integer
Sandbox memory	`512-8192MiB`, step `512MiB`
Sandbox storage	`1GiB`
CPU:RAM ratio	`1:0.5` to `1:4`

Query Current Sandbox Limits

GET /usage/limits
X-API-Key: <SEACLOUD_API_KEY>

The response reports user-level quota usage:

{
  "resource": "sandboxes",
  "unlimited": false,
  "user": {
    "usage": {
      "held": 2,
      "running": 1
    },
    "limits": {
      "held": { "limit": 20, "used": 2, "remaining": 18, "enforced": true },
      "running": { "limit": 10, "used": 1, "remaining": 9, "enforced": true }
    }
  },
  "runtime": {
    "maxRuntimeSeconds": 3600
  }
}

Limit Terms

Field	Meaning
`held`	Sandboxes that are not deleted or destroying.
`running`	Running plus starting sandboxes, matching create/start enforcement.
`enforced`	`false` means the value is visible for planning but not enforced.
`unlimited`	Whether the quota is uncapped for the caller.
`maxRuntimeSeconds`	Maximum lifecycle duration the platform reports for the caller.

When A Quota Is Hit

Create/start requests can return 429 with details such as scope, resource, metric, used, limit, remaining, and usageEndpoint. Use the returned endpoint before retrying.

{
  "code": 429,
  "message": "sandbox limit exceeded",
  "details": {
    "reason": "usage_limit",
    "scope": "user",
    "resource": "sandboxes",
    "metric": "running",
    "used": 10,
    "limit": 10,
    "remaining": 0,
    "usageEndpoint": "/usage/limits"
  }
}