TL;DRThe cloud landscape post (order 7) of the Sandbox Series. Summarizes positioning, pricing, cold start, isolation strength, and applicable scenarios for E2B, Daytona, Runloop, Vercel, Cloudflare, Modal, AWS Bedrock AgentCore, Alibaba OpenSandbox, Azure Container Apps — with a selection decision matrix.
Series: Sandbox Series (7 / 30)
🌏 中文版
What This Post Is
This post is the "cloud landscape" post (order 7) of the Sandbox Series. It doesn't dive deep into a single provider's technical details (provider deep dives are in order 8–16). Instead, it lays out the major cloud sandbox providers side by side to help you answer:
- What does each provider position itself for? — What type of agent workload is each suitable for?
- What are the pricing model differences? — Wall-clock billing vs active-CPU billing, how much does monthly cost differ?
- What isolation technology does each use? — Container, gVisor, Firecracker microVM, different strengths.
- Cold start and resume speed? — Affects interactive agent experience.
- How do I choose? — With a selection decision matrix.
Cloud Sandbox Provider Landscape
| Provider | Isolation Tech | Cold Start | Pricing Model | Suitable Scenario | Strengths | Weaknesses |
|---|---|---|---|---|---|---|
| E2B | Firecracker microVM | ~150 ms | wall-clock | Coding agent, long tasks | pause/resume preserves memory, open-source runtime | No GPU, 24-hour session limit |
| Daytona | Docker / Kata | ~90 ms | wall-clock | Parallel evaluation, snapshot fork | Snapshots & forks, long lifecycle | Open-source repo no longer maintained |
| Runloop | microVM | ~150 ms | wall-clock | Evaluation, Blueprint workflow | Devbox blueprint, parallel Devboxes | Smaller ecosystem |
| Vercel Sandbox | Firecracker microVM | ~1.8 s | active-CPU | Agents already on Vercel | Shortest integration path with Vercel ecosystem | Memory billing, persistence needs self-design |
| Cloudflare Sandboxes | Container in VM | ~2–3 s | active-CPU (10ms) | Cloudflare Workers ecosystem | Three-layer architecture (Worker + DO + Container) | Three-layer billing, persistent data needs self-design |
| Modal | gVisor / microVM | sub-second | wall-clock (no idle charge) | GPU workloads, high concurrency | $300M–$1B ARR, GPU sandbox | Managed only, price ~3× function rate |
| AWS Bedrock AgentCore | microVM | ~1–2 s | wall-clock | AWS-native agent | AWS ecosystem integration, Code Interpreter | AWS lock-in |
| Alibaba OpenSandbox | gVisor | ~200 ms | wall-clock | Multi-language SDK (Python/Go/Java) | Alibaba Cloud ecosystem, BYOC | Less international region support |
| Azure Container Apps Sandboxes | microVM | ~1–2 s | wall-clock | Azure-native agent | Microsoft ecosystem, lifecycle policy | Azure lock-in |
Pricing Model Deep Dive
Cloud sandbox pricing models fall into two main categories, directly affecting monthly cost:
1. Wall-clock Billing (E2B, Daytona, Runloop, Modal, Bedrock AgentCore, OpenSandbox, Azure)
Wall-clock billing charges for every second the sandbox is alive, regardless of whether CPU is busy.
| Provider | CPU Rate | Memory Rate | Billing Unit |
|---|---|---|---|
| E2B | $0.000014 / vCPU-s | $0.0000045 / GiB-s | Per second |
| Daytona | $0.000014 / vCPU-s | $0.0000045 / GiB-s | Per second |
| Runloop | Similar to E2B | Similar to E2B | Per second |
| Modal | $0.00003942 / core-s | $0.00000672 / GiB-s | Per second |
| Bedrock AgentCore | AWS standard rates | AWS standard rates | Per second |
2. Active-CPU Billing (Vercel, Cloudflare)
Charges only for actual CPU time executing code, not I/O wait time.
| Provider | CPU Rate | Memory Rate | Billing Unit | Feature |
|---|---|---|---|---|
| Vercel | $0.128 / vCPU-hr | $0.0212 / GB-hr | Per hour | Only active CPU billed, memory billed by wall-clock |
| Cloudflare | $0.072 / vCPU-hr | $0.009 / GiB-hr | Per 10 ms | Memory and disk billed by provisioned size |
Cost Scenario Simulation: 30,000 sessions/month, 5 minutes each, only 30 seconds CPU usage
This scenario simulates "burst interactive agent" workloads: each session lives 5 minutes but actual CPU usage is only 30 seconds, 2 vCPU + 4 GB memory:
| Provider | Estimated Monthly Cost | Notes |
|---|---|---|
| Modal | ~$36 | Almost no idle CPU charge, best for burst scenarios |
| Vercel | ~$276 | Active-CPU billing skips wait time |
| E2B / Daytona / Blaxel | ~$414 | Full-duration billing, every second counts |
| Cloudflare | Depends on provisioned size | 10 ms billing unit, suitable for extremely short executions |
Conclusion: If your agent workload is "bursty, short execution, long wait," active-CPU billing (Vercel, Cloudflare) or no-idle-charge (Modal) will be much cheaper; if your workload is "long-running continuous execution," wall-clock billing providers (E2B, Daytona) are more suitable.
Cold Start & Resume Speed Comparison
| Provider | Median TTI | P95 | P99 | Success Rate |
|---|---|---|---|---|
| Daytona | 0.27 s | 0.43 s | 0.44 s | 37% |
| Vercel | 0.67 s | 1.04 s | 1.12 s | 100% |
| Modal | 0.88 s | 1.00 s | 1.08 s | 100% |
| Runloop | 0.89 s | 3.27 s | 3.50 s | 100% |
| E2B | 1.61 s | 1.77 s | 1.81 s | 100% |
| Cloudflare | 5.06 s | 6.04 s | 6.48 s | 100% |
Daytona's success rate is lower (37%) possibly due to test conditions, but its cold start speed is indeed industry-leading.
Selection Decision Tree
Starting point: Your agent workload characteristics
│
├─ Need GPU? ──→ Modal (GPU sandbox) or Bedrock AgentCore
│
├─ Already in Vercel ecosystem? ──→ Vercel Sandbox (shortest integration path)
│
├─ Already in Cloudflare ecosystem? ──→ Cloudflare Sandboxes (three-layer architecture)
│
├─ Already in Azure ecosystem? ──→ Azure Container Apps Sandboxes
│
├─ Already in AWS ecosystem? ──→ Bedrock AgentCore
│
├─ Already in Alibaba Cloud ecosystem? ──→ Alibaba OpenSandbox
│
├─ Need pause/resume preserving memory? ──→ E2B
│
├─ Need snapshots & forks (parallel evaluation)? ──→ Daytona
│
├─ Need evaluation & Blueprint workflow? ──→ Runloop
│
├─ Bursty interactive, cost-sensitive? ──→ Modal or Vercel (active-CPU)
│
└─ Other: Long tasks, no special ecosystem binding ──→ E2B or DaytonaWhat You Should Understand After Reading
- Positioning and differences among nine cloud sandbox providers.
- Wall-clock vs active-CPU billing model cost differences, and which scenario chooses which.
- Cold start speed impact on different types of agents.
- How to choose a provider based on workload characteristics.
- Each provider's strengths and weaknesses, avoiding wrong provider selection leading to migration costs.
References
- E2B Documentation
- Daytona Documentation
- Runloop Documentation
- Vercel Sandbox
- Cloudflare Sandbox SDK
- Modal Sandbox Guide
- AWS Bedrock AgentCore
- Alibaba OpenSandbox
- Azure Container Apps Sandboxes
- 本站：沙箱系列導讀（order 0）
- 本站：E2B Agent Sandbox（order 8）
- 本站：Daytona Agent Sandbox（order 9）
- 本站：Runloop Devbox（order 10）
- 本站：Vercel Sandbox（order 11）
- 本站：Cloudflare Sandboxes（order 15）