Dora NodaModal's homepage quotes $0.0000131 per CPU core-second. Run the math on 10,000 monthly CPU-hours — a modest fleet of AI-agent sandboxes running a few hours a day — and that headline rate comes to $471.60. It's the number every pricing comparison table repeats.
It's also not what you'll pay if you're actually running AI-agent sandboxes. Modal's Sandbox product is forced into non-preemptible pricing, and the moment you pin a sandbox to a region — which most production deployments do, for latency or compliance — a second multiplier stacks on top. Run the same 10,000 CPU-hours as real sandboxes in a real region, and the bill lands between $1,419 and $2,483. That's 3x to 5.3x the advertised rate, not the 3.75x that several pricing-comparison sites confidently quote (more on that mismatch below — it turns out the recycled number is itself wrong).
The rate card vs. the sandbox tax
Modal's pricing page lists two different CPU rates depending on what you're running:
| Product | Rate |
|---|---|
| Functions (general serverless, preemptible) | $0.0000131 / core / sec |
| Sandboxes & Notebooks | $0.00003942 / core / sec |
The Sandbox rate is exactly 3x the Function rate. That's not a coincidence — Modal's docs spell out a "Non-Preemptible Execution: 3x base prices" rule, and Sandboxes are non-preemptible by design. A generic serverless function can be killed and rescheduled elsewhere without anyone noticing; an AI agent mid-way through a multi-step sandboxed task can't. So Modal bakes the non-preemptible premium directly into the Sandbox rate card, and there's no cheaper preemptible tier to opt into if what you're running is an agent.
That 3x alone turns the $471.60 headline number into $1,419.12 for 10,000 monthly CPU-hours of actual Sandbox usage — before you've touched a region setting.
The fleet-level math is useful for capacity planning, but it can obscure what a single workload actually costs. Say you're running one always-on coding-agent sandbox — 4 CPU cores, 16GB RAM, the kind of spec a Claude Code or similar agent session needs to hold a repo and a build toolchain in memory. Modal's Sandbox memory rate is $0.00000672 per GiB per second, also 3x the Function-tier rate. Add it up:
- CPU: 4 cores × $0.00003942/sec = $0.00015768/sec
- Memory: 16 GiB × $0.00000672/sec = $0.00010752/sec
- Combined: $0.0002652/sec → $22.91/day → $687.40/month, run continuously, before any region pin
That's the cost of one persistent sandbox sitting idle-but-warm between agent turns, not a burst workload — and it's already $216/month above what a rough back-of-envelope estimate from the advertised per-core rate would suggest.
Then region selection stacks another 1.5x–1.75x
Most people running agent sandboxes in production don't leave region selection to chance. Latency-sensitive agents and anything with a data-residency requirement get pinned to a specific region. Modal's region-selection docs split regions into two tiers, and the multiplier applies "on top of our base usage pricing" to any Function or Sandbox with a container region defined:
- Broad regions (
us,eu,ap,uk,ca,mx,sa,me,af) — 1.5x - Narrow regions (
us-west,us-east,eu-north,ap-northeast,jp,au, and similar) — 1.75x
Notably, this isn't the compliance-driven "cheap regions vs. expensive regions" split you'd expect — Modal charges the same 1.5x/1.75x whether you pin to us or af. The only variable is how narrowly you specify the region, not which one you pick.
Stack that on top of the Sandbox rate and the $1,419.12 baseline becomes:
| Scenario | Multiplier vs. advertised rate | Cost for 10,000 CPU-hours |
|---|---|---|
| Advertised Function rate (preemptible, no region pin) | 1x | $471.60 |
| Sandbox rate (forced non-preemptible) | 3x | $1,419.12 |
Sandbox + broad region pin (e.g. us) | 4.5x | $2,128.68 |
Sandbox + narrow region pin (e.g. us-west) | 5.25x | $2,483.46 |
A team that reads the $0.0000131 rate, sizes a sandbox fleet against it, and then deploys real agent sandboxes into us-west for latency reasons will see a bill roughly 5.25x higher than what they budgeted for — not because Modal hid anything, but because the rate card and the invoice are answering different questions.
Applied to the single always-on 4-core/16GB sandbox from above, region pinning takes that $687.40/month baseline to $1,031.10/month in a broad region or $1,202.95/month in a narrow one. One sandbox, held always-on for a single agent, can cost more than $14,000 a year — for a workload whose advertised per-core rate implied a small fraction of that.
Why every comparison site has the multiplier wrong
Here's where it gets worse for anyone doing this research secondhand. Search for "Modal sandbox pricing multiplier" and you'll land on multiple comparison sites — Blaxel's Modal pricing guide and CheckThat.ai's Modal brand page among them — that both state the region multiplier is "1.25x-2.5x" and that a combined non-preemptible-plus-region bill comes to 3.75x base, or roughly $1,768.50 for that same 10,000-hour baseline.
That figure doesn't exist anywhere in Modal's current documentation. Live as of this writing, modal.com/pricing and modal.com/docs/guide/region-selection both state the multiplier is 1.5x for broad regions and 1.75x for narrow ones — full stop, no country-tier split, no 1.25x, no 2.5x. Two independently-published sites landed on the exact same incorrect figure, down to the decimal, which is the signature of one source getting copied (directly or via an AI summarization pass) into the next without anyone checking it against the primary source.
This matters beyond one wrong number. The stated audience for pricing-comparison content increasingly includes AI agents doing exactly this kind of research — pulling a rate card to decide where to deploy a workload — and a wrong multiplier that's been laundered across three or four "independent" sources looks a lot more authoritative to an automated researcher than it should. The only fix is the boring one: read the vendor's own current pricing page, not the summary of a summary.
What the same core-hours cost on owned hardware
Modal isn't uniquely expensive here — the underlying tension is that any provider selling burst capacity has to price in the interruption risk it's taking on your behalf. But it's worth putting the corrected numbers next to what the same CPU-hours cost on hardware you own outright.
Hetzner raised CCX (dedicated vCPU) prices sharply in its June 2026 adjustment — a CCX33 (8 dedicated vCPU, 32GB RAM) went from €62.49/month to €138.49/month, a 122% increase. Even after that hike, at roughly 730 hours in a month, a CCX33 delivers 5,840 core-hours for €138.49 (about $157.88 at the current EUR/USD rate). Scaled to 10,000 core-hours, that's roughly $270 — run continuously, with no region multiplier, no preemption premium, and no lookup table to reverse-engineer before you can predict a bill.
That's still 5.3x to 9.2x cheaper than Modal's corrected Sandbox pricing for the same core-hours, even with Hetzner's own 2026 price increases factored in. For context, not every sandbox provider stacks multipliers the way Modal does: E2B's pricing page lists a flat $0.0504 per vCPU-hour with no region or preemption premium, which comes to $504 for 10,000 vCPU-hours — close enough to its own advertised rate that the headline number and the invoice are the same thing. The hidden-multiplier problem isn't universal to AI sandboxes; it's a Modal-specific pricing design.
How to actually budget a Modal sandbox fleet
If you're sizing a real deployment instead of reading a rate card, the four questions that determine your actual multiplier are:
- Is it a Sandbox, not a Function? If your workload is an AI agent holding state across a session, yes — and that's a fixed 3x over the Function rate before anything else.
- Are you pinning a region? If latency or data residency requires it, add 1.5x for a broad region (
us,eu,ap) or 1.75x for a narrow one (us-west,eu-north, and similar) — on top of the Sandbox rate, not instead of it. - What's your actual concurrency and duration? The per-second billing means idle-but-warm sandboxes between agent turns still bill — multiply core-seconds by wall-clock uptime, not by task-execution time.
- Did your cost estimate come from Modal's own pricing page, dated today — or from a comparison site that might be quoting last year's numbers, or someone else's mistake?
Skipping any of the first three understates the bill. Skipping the fourth means you might be budgeting off a number nobody can currently verify.
The real lesson for anyone sizing an agent fleet
None of this makes Modal a bad product — burst capacity that scales to zero is worth paying a premium for, and plenty of workloads genuinely need it. But sizing a sandbox fleet against the advertised per-core-second rate, rather than the Sandbox-plus-region rate you'll actually be billed, is an easy way to blow a budget by 3–5x without anything going wrong operationally. And trusting a comparison site's multiplier without checking it against the vendor's own current pricing page compounds the error rather than catching it.
As more of this cost math gets done by an AI agent deciding where to deploy its own sandboxes rather than a human reading a pricing page, that gap between rate card and invoice becomes a worse input, not a better one — an agent that can't tell a stale multiplier from a current one will size a fleet just as wrong as a human copying the same number from the same blog post.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. There's no multiplier table between the rate you see and the bill you get, because there's no rate card at all: you're paying for the Hetzner capacity directly, at whatever Hetzner is charging that month. Star the repo on GitHub or deploy your first app today.