Daytona vs Modal Sandboxes

Daytona

API keys with per-action scopes, so an agent can create sandboxes without being able to delete them. The container class shares the host kernel. Only the VM classes get their own.

Modal Sandboxes

GPU sandboxes at the same per-second rates as the rest of Modal. No REST API, and the JavaScript and Go SDKs are beta.

Daytona

1. Pick a Linux VM class for untrusted code or when memory must survive a pause. Container sandboxes stop and archive instead
2. Set autoStopInterval yourself. The 15-minute idle default can stop a sandbox while the agent is still thinking
3. Give the agent a key without delete:sandboxes if it shouldn't destroy work
4. Read Retry-After-{throttler} on a 429 before retrying sandbox creation
5. Check the organisation's tier before relying on outbound calls from inside the sandbox

Modal Sandboxes

1. Pass timeout= when you create a sandbox. The default lifetime is 5 minutes
2. Set block_network=True or a cidr_allowlist for untrusted code
3. Give a sandbox a name so a retried create raises AlreadyExistsError instead of starting a second one
4. Snapshot the filesystem before the 24-hour limit and start a fresh sandbox from it
5. Catch ResourceExhaustedError from Sandbox.create() on SDK 1.6.0 and later