Daytona vs Maritime

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.

Maritime

Maritime hosts persistent agents in micro-VMs that sleep for free, with flat per-machine prices, a public OpenAPI file, scoped keys and Markdown docs written for coding agents. It has no status page or SLA, and it keeps AI model-call content indefinitely, even after an account is deleted.

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

Maritime

1. Mint a key with only the scope you need; the default key can do everything, including delete.
2. Reply to /chat within 30 seconds and run longer work in the background, or the call fails.
3. Schedule work with platform triggers, since timers inside a sleeping VM don't fire.
4. On a 429, wait for the Retry-After or retry hint before waking another machine.
5. Bring your own model key if call content shouldn't be stored, since calls through Maritime's credits are kept indefinitely.