Sandal vs. E2B, Daytona, Depot, Blacksmith, Limrun, run.cloud

Most "vs" pages are written to win. This one is written to be correct, including the parts where a competitor is genuinely a better fit than Sandal. If our numbers ever drift from what's true, file an issue and we'll fix the page.

The short version#

No other company in this table spans sandboxes + CI runners + mobile simulators + code interpreter on one SDK. That's the actual difference, not a bigger benchmark number, and it's what lets active-CPU + provisioned-RAM billing pool utilization across bursty daytime sandbox load, bursty weekday CI load, and interactive simulator sessions on the same fleet, which is where the pricing gap in the worked example below comes from.

vs. E2B#

E2B is the sandbox category leader, 1B+ sandboxes started, 94% of the Fortune 100, an open-source infra repo, and a genuinely tight three-namespace SDK (commands, files, pty). If you specifically want the most battle-tested, most widely-integrated sandbox product with an active OSS community and BYOC for enterprise VPC isolation, E2B is a very reasonable choice today.

Where Sandal differs:

• Billing model. E2B bills wall-clock CPU-seconds and RAM-seconds regardless of whether the CPU is actually doing work. Sandal bills per second while the sandbox runs, and paused sandboxes are $0, for agent workloads that spend a lot of time waiting on a model response between tool calls, that's a materially different bill.
• Surface. E2B is sandboxes and code interpreter only. If you also run CI or need mobile simulators, that's a second and third vendor relationship.
• Hardware economics. E2B doesn't publish its underlying infrastructure provider. Sandal runs on Hetzner/OVH/Leaseweb bare metal, which is the source of the price gap, not a markup difference.

Stay with E2B if: you need BYOC (templates/snapshots/logs inside your own VPC) today. Sandal doesn't yet offer a BYOC tier, or you're already deep in their open-source infra and want to self-host.

vs. Daytona#

Daytona's sub-90ms creation number is real, but it's measured on their container fast-path, not their microVM/GPU tier, worth knowing before you compare it directly against a Firecracker or Cloud Hypervisor number, since containers and microVMs give you different isolation guarantees for the same latency budget. Their docs organization (Agent Tools / Human Tools / System Tools) is genuinely a good mental model and their namespace breadth (process, fs, git, code_interpreter, computer_use, snapshots, volumes) is the most complete single-vendor surface in the sandbox category.

Where Sandal differs:

• Isolation is uniform. Every Sandal sandbox is a Firecracker/Cloud Hypervisor microVM with its own kernel, there's no fast-path/slow-path split to keep track of. See Isolation tier honesty below.
• Pricing model. Daytona bills $0.0504/vCPU-hr + $0.0162/GiB-hr flat, with no pause discount built into the headline rate. Sandal's paused-is-$0 model rewards the idle-between-turns pattern that most coding agents actually exhibit.
• One SDK, three surfaces. Daytona doesn't offer CI runners or mobile simulators.

Stay with Daytona if: you specifically want their LSP/computer-use/VNC tooling bundled in, or the container fast-path's raw creation speed matters more to your workload than uniform microVM isolation.

vs. Depot#

Depot is not really a sandbox-first competitor, it's a build-cache and CI-acceleration company (Depot Metal, Depot CI, cache volumes) with a sandbox product bolted on, and its runner benchmarks against public repos (published YAMLs, both sides) are the best evidenced numbers in the category. Depot Metal's disaggregated NVMe-over-TCP storage architecture is a legitimately sophisticated piece of infrastructure engineering, and their "40x builds, 10x Actions" claims are backed by continuously-run public benchmark repos, not marketing copy.

Where Sandal differs:

• Product breadth. Depot's core strength is build acceleration; runners and sandboxes are downstream of that. Sandal is agent-infrastructure-first: sandboxes, runners, simulators, and interpreter are peers, not a cache product with extensions.
• Runner pricing. Depot's Linux runner floor is $0.004/min (2vCPU) up to $0.128/min (64vCPU); Sandal's Linux runner floor is $0.003/min (2vCPU), lower at the small end where most CI matrices actually run.
• No simulator product. Depot has no mobile simulator offering.

Stay with Depot if: your bottleneck is genuinely build/cache performance rather than raw compute cost, or you're already using Depot Metal's sticky-cache-volume model and don't want to re-architect your CI caching strategy.

vs. Blacksmith#

Blacksmith is the strongest public validator of the utilization thesis behind bare-metal agent infrastructure, their published gross-margin curve (roughly 35% at 10% utilization, climbing to 85%+ at 35% utilization) is exactly the economics that make multi-surface pooling (sandboxes + runners + simulators sharing one fleet) worth building. They run Firecracker per job on leased bare-metal gaming CPUs and are genuinely fast and well-proven at scale (50M+ jobs/month, 3k orgs).

Where Sandal differs:

