For most agent workloads, cost is dominated by compute while a session is actively running. A 60-second session on a 2 vCPU / 4 GiB sandbox costs about a quarter of a cent in raw compute at Dedalus's published rates. The trap isn't the per-session price — it's paying for idle machines, over-provisioned CPU, and sessions that never terminate.
Per-second billing itself won't save you from that trap anymore. E2B, Modal, and Fly.io all bill per second too. The distinction that actually matters is what "per second" is measuring — wall-clock time the sandbox is up, or actual active compute — and whether avoiding the idle charge costs you the sandbox's state. This guide breaks down real, published prices, corrects a common conflation in how "idle" gets marketed, and gives you a formula to forecast spend before you present numbers to your team or investors.
Why AI Agent Sandbox Costs Are Confusing
Traditional cloud billing assumes long-lived servers: you rent an instance by the hour and pay whether or not it's doing work. That model was built for web apps that run 24/7.
Agent workloads break every assumption behind it. A single agent might spin up, run for 30–90 seconds, and exit, then sit idle for minutes before the next trigger. One user might run 3 sessions a day; another runs 3,000. A code-review agent might finish in 15 seconds; a research agent scraping 40 pages might run 4 minutes.
Map a bursty, ephemeral workload onto hourly billing and you overpay dramatically — you're renting a full hour to use 45 seconds of it. There's no standard cost model across vendors, either, which is exactly why the numbers below are normalized to per-second units rather than compared as marketing headlines.
The Two Pricing Models
There are three dominant ways vendors charge for agent sandboxes, and each fits a different workload shape.
Per-second (pay only while running). You're billed by the second the sandbox is up, and billing stops when it's stopped, paused, or killed. This is the default for bursty, ephemeral agent traffic, and it's now the baseline model across E2B, Modal, Fly.io Machines, and Dedalus. If you're comparing vendors on "per-second billing" alone, you're comparing a feature none of them differentiate on anymore.
Where they do differ is what "running" means and who has to act to stop the meter:
- E2B bills for the full wall-clock duration a sandbox is in the running state, active or not. Their own docs are explicit about this: billing stops only "once a sandbox is paused, killed or times out" — and pausing is something you call (
sbx.pause()) or configure (auto-pause after inactivity). An idle sandbox mid-session, sitting between tool calls, bills at the full rate until you or a timeout intervenes. - Modal meters for the duration a container holds resources during an invocation; the rate for Sandboxes runs about 3x Modal's standard Function rate. The meter stops once the container scales to zero after the invocation ends, but idle time within an active invocation is billed.
- Dedalus meters active compute continuously and automatically distinguishes active from idle without pausing or killing the machine. The machine stays persistent and warm; you're billed $0/hour the moment it goes idle, and full rate the moment work resumes — no pause call, no lost state, no cold restart.
That's the actual differentiator: E2B, Modal, and Fly.io all make you choose between keeping a sandbox persistent (and paying the idle rate) or pausing it to save money (and interrupting whatever state or in-flight work it held). Dedalus's bet is that you shouldn't have to choose.
Reserved (monthly commitment). You commit to guaranteed capacity for a flat or discounted monthly fee. Best for steady, high-volume baseline load where you know you'll always have N sandboxes warm.
Rule of thumb: bursty traffic wants per-second metering that actually tracks activity, not just uptime; predictable baseline load wants reserved capacity. Most agent products start per-second and layer reserved capacity underneath only once they have a stable floor of demand.
Cost Anatomy of an Agent Session
A single agent session accrues cost across five components:
- VM provisioning — spinning up the sandbox. This should be free or negligible. If a provider bills the provisioning window or charges for cold starts, that's a red flag. Dedalus launches full Linux VMs in under 50ms and doesn't bill idle provisioning time.
- Compute time — vCPU-seconds while the sandbox is active. Usually the largest line item.
- Memory — GiB-seconds. High-memory configs carry a premium.
- Disk — persistent state between sessions, billed per GB-month. Small but recurring.
- Network egress — browsing, API calls, package downloads. Variable and easy to underestimate for web-scraping agents.
A worked example: 60 seconds on a 2 vCPU / 4 GiB sandbox
Using Dedalus's published rates as of July 2026 ($0.04536/vCPU-hour, $0.01458/GiB-hour):
- Compute: 2 vCPU × $0.04536/hr × (60s ÷ 3600) = $0.0015
- Memory: 4 GiB × $0.01458/hr × (60s ÷ 3600) = $0.0010
- Total: ~$0.0025 — about a quarter of a cent for a full minute of a 2-core agent.
Disk and egress are typically pennies-per-thousand-sessions territory unless your agent moves large payloads. Compute is the dominant cost, which is why how long your agents run and whether they idle matters far more than the headline per-second rate.
Cost Comparison Table (Public Pricing, July 2026)
Rates below are normalized to per-vCPU-hour and per-GiB-hour where a vendor publishes clean per-unit pricing. Where they don't, that's noted rather than estimated.
| Provider | vCPU-hour | Memory (GiB-hour) | Cost while idle |
|---|---|---|---|
| **Dedalus** | $0.04536 | $0.01458 | $0, automatically, machine stays persistent |
| **E2B** | $0.0504 | $0.0162 | $0 only after explicit `.pause()`/`.kill()` or configured auto-pause |
| **Modal** (Sandboxes, non-preemptible) | ~$0.1419 | ~$0.0242 | $0 once container scales to zero post-invocation; idle *within* an invocation is billed |
| **Fly.io Machines** | Bundled into named presets (smallest shared-cpu-1x-256mb ≈ $0.0028/hr all-in) | Bundled | Compute drops to $0 once explicitly stopped; attached volumes keep billing |
| **AWS EC2** (t3.medium, on-demand, 2 vCPU / 4 GiB) | $0.0416/hr flat, bundled | Bundled | None — bills the full instance regardless of utilization |
Dedalus and E2B publish clean, separable per-unit rates that normalize directly. Modal's Sandbox rate runs roughly 3x its standard Function rate and carries additional multipliers for region pinning and non-preemptible execution — the number above is the base non-preemptible rate. Fly.io bundles CPU and RAM into named machine sizes, so there's no clean per-vCPU figure to quote; we've listed its smallest preset rather than guess one. EC2 bundles memory into the instance type too, and — this is the real structural gap — it bills the full running instance whether your agent is active or idle, which is the mismatch that per-second billing exists to fix in the first place.
A real example, not a hypothetical
Dedalus's own pricing calculator models a 2 vCPU / 8 GiB machine running 150 active hours and 594 idle hours in a month (a realistic split for a bursty agent workload). At Dedalus's rates, that's $31.10 — you pay only for the 150 active hours. A comparable always-on setup billing for all 744 hours works out to roughly $106.89, a 71% difference, purely from not being charged for idle time. That's the shape of the savings per-second-billing-with-automatic-idle-detection is supposed to produce — and it only shows up if the vendor doesn't require you to manually pause the machine to get it.
How to Control Agent Compute Spend
The difference between a $500/month agent bill and a $5,000 one is almost always operational discipline, not the vendor's rate card.
- Hard timeouts. A runaway agent hung on a network call can burn compute indefinitely. Set an aggressive max-duration kill switch on every session — the single highest-leverage control you have.
- Right-sizing. Most agent tasks are I/O-bound (waiting on API and model responses), not CPU-bound. They need 1–2 vCPU, not 8. Doubling vCPU doubles your compute rate for work that's mostly waiting. (For matching agent workloads to the right compute tier, see the agent runtime environment guide.)
- Ephemeral by default, without sacrificing state. Don't keep sandboxes warm "just in case" — but also don't accept a vendor that forces you to pause or kill a sandbox to stop paying for it. On EC2, idle is simply your bill. On E2B, Modal, and Fly, avoiding the idle charge means an explicit pause/stop call, which also suspends whatever the sandbox was holding. On Dedalus, idle costs $0 automatically while the machine stays live — this control is table stakes for us, not an optimization you have to remember to apply.
- Snapshot + restore. Persisting state to a snapshot and restoring on demand is far cheaper than keeping a VM idling to preserve state. You pay cheap storage instead of expensive compute.
- Per-agent cost monitoring. Tag and meter cost per agent or per customer. Alert when any single agent exceeds its expected envelope — that's how you catch a broken loop before it hits the invoice.
Frequently Asked Questions
How much does an AI agent sandbox cost? For a standard 2 vCPU / 4 GiB sandbox on per-second billing, a typical 45–60 second agent session costs roughly $0.002–$0.007 in raw compute — well under a cent. At scale, 300,000 sessions/month (10,000/day averaging 45s) works out to about $1,350/month using an illustrative round rate of $0.0001/second (an example figure, not a published provider price). Your actual cost depends far more on session duration and idle time than on the headline rate. Published vCPU-hour rates, as of July 2026, range from ~$0.045 (Dedalus) to ~$0.14 (Modal Sandboxes).
What is per-second VM billing, and is it the same everywhere? Per-second billing charges you only for the seconds a sandbox is running, rather than a full hour regardless of use. By 2026 this is standard across E2B, Modal, Fly.io, and Dedalus — it's no longer a differentiator on its own. What still varies is whether "running" tracks actual activity or just uptime, and whether stopping the idle charge requires you to pause or kill the sandbox. Vendors that meter idle-vs-active automatically on a persistent machine (rather than requiring a manual pause) can cut costs 60–70%+ versus always-on setups, without the tradeoff of losing session state to get there.
How do I reduce AI agent infrastructure costs? Five high-leverage controls: set hard timeouts to kill runaway sessions; right-size to 1–2 vCPU since most agent work is I/O-bound, not CPU-bound; run ephemeral by default rather than keeping sandboxes warm "just in case"; use snapshot + restore instead of idling VMs to preserve state; and monitor cost per agent with alerts. Choosing a provider that meters idle automatically — rather than one where avoiding the idle charge means pausing or killing the machine yourself — makes most of these the default instead of a constant fight.