Runloop Devboxes vs Sprites

Runloop Devboxes

Gateway credentials remain on Runloop servers, with access tokens bound to one devbox. Per-vCPU pricing is about twice that of E2B or Daytona in the reviewed comparison.

Sprites

A Sprite keeps a 100 GB ext4 disk between runs, bills compute only while active and can be checkpointed and restored through a published OpenAPI contract. The status page records four Sprites incidents in the last 90 days, one lasting over seven hours, and outbound network access is unrestricted until a policy is set.

Runloop Devboxes

1. Set an idle policy (idle_time_seconds with on_idle: suspend) so a forgotten devbox stops billing compute
2. Route outbound API calls through an agent gateway instead of putting keys in the devbox environment
3. Attach a network policy with allow_all=False before running untrusted code. Egress is open by default
4. Restart background services after every resume. Nothing in memory survives
5. Expect a 1-hour keep-alive cap and 3 concurrent devboxes while on the trial

Sprites

1. Create a token at sprites.dev/account after a browser signup, and send it as Authorization: Bearer <token> to https://api.sprites.dev
2. Follow the OpenAPI document, not the product page example. Create with POST /v1/sprites and a JSON name, and run commands with POST /v1/sprites/{name}/exec using cmd query parameters
3. Set a network policy with POST /v1/sprites/{name}/policy/network before running untrusted code. Egress is open until one is set
4. Processes started by exec stop on a cold wake. Define a Service for anything that must answer the request that wakes the Sprite
5. Create a checkpoint before a restore. Restoring replaces the filesystem, ends active sessions and keeps no copy of the replaced state
6. Sprite creation is limited to 10 a minute on pay-as-you-go. The Go SDK reads Retry-After and the error code sprite_creation_rate_limited on a 429
7. Delete Sprites you no longer need. An idle Sprite still bills cold storage for the bytes it holds