Sprites vs Vercel Sandbox

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.

Vercel Sandbox

Active CPU billing, so waiting on model responses costs only memory. Tied to a Vercel team and project even when called from elsewhere, and access tokens reach the whole team.

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

Vercel Sandbox

1. Call sandbox.stop() when the task is done. Memory bills until the session ends
2. Use Sandbox.getOrCreate with a name so retries land in the same sandbox
3. Set networkPolicy to deny-all for untrusted code. The default is allow-all
4. Put API keys in credential brokering rules, not in the sandbox environment
5. Pass persistent: false for one-off runs so no snapshot is stored or billed