2026年Agent沙箱横评：冷启动、按秒计费与网络策略对比
Best Agent Sandboxes in 2026: Cold Start, Per-Second Pricing, and Network Policy Across E2B, Daytona, Modal, Cloudflare, and Vercel
做Agent基建选型的同学必看，这份横评把冷启动、计费模型和成本算得清清楚楚，还给了可复现的压测代码，直接拿去对比你的工作负载。
Every agent that writes code needs somewhere to run it. That “somewhere” is now a product category with at least a dozen vendors, four incompatible billing models, and marketing pages that quote cold starts measured under conditions nobody publishes.
每个编写代码的代理都需要一个运行环境。这个“环境”如今已成为一个产品类别，至少有十几个供应商、四种互不兼容的计费模式，以及引用冷启动时间但未公布测试条件的营销页面。
This comparison fixes the units. It covers the five platforms most teams shortlist — E2B, Daytona, Modal Sandboxes, Cloudflare Sandbox SDK, and Vercel Sandbox — along with Runloop, Fly.io Sprites, and Northflank where they change the answer.
本对比统一了计量单位。它涵盖了大多数团队入围的五款平台——E2B、Daytona、Modal Sandboxes、Cloudflare Sandbox SDK 和 Vercel Sandbox——以及 Runloop、Fly.io Sprites 和 Northflank（在它们影响结论的情况下）。
The four questions that actually decide this
真正决定选择的四个问题
Feature matrices for this category are mostly noise. Four properties change architecture, and everything else is a preference:
这类产品的功能矩阵大多是噪音。四个属性会改变架构，其余都是偏好问题：
- Cold start under concurrency: An agent loop that creates a sandbox per tool call pays this tax thousands of times a day.
- Filesystem persistence between turns: Does turn 2 see the pip install from turn 1, or does the agent rebuild its world?
- Egress policy: Can the sandbox reach the internet, can you turn that off, and can you change your mind mid-session?
- Idle billing: Agents spend most of their wall-clock waiting on a model. Somebody is paying for those seconds.
- 并发下的冷启动：一个每次工具调用都创建沙箱的代理循环，每天要为这种开销付出数千次代价。
- 轮次间的文件系统持久性：第二轮能否看到第一轮的 pip 安装，还是代理必须重建其环境？
- 出口策略：沙箱能否访问互联网，能否关闭该权限，以及能否在会话中途更改决定？
- 空闲计费：代理大部分墙钟时间都在等待模型响应。这些秒数总有人要买单。
1. Cold start: what the numbers actually say
1. 冷启动：数字实际说明了什么
The vendor claims are not comparable to each other. Daytona’s pricing page advertises sub-90ms sandbox creation. E2B is commonly cited at roughly 150ms. Modal advertises sub-second cold starts for pre-cached containers. None of these state concurrency, region, image size, or whether the clock stops at API acknowledgment or at first executed command.
各供应商的声明彼此不可比。Daytona 的定价页面宣传沙箱创建低于 90 毫秒。E2B 通常被引用为约 150 毫秒。Modal 宣传预缓存容器的冷启动低于一秒。这些都没有说明并发度、区域、镜像大小，或计时是在 API 确认时停止还是在首个命令执行时停止。
The most useful public dataset is ComputeSDK’s sandbox leaderboard, which is open source and runs on a schedule. It measures Time to Interactive (TTI): elapsed time from create to the first successful command inside the sandbox, 100 iterations per provider, launched concurrently in a single burst, from a 4 vCPU host in Northern Virginia.
最有用的公开数据集是 ComputeSDK 的沙箱排行榜，它是开源的并按计划运行。它测量交互时间（TTI）：从创建到沙箱内首个命令成功执行的耗时，每个提供商 100 次迭代，单次突发并发启动，来自北弗吉尼亚的 4 vCPU 主机。
Results from the August 21, 2026 run:
2026 年 8 月 21 日运行的结果：
| Provider | Median TTI | P95 | P99 | Success rate |
|---|---|---|---|---|
| Vercel Sandbox | 0.67s | 1.04s | 1.12s | 100% |
| Modal | 0.88s | 1.00s | 1.08s | 100% |
| Runloop | 0.89s | 3.27s | 3.50s | 100% |
| E2B | 1.61s | 1.77s | 1.81s | 100% |
| Cloudflare | 5.06s | 6.04s | 6.48s | 100% |
| Daytona | 0.27s | 0.43s | 0.44s | 37% |
| 提供商 | 中位 TTI | P95 | P99 | 成功率 |
|---|---|---|---|---|
| Vercel Sandbox | 0.67s | 1.04s | 1.12s | 100% |
| Modal | 0.88s | 1.00s | 1.08s | 100% |
| Runloop | 0.89s | 3.27s | 3.50s | 100% |
| E2B | 1.61s | 1.77s | 1.81s | 100% |
| Cloudflare | 5.06s | 6.04s | 6.48s | 100% |
| Daytona | 0.27s | 0.43s | 0.44s | 37% |
Three things in that table matter more than the ranking.
该表中三件事比排名更重要。
- Burst is not the same test as sequential: Daytona’s fastest published median is real, and on an earlier provider-page run it created sandboxes at a 0.10s median when launched one at a time. On the August burst run it posted the fastest median in the field and completed 37 of 100 attempts. A median you only reach on a third of your calls is not a latency number, it is a capacity number. Retry logic is not optional on any of these platforms.
- Tail latency is the number to design against: Runloop’s median and Modal’s median are 10ms apart. Runloop’s P95 is 3.3x Modal’s. If your agent’s UX budget is one second, the median tells you almost nothing.
- Cloudflare is measuring a different product: Sandbox SDK sits on Cloudflare Containers, which schedules a container instance and boots an image. That is architecturally a heavier operation than resuming a pre-warmed Firecracker VM, and 5s medians reflect it. Cloudflare’s own GA post is candid about the shape of the problem: booting a sandbox, cloning a repo, and running npm install takes about 30 seconds, while restoring the same environment from a backup takes about two.
- 突发测试与顺序测试不同：Daytona 最快的公开中位数是真实的，在早前的一次提供商页面运行中，当逐个启动沙箱时，其中位数时间为0.10秒。在8月的突发运行中，它在该领域发布了最快的中位数，并完成了100次尝试中的37次。仅在三分之一的调用中达到的中位数不是延迟数字，而是容量数字。在任何这些平台上，重试逻辑都是必不可少的。
- 尾部延迟是设计时应对的数字：Runloop 的中位数与 Modal 的中位数相差10毫秒。Runloop 的 P95 是 Modal 的3.3倍。如果你的代理用户体验预算是一秒，中位数几乎无法告诉你任何信息。
- Cloudflare 测量的是不同的产品：Sandbox SDK 基于 Cloudflare Containers，它调度一个容器实例并启动镜像。这在架构上比恢复预热的 Firecracker VM 更重，5秒的中位数反映了这一点。Cloudflare 自己的 GA 发布文章坦诚地描述了问题的形态：启动沙箱、克隆仓库并运行 npm install 大约需要30秒，而从备份恢复相同环境大约需要两秒。
Reproducing this yourself
自行复现此测试
The task worth measuring is the one your agent runs, not echo hello. A useful harness runs the same unit of work everywhere: install pandas, read a CSV, plot it, return a PNG. Time four checkpoints separately.
值得测量的任务是你的代理实际运行的，而不是 echo hello。一个有用的测试框架应在各处运行相同的工作单元：安装 pandas、读取 CSV、绘制图表、返回 PNG。分别计时四个检查点。
# checkpoints: t_create -> t_ready -> t_deps -> t_result
# run 100 iterations sequential, then 100 concurrent, report median/P95/P99
import time, statistics
def one_run(provider):
t0 = time.perf_counter()
sbx = provider.create() # API acknowledged
t1 = time.perf_counter()
sbx.exec("python -c 'print(1)'") # first command returns: TTI
t2 = time.perf_counter()
sbx.exec("pip install pandas matplotlib")
t3 = time.perf_counter()
sbx.exec("python /work/plot.py") # writes /work/out.png
png = sbx.read_file("/work/out.png")
t4 = time.perf_counter()
sbx.kill()
return dict(create=t1-t0, tti=t2-t0, deps=t3-t2, task=t4-t3, bytes=len(png))# checkpoints: t_create -> t_ready -> t_deps -> t_result
# run 100 iterations sequential, then 100 concurrent, report median/P95/P99
import time, statistics
def one_run(provider):
t0 = time.perf_counter()
sbx = provider.create() # API acknowledged
t1 = time.perf_counter()
sbx.exec("python -c 'print(1)'") # first command returns: TTI
t2 = time.perf_counter()
sbx.exec("pip install pandas matplotlib")
t3 = time.perf_counter()
sbx.exec("python /work/plot.py") # writes /work/out.png
png = sbx.read_file("/work/out.png")
t4 = time.perf_counter()
sbx.kill()
return dict(create=t1-t0, tti=t2-t0, deps=t3-t2, task=t4-t3, bytes=len(png))Report tti and task separately. Vendors optimize the first and readers care about the second. Pin the region, pin the image, and publish both the sequential and the concurrent series, because they answer different questions.
分别报告 tti 和任务时间。供应商优化前者，读者关心后者。固定区域、固定镜像，并同时发布顺序和并发系列，因为它们回答不同的问题。
2. Per-second pricing, normalized
2. 按秒计费，标准化
Published rates as of August 27, 2026, converted to a common unit. Modal prices per physical core, which it defines as 2 vCPU, so the vCPU-equivalent is shown for comparison.
截至2026年8月27日的公布费率，转换为统一单位。Modal 按物理核心计费，其定义为2个 vCPU，因此为比较显示了 vCPU 等效值。
| Platform | CPU | Memory | Billing basis | Plan floor |
|---|---|---|---|---|
| E2B | $0.0504 / vCPU-hr | $0.0162 / GiB-hr | Wall-clock, per second | Free Hobby; $150/mo Pro |
| Daytona | $0.0504 / vCPU-hr | $0.0162 / GiB-hr | Wall-clock, per second | None; $200 credit |
| Modal Sandbox | $0.1419 / core-hr (~$0.0710 / vCPU-hr) | $0.0240 / GiB-hr | max(request, actual), per second | Free Starter; $250/mo Team |
| Vercel Sandbox | $0.128 / vCPU-hr active CPU only | $0.0212 / GB-hr provisioned | Split: CPU active, memory wall-clock | Hobby allotment; Pro credit |
| Cloudflare Sandbox | $0.072 / vCPU-hr active CPU only | $0.009 / GiB-hr provisioned | Active CPU + provisioned memory/disk | $5/mo Workers Paid |
| Fly.io Sprites | $0.07 / CPU-hr | $0.04375 / GB-hr | Active use only; sleeps when idle | Subscription tiers |
| Runloop | $0.108 / CPU-hr | $0.0252 / GB-hr | Running state; suspended is storage-only | Free Basic; $250/mo Pro |
| Northflank | $0.01667 / vCPU-hr | $0.00833 / GB-hr | Allocated resources, per second | Free Sandbox tier |
| 平台 | CPU | 内存 | 计费基础 | 计划下限 |
|---|---|---|---|---|
| E2B | $0.0504 / vCPU-小时 | $0.0162 / GiB-小时 | 按挂钟时间，每秒 | 免费Hobby；$150/月Pro |
| Daytona | $0.0504 / vCPU-小时 | $0.0162 / GiB-小时 | 按挂钟时间，每秒 | 无；$200信用额度 |
| Modal Sandbox | $0.1419 / 核-小时（约$0.0710 / vCPU-小时） | $0.0240 / GiB-小时 | max(请求,实际)，每秒 | 免费Starter；$250/月Team |
| Vercel Sandbox | $0.128 / vCPU-小时（仅活跃CPU） | $0.0212 / GB-小时（预置） | 拆分：CPU活跃，内存挂钟 | Hobby配额；Pro信用额度 |
| Cloudflare Sandbox | $0.072 / vCPU-小时（仅活跃CPU） | $0.009 / GiB-小时（预置） | 活跃CPU + 预置内存/磁盘 | $5/月Workers Paid |
| Fly.io Sprites | $0.07 / CPU-小时 | $0.04375 / GB-小时 | 仅活跃使用；空闲时休眠 | 订阅层级 |
| Runloop | $0.108 / CPU-小时 | $0.0252 / GB-小时 | 运行状态；挂起仅存储 | 免费Basic；$250/月Pro |
| Northflank | $0.01667 / vCPU-小时 | $0.00833 / GB-小时 | 分配资源，每秒 | 免费Sandbox层级 |
Two footnotes that people get wrong.
两个人们容易搞错的脚注。
- Modal’s sandbox tier is roughly 3x its standard Function rate ($0.00003942 vs $0.0000131 per core-second), and region selection adds 1.5–1.75x on top. Sandbox pricing is not Modal’s headline compute pricing.
- Daytona’s GPU rates are widely reproduced at $3.95/hr for an H100. Its live pricing page lists on-demand H100 at $2.27/hr and H200 at $2.61/hr. Third-party comparison tables in this category go stale within a quarter.
- Modal的沙箱层级大约是其标准Function费率（每核秒$0.00003942对比$0.0000131）的3倍，且区域选择还会额外增加1.5-1.75倍。沙箱定价并非Modal的主打计算定价。
- Daytona的GPU费率广泛被引用为H100每小时$3.95。其实时定价页面列出按需H100为$2.27/小时，H200为$2.61/小时。该类别中的第三方比较表在一个季度内就会过时。
3. Cost per 1,000 executions
3. 每1000次执行的成本
Rates are not costs. The model below fixes the workload and runs it through each rate card.
费率不等于成本。下面的模型固定工作负载，并通过每个费率卡运行它。
Assumptions: 2 vCPU / 4 GiB sandbox, 1,000 executions, no plan floor included, no egress, default region (Vercel iad1, Cloudflare standard-3 at 2 vCPU / 8 GiB / 16 GB disk since instance sizes are fixed).
假设：2 vCPU / 4 GiB沙箱，1000次执行，不包括计划下限，无出站流量，默认区域（Vercel iad1，Cloudflare standard-3，2 vCPU / 8 GiB / 16 GB磁盘，因为实例大小固定）。
Scenario A: short burst — 90s alive, 50% average CPU
场景A：短突发——存活90秒，平均CPU 50%
| Platform | Cost / 1,000 | Composition |
|---|---|---|
| Northflank | $1.67 | $0.83 CPU + $0.83 memory |
| Cloudflare | $3.70 | $1.80 CPU + $1.80 memory + $0.10 disk |
| E2B / Daytona | $4.14 | $2.52 CPU + $1.62 memory |
| Vercel | $5.32 | $3.20 active CPU + $2.12 memory |
| Modal | $5.95 | $3.55 CPU + $2.40 memory |
| Fly Sprites | $7.88 | $3.50 CPU + $4.38 memory |
| Runloop | $7.92 | $5.40 CPU + $2.52 memory |
| 平台 | 成本/1000 | 构成 |
|---|---|---|
| Northflank | $1.67 | $0.83 CPU + $0.83内存 |
| Cloudflare | $3.70 | $1.80 CPU + $1.80内存 + $0.10磁盘 |
| E2B / Daytona | $4.14 | $2.52 CPU + $1.62内存 |
| Vercel | $5.32 | $3.20活跃CPU + $2.12内存 |
| Modal | $5.95 | $3.55 CPU + $2.40内存 |
| Fly Sprites | $7.88 | $3.50 CPU + $4.38内存 |
| Runloop | $7.92 | $5.40 CPU + $2.52内存 |
Scenario B: idle-heavy — 10 min alive, 5% average CPU
场景B：空闲为主——存活10分钟，平均CPU 5%
This is what a real agent loop looks like. The sandbox is open, the model is thinking, nothing is running.
这就是真实代理循环的样子。沙箱是打开的，模型在思考，没有运行任何东西。
| Platform | Cost / 1,000 | Change vs A |
|---|---|---|
| Northflank | $11.11 | 6.7x |
| Cloudflare | $13.87 | 3.7x |
| Vercel | $16.27 | 3.1x |
| E2B / Daytona | $27.60 | 6.7x |
| Modal | $39.66 | 6.7x |
| Fly Sprites (kept awake) | $52.50 | 6.7x |
| Runloop (kept running) | $52.80 | 6.7x |
| 平台 | 成本/千次 | 相对A的变化 |
|---|---|---|
| Northflank | $11.11 | 6.7倍 |
| Cloudflare | $13.87 | 3.7倍 |
| Vercel | $16.27 | 3.1倍 |
| E2B / Daytona | $27.60 | 6.7倍 |
| Modal | $39.66 | 6.7倍 |
| Fly Sprites（保持唤醒） | $52.50 | 6.7倍 |
| Runloop（持续运行） | $52.80 | 6.7倍 |
Vercel moves from 4th-cheapest to 3rd, and its CPU line drops from $3.20 to $2.13 while everyone else’s scales linearly. Cloudflare’s active-CPU line falls to $1.20. That is the entire argument for active-CPU billing, and it is worth roughly 2x on this workload.
Vercel从第四便宜升至第三，其CPU费用从$3.20降至$2.13，而其他平台的费用则线性增长。Cloudflare的活动CPU费用降至$1.20。这就是活动CPU计费的全部论据，在此工作负载下大约值2倍的成本差异。
Scenario B with suspend
场景B（带挂起）
The platforms that lose Scenario B can win it back, if your orchestration suspends between turns instead of holding the box open. Same workload, 30s awake per execution:
如果您的编排在轮次之间挂起而不是保持盒子开启，那么在场景B中失利的平台可以扳回一局。相同的工作负载，每次执行唤醒30秒：
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力