Runloop Devboxes vs Together Code Sandbox

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.

Together Code Sandbox

Two public OpenAPI documents, MIT clients for Python and TypeScript, cursor pagination and built-in retries make the surface easy for an agent to drive. Access is the limit. Together enables the SDK per organisation on request, publishes no rate limits or SLA, and neither status page names the sandbox service.

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

Together Code Sandbox

1. Confirm the organisation is on Together's allowlist before installing. A valid TOGETHER_API_KEY alone is not enough
2. Build a snapshot first with snapshots.create. No default image exists, and every sandbox needs snapshot_id or snapshot_alias
3. Set ttl at creation or call terminate(). Nothing stops a sandbox otherwise, and closing the Python client leaves it running
4. Store the snapshot alias, not the sandbox ID. A terminated sandbox can't restart, and its state lives at sandbox:<id>
5. Exclude snapshots.create from retries with should_retry, and set experimental.network_policy before serving anything private on a port