E2B vs Sprites

E2B

Firecracker microVM with its own kernel per sandbox. Two major incidents over an hour in September 2026, on sandbox creation and on creating from snapshots.

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.

E2B

1. Set a timeout when you create a sandbox. The default is 5 minutes
2. Pause rather than kill when you'll come back. Resume takes about a second and nothing is billed while paused
3. Use Secret.fill in network transforms instead of passing API keys into the sandbox environment
4. Pace sandbox creation. Hobby allows 1 a second and 20 running at once
5. Move to the v2 sandbox endpoints. SDK 2.51.0 and later use them by default

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