Runtime (withruntime.com) bills $0.025 per vCPU-hour of CPU your agent actually uses and $0.0075 per GiB-hour of memory, with no plan fee, so the waiting an agent does between model calls costs almost nothing. This post builds the bill for 1,000 runs one line at a time, shows which lines you control, and prices the same work at other providers' published rates.
What does one agent run actually do?
An agent run is mostly waiting, with short bursts of work in between. To price a run, you need two numbers: how long the sandbox runs, and how many CPU-seconds it uses in that time. A CPU-second is one core busy for one second.
Here is a typical coding-agent run. It clones a repository, makes a change, and runs the tests. It uses a sandbox of 2 vCPU and 4 GiB:
| Phase | Wall time | CPU-seconds used | What the CPUs do |
|---|---|---|---|
| Clone and install | 40 s | 50 | Unpack, compile, write to disk |
| 20 model turns | 180 s | 15 | Almost nothing: the model is thinking |
| 20 tool calls between turns | 40 s | 35 | grep, edits, small scripts |
| Run the test suite | 40 s | 50 | Both cores, most of the time |
| Whole run | 300 s | 150 |
Two vCPUs for 300 seconds can do 600 CPU-seconds of work. This run uses 150, a quarter of that. The model turns take more than half the wall time and use almost none of the CPU. This pattern is typical of nearly every agent. The workload priced below is 2 vCPU, 4 GiB, 300 s, 150 CPU-seconds, and 1,000 runs.
How much is the CPU line?
The CPU line is the CPU that the commands used, priced per vCPU-hour:
- CPU
- 1,000 runs × 150 CPU-seconds / 3,600 × $0.025
- $1.04
That is the whole CPU charge for 1,000 runs. Each sandbox held two vCPUs for five minutes, but the bill counts the 150 CPU-seconds that the commands used. It does not count the 600 that the sandbox could have used.
There is a floor. A shared-CPU sandbox is promised 50 millicores (a twentieth of a vCPU) at all times. Each settlement charges the larger of measured CPU and that floor over its duration. For this run, the floor would be 15 CPU-seconds. That is well under the 150 used, so it adds nothing. The floor shows up on a bill only when a sandbox does almost nothing for a long time. Idle pause exists for that case.
How much is the memory line?
Memory is billed on the size you ask for, for as long as the sandbox runs:
- Memory
- 1,000 runs × 300 s / 3,600 × 4 GiB × $0.0075
- $2.50
On a bill that charges CPU by use, memory is the larger line for an agent. So that is where to look for savings. Most coding agents fit in 2 GiB, unless the test suite or a language server needs more. Halving the memory halves this line:
- Memory at 2 GiB
- 1,000 × 300 / 3,600 × 2 × $0.0075
- $1.25
Measure before you cut. sbx.metrics() returns each sandbox's CPU and memory
over time. Size from the peak that your runs actually reach
(size CPU and memory).
What about startup, idle time and the network?
Startup is free, idle time is the line people forget, and the network is usually zero.
Startup. CPU is billed from the moment the sandbox is ready. Boot time is not on your bill. So there is no reason to keep spare sandboxes running ahead of demand.
The idle tail. If your code does not stop the sandbox, it sits idle for 300 seconds and then pauses itself. That wait costs memory and the CPU floor:
- Idle tail
- 1,000 × 300 s / 3,600 × (4 GiB × $0.0075 + 50 millicores × $0.025 per vCPU)
- $2.60
Stop the sandbox when the run ends, and this line is zero. If you turn off idle pause and forget to stop a sandbox, it costs $0.03125 for every hour it sits there. For the thousand sandboxes, that is $31.25 an hour.
Keeping runs for review. A paused sandbox keeps its files, memory and processes. It costs $0.08 per decimal GB per 30-day month, counted on what the sandbox alone stores. Suppose each run left 1 GB of its own state, and you kept all of them paused for a day of review:
- Paused a day
- 1,000 × 1 GB × $0.08 / 30
- $2.67
Outbound traffic. Inbound traffic is free. The clone, the package downloads and every model response cost nothing. Outbound traffic is what the sandbox sends. An agent that calls its model from inside the sandbox sends its prompts. At 20 calls a run and about 60 KB a prompt, the thousand runs send 1.2 GB. Each account gets its first 100 GiB of outbound traffic free each month. After that, outbound traffic costs $0.02 per GB. So this line is zero. Without any allowance, it would be $0.02.
What is the whole bill?
Added together, with each sandbox stopped at the end of its run:
| Line | 1,000 runs |
|---|---|
| CPU used, 150 CPU-seconds a run | $1.04 |
| Memory, 4 GiB for 300 s a run | $2.50 |
| Startup | $0.00 |
| Outbound prompts, inside the allowance | $0.00 |
| Plan fee | $0.00 |
| Total | $3.54 |
| With memory right-sized to 2 GiB | $2.29 |
That is well under a cent a run. The model tokens for the same run will usually cost more than the machine. That is the right way round: the sandbox should be the cheap part.
What changes if the CPU is reserved?
Reserved CPU bills every vCPU as if it were busy for the whole run. Some workloads need it, such as a benchmark that must not share a core. For an agent, it charges for the waiting:
- Reserved CPU
- 1,000 × 300 s × 2 vCPU / 3,600 × $0.025
- $4.17
That is 4 times the measured CPU line for the same work. Most providers bill CPU this way by default: every allocated vCPU, for every second that the sandbox runs. The shared vs reserved CPU page explains when reserving is worth it.
What would the same runs cost elsewhere?
Priced at each provider's published rates for CPU and memory, the same 1,000 runs cost:
| Provider | 1,000 runs, CPU and memory | Runtime costs less by |
|---|---|---|
| Runtime | $3.54 | — |
| Northflank | $5.56 | 36% |
| Vercel Sandbox | $12.40 | 71% |
| E2B | $13.80 | 74% |
| Daytona | $13.80 | 74% |
| Blaxel | $14.49 | 76% |
| Modal | $19.83 | 82% |
Plan fees, storage and network are left out of every row. Each provider's rates were read within the last month. On the one-minute job that the pricing guide uses, Runtime costs 42% to 88% less than fourteen other providers. To price another shape, use the sandbox cost calculator.
How do you measure your own cost per run?
Label every sandbox with the job it belongs to. Then add up what each one was
charged. chargedMicros is the cost of a sandbox so far, in millionths of a
dollar:
TypeScriptimport { Runtime } from "withruntime";const runtime = new Runtime();let runs = 0;let micros = 0;const page = await runtime.sandboxes.list({ labels: { job: "nightly-fix" }, includeStopped: true });for await (const sbx of page) { runs += 1; micros += sbx.info.chargedMicros;}console.log( `${runs} runs, $${(micros / 1e6).toFixed(4)} in all, $${(micros / 1e6 / Math.max(runs, 1)).toFixed(6)} a run`,);Pythonfrom withruntime import Runtimeruntime = Runtime()runs, micros = 0, 0for sbx in runtime.sandboxes.list(labels={"job": "nightly-fix"}, include_stopped=True): runs += 1 micros += int(sbx.info["chargedMicros"])print(f"{runs} runs, ${micros / 1e6:.4f} in all, ${micros / 1e6 / max(runs, 1):.6f} a run")Create each run's sandbox with labels: { job: "nightly-fix" }. The sum is then
your real cost per run, measured rather than estimated. Once you have runs on
Runtime, the CLI also prices them at another provider's published rates:
Terminalruntime compare --from e2bIn short
- An agent run is mostly waiting; price it by running time and CPU-seconds used, not by vCPUs held.
- With CPU billed by use, memory is the bigger line: right-size it first.
- Stop the sandbox when the run ends, or let idle pause cut the tail to 300 seconds.
- Startup is free, inbound traffic is free, and an agent's prompts rarely go beyond the free outbound allowance.
- Label runs and sum
chargedMicrosto get your real cost per run.
Run it on Runtime
On Runtime, these 1,000 five-minute runs cost $3.54 in CPU and memory. There is no plan fee. Every account gets 100 free hours of a 1 GB machine each month, with no card needed. Sign in, or read the pricing and get started guides.