Runtime bills the CPU your code uses. So for an agent that mostly waits on a
model, the comparison usually shows a saving of 42% to 88%. Those are
the figures for the standard example, at each provider's published rates,
checked 25 October 2026 (pricing). runtime compare replaces
the example with your own sandboxes. It uses the same vCPUs, memory and running
time, and prices them both ways.
Run the comparison
Terminalruntime compare --from e2bWithout the CLI installed, run npx withruntime compare --from e2b. The command
takes your settled sandboxes from the last 30 days. It prices them at the rates
you were quoted on Runtime. It prices the same shape and time at the rival's
published rates. Then it prints what you save, about how much that is a month,
and the date the rival's rates were checked.
To change the window, or to compare with another provider:
Terminalruntime compare --from daytona --days 90runtime compare --from modalruntime compare --from fly-machinesThe same figures, in microdollars, come from the API and from MCP:
Terminalcurl -sS "https://api.withruntime.com/v1/usage/compare?provider=vercel&days=30" \ -H "Authorization: Bearer ${RUNTIME_API_KEY}"An agent calls the runtime_account tool with action compare.
Options
| Option | Values |
|---|---|
--from |
e2b, daytona, vercel, modal, cloudflare, fly (Sprites), fly-machines and the others in the rate table |
--days |
The window, up to 90; 30 by default |
--json |
One JSON value, every figure in integer microdollars |
| API | GET /v1/usage/compare?provider=<p>&days=<n> |
| MCP | runtime_account, action compare |
What the example looks like
With no sandboxes yet, the command prices an example, and it says so. The standard example is 1,000 runs of a 2 vCPU, 4 GiB sandbox, 60 seconds each, with 20 CPU-seconds of work per run:
- CPU
- 1,000 × 20 s / 3,600 × $0.025
- $0.14
- Memory
- 1,000 × 60 s / 3,600 × 4 × $0.0075
- $0.50
- CPU
- 1,000 × 60 s / 3,600 × 2 × $0.0504
- $1.68
- Memory
- 1,000 × 60 s / 3,600 × 4 × $0.0162
- $1.08
E2B bills every allocated vCPU for the whole run. Runtime bills the 20 CPU-seconds that the code used. With both CPUs busy for the whole minute, the job costs $1.33 on Runtime and $2.76 on E2B. So Runtime stays cheaper however busy the sandbox is. E2B's rates are from its pricing page, checked 25 October 2026.
Work it out by hand
runtime usage --json lists each sandbox with its measured
activeCpuSeconds, billedCpuSeconds and memoryGiBSeconds. Runtime's cost
is then:
textcost = billedCpuSeconds × $0.025 / 3,600 + memoryGiBSeconds × $0.0075 / 3,600For the other side, use the old provider's own bill where you can see it. If you cannot, use its published rates from the comparison pages. Divide each total by successful jobs, with failed attempts and retries included. Then multiply the difference by your jobs a month.
Mistakes and how Runtime handles them
- Counting free usage as a saving. The comparison prices included sandboxes at Runtime's standard rates. That is what the same work costs on paid credit. It also says how many there were.
- A short history. When your first sandbox is more recent than the window, the month is projected from the days since. The output says so.
- Comparing everything. It compares compute only. Storage, network, plan fees and free allowances are left out on both sides.
- Comparing unlike CPUs. Runtime's default CPU is shared, with a guaranteed
floor. If your old provider gave whole cores, compare against
cpu: "reserved"(how to reserve CPU). - Waiting past the first month to top up. Credit you add within 30 days of signing up is matched, up to $1,000 in total (welcome match). After that, it is not matched.
Related
- How to switch from E2B in one import
- Sandbox cost calculator for a workload you have not run yet
- E2B pricing calculator
- Switch from another provider
Sources
- E2B pricing, checked 25 October 2026
- Every other rival's source is listed under published rate comparison
Facts on this page were checked on 26 October 2026.