• Runner-only vs. full platform. Blacksmith is CI runners exclusively, no sandboxes, no simulators, no interpreter. If a runner swap is literally the only thing you need, they're a focused, mature option.
• Pricing is close, not identical. Blacksmith Linux is $0.004/min vs. Sandal's $0.003/min; Blacksmith macOS M4 is $0.08/min vs. Sandal's $0.06/min. Both are meaningfully cheaper than GitHub-hosted; the gap between us is smaller than the gap to hyperscaler-hosted runners.

Stay with Blacksmith if: CI runners are your only need and their sticky-disk/CoW-snapshot workflow-caching model already fits your pipeline, there's no reason to add a second vendor for capability you won't use.

vs. Limrun#

Limrun is the most credible mobile-simulator specialist in this list, real Macs running Simulator/xcodebuild (not emulated), delta source sync with server-side dependency resolution, per-instance scoped tokens with one MCP server per instance (never an org key in the browser), and a genuinely well-designed <RemoteControl/> React component. If mobile is your whole product surface, their depth on that one thing is real.

Where Sandal differs:

• Surface. Limrun is simulators only, no sandboxes, no CI runners, no interpreter.
• Published pricing. Limrun has no public rate card (sales-gated); third parties estimate roughly $0.06/Android-min and $0.12/iOS-min. Sandal publishes $0.015/active-minute for both platforms on our pricing page, no sales call required to know what you'll pay.
• Token/session model. Sandal's DPoP-scoped per-instance tokens are directly inspired by (and functionally comparable to) Limrun's per-instance-token approach, this is one place we followed their lead rather than diverging.

Stay with Limrun if: you need the deepest possible native-Mac fidelity for iOS-specific CI (their delta-sync and dependency resolution is more specialized than a general sandbox/simulator platform will offer) and public pricing isn't a blocker for you.

vs. run.cloud#

run.cloud is the closest structural analog to Sandal on paper, sandboxes plus simulators, KVM Firecracker, paused-is-$0, active-CPU-style physical-core metering, and (to their credit) ten honest /compare/<competitor> pages with real compat shims (runcloud.compat.e2b). We borrowed the "stay with X if you need Y" framing on this very page from their approach, because it's the right way to write a comparison page.

Where Sandal differs:

• CI runners and docs. run.cloud has no GitHub Actions runner product and, as of this writing, no dedicated docs site or engineering blog, their technical depth is crammed into marketing pages, which caps how far it can go. Sandal ships full docs, an llms.txt, and every doc page mirrored as .md.
• Pricing is close on sandboxes, cheaper on simulators here. run.cloud sandboxes run roughly $0.0237/hr at 1 vCPU/2GiB; Sandal's smallest sandbox tier is priced comparably per-core. run.cloud simulators are $0.02/active-minute; Sandal is $0.015/active-minute.
• Runner gap fills the platform. Because run.cloud doesn't do CI, teams that need sandboxes + runners + simulators in one SDK still end up with two vendors on run.cloud and one on Sandal.

Stay with run.cloud if: you specifically want their camera/mic-passthrough "cloud phone" framing for simulator work, or you're already using one of their compat shims and a migration isn't worth it yet.

Price, worked#

The 50-agent fleet example from Pricing sized against a comparable always-on, wall-clock-billed sandbox provider at 4vCPU/8GB, 240 active-agent-hours/month per agent, 50% actual utilization:

The gap isn't a discount, it's that most of those 240 hours per agent are spent paused between turns, and wall-clock billing charges for that idle time while per-second billing doesn't. Run your own numbers against the rate card.

Isolation tier honesty#

Not every "sandbox" in this market means the same thing, and the marketing copy across the industry doesn't always make the isolation boundary obvious. Three tiers show up under the same word:

1. Containers (shared host kernel, namespace + cgroup isolation), fastest to boot, weakest isolation boundary. Fine for trusted or low-risk code; not what you want for arbitrary untrusted agent output.
2. microVMs (Firecracker, Cloud Hypervisor, gVisor with its own syscall interception), dedicated kernel per instance, hardware-virtualization-backed boundary, still fast enough for sub-second cold starts. This is Sandal's isolation tier for every sandbox, runner, and interpreter session, with no fast-path exception.
3. Real hardware / dedicated VMs, used by mobile simulator providers (Limrun, Sandal, run.cloud) where the workload (Xcode Simulator, Android emulator) needs a real Mac or a persistent VM rather than a microVM.

When a competitor's headline latency number comes from a container fast-path (Daytona's ~90ms) rather than their microVM tier, that's not dishonest, but it is a different isolation guarantee than the number implies if you assume "sandbox" always means "own kernel." We publish which tier backs every number on this page so you can compare apples to apples: Sandal sandboxes, runners, and interpreter sessions are always Firecracker/Cloud Hypervisor microVMs, never a container fast-path standing in for the marketing number.

Evidence#

Every claim on this page traces back to a specific source: the competitor's own pricing page, docs, or engineering blog, captured and cross-checked against Sandal's live rate card. Competitor pricing and architecture claims can and do change, if something here is stale, tell us and we'll correct it, not just quietly remove the comparison.