SPACE vs Runloop Devboxes

SPACE

Once deployed, SPACE's native API has a public OpenAPI 3.1 contract, stable error codes with a retryable flag and 24-hour idempotency keys, and egress and credential controls sit outside the VM. A person must first deploy it on a Linux x86_64 host with KVM and Kubernetes. Version 0.8.0 has no tagged release, changelog or public container images.

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.

SPACE

1. Ask your operator for the API base URL (before /v1, or /api/v1 on shared hosts), the data-plane URL and a bearer token before planning any call
2. Poll the returned operation until it succeeds and the sandbox is running before creating a command. A 202 response is not readiness
3. Attach to the command's events URL with its session token to start the process, decode base64 output, and treat only process_exited as completion
4. Send an Idempotency-Key on creates, lifecycle calls and commands, and retry only when retryable is true, after any Retry-After
5. Save output as it arrives. Reconnecting with Last-Event-ID returns resync_required, not the missed output

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