Sandbox Cost Modeling for AI Agent Workloads
AI agents break traditional sandbox cost models because they burst and idle, not run continuously.
Sandbox cost modeling for AI agents breaks the moment engineers apply web-server math to it: hourly rate times hours running. Agent workloads don't move that way. They burst for a few seconds, sit idle waiting on a model response or a tool call, then burst again, and the pattern repeats hundreds or thousands of times a day across sessions that individually last almost nothing. Getting the cost model right means pulling apart six separate axes, compute, session overhead, idle time, storage, egress, and provisioning speed, and understanding how each one behaves before trying to reason about how they interact.
Uber's CTO, Praveen Neppalli Naga, said in April 2026 that the company's entire annual AI budget was already spent. Claude Code adoption inside the engineering org had jumped from 32% to 84% between December 2025 and March 2026, across roughly 5,000 engineers, and monthly API costs per engineer averaged $150 to $250, with power users running $500 to $2,000. Whatever pilot math justified the rollout had no relationship to what production actually cost, and that gap is the whole subject of this piece. Gartner's March 2026 analysis found agentic models eating between 5 and 30 times more tokens per task than a standard chatbot call, and that same multiplier applies just as directly to sandbox compute, session counts, and storage. A cost model built around per-hour thinking will underestimate an agent workload by that same order of magnitude, because the unit that matters is the task the agent performs, not the clock. A single task might trigger a dozen model calls, several tool invocations, and its own sandbox spin-up, and every one of those carries its own charge.
The six cost axes that actually determine an agent sandbox bill
Compute is the most visible line on any bill: the vCPU and memory a sandbox burns while it's doing something. But it's rarely the axis that decides who wins a platform comparison, and treating it as the main event is the first mistake most teams make. Session overhead is the flat charge some platforms apply just for starting a session, or a minimum billing floor that rounds a half-second task up to a full minute. Idle time asks a simpler question: does the meter keep running while the sandbox sits there provisioned but doing nothing? For agent workloads this turns out to be the single most consequential variable on the list, more consequential than compute itself, because agents spend most of their wall-clock time waiting rather than working.
Storage splits into two behaviors that get lumped under one word. Ephemeral storage disappears when the sandbox tears down and is usually free within some limit; persistent storage sticks around, gets billed per gigabyte per month, and quietly piles up whether the work justifies it or not. Egress, the cost of data leaving the sandbox, stays invisible during development and turns into real money only once an agent starts fetching pages, cloning repos, or pulling model weights at volume. Provisioning speed isn't a line item at all, technically, but it decides whether idle sandboxes get kept warm (and billed for it) or torn down clean between tasks.
Here's the actual problem: nobody bills the same way, so comparing platforms on their headline number is close to useless. Some bundle CPU and memory into fixed tiers, some bill physical cores instead of vCPUs, some fold storage into the base price and others charge for it separately. Northflank's published comparison put this in concrete terms: at 200 concurrent sandboxes, total cost across platforms ranged from roughly $7,200 to more than $35,000. A five-times spread. CPU pricing alone cannot explain a gap that size, which means teams picking a platform off its advertised per-vCPU rate are optimizing for the wrong number entirely.
Compute pricing: what the per-second rates actually mean when normalized
Different billing units make this worse before it gets better. Some platforms quote per vCPU-hour, some quote per physical core-hour, some bill per second, and none of it converts cleanly without doing the arithmetic by hand. Northflank publishes $0.01667 per vCPU-hour, billed per second, one of the lowest CPU rates among the PaaS comparisons available. Novita's Agent Sandbox prices per second directly: $0.0000098 per second per vCPU, plus $0.0000016 per GiB per second for memory. Run the numbers on a 5-minute task using 1 vCPU and 512 MiB of RAM and it lands around $0.0032, a number so small it only means anything once multiplied across thousands of sessions a day.
Memory flexibility matters more than it sounds like it should. A data-analysis agent might need 4 GiB of RAM but only a single vCPU, and a platform that only sells fixed compute bundles forces payment for CPU capacity that never gets touched. Per-resource billing avoids that waste, making it the better default for any workload where memory and CPU needs don't scale together. Blaxel takes a different approach with memory tiers, from XS at $0.0828 an hour up through XL at $1.3248 an hour, with CPU bundled into the tier. Estimating cost is simple once memory needs are known, but comparing Blaxel's rate against a per-vCPU rate elsewhere is genuinely hard. The opacity doesn't go away here, it just moves somewhere else on the bill.
Session overhead and minimum billing units: where short-lived agents pay a disproportionate tax
Two mechanisms do roughly the same damage, even though they look different on paper. A flat per-session startup fee charges a fixed amount no matter how short the run is or how little compute it used. A minimum billing unit does the same thing indirectly, rounding a 5-second task up to a full billed minute because that's the smallest unit the meter recognizes.
Why does this land so much harder on agents than on a typical web app? Picture an agent that spins up a fresh sandbox for every user turn in a conversation, or for every tool call inside a multi-step pipeline. That agent might spawn hundreds or thousands of sandboxes a day, and it pays the session tax every single time, before a single unit of compute even gets counted. Novita's per-second billing is built specifically around this failure mode, giving it the right shape for anything high-frequency and short-duration by design rather than by accident. A platform charging even a few cents per session start looks trivial in isolation and ruinous at 10,000 sessions a day. If a vendor's pricing page leads with the compute rate and buries the session fee in a footnote, that's usually the tell.
Before signing anything, a short list of pointed questions earns its keep. Does the provider charge a per-session minimum? What's the smallest billable unit, a second, a minute, something coarser? Does the free tier's concurrency cap quietly break once volume hits production scale? This axis doesn't sit in isolation, either: it interacts directly with provisioning speed. If a fresh sandbox spins up fast enough that starting one per task doesn't stall the agent, per-session overhead becomes the deciding cost factor. If spin-up is slow, teams get pushed toward keeping sandboxes warm instead, which just moves the cost over to the idle-time axis. A session's price never stands alone; it depends on how fast the platform can start one.
Idle time and autopause: the hidden cost driver for intermittent agent execution
Most of an agent's wall-clock time gets spent waiting: on an LLM API response, on an external tool call, on a human approval step, on some downstream data source. The sandbox sits there, fully provisioned, holding state, doing nothing. Whether that idle stretch costs anything depends entirely on how the platform meters it, and this is where most cost estimates go wrong, because engineers price the work and forget to price the wait.
Some platforms only bill active CPU. Fly.io Sprites, Vercel Sandbox, and Cloudflare Sandbox all stop the CPU meter when the sandbox isn't executing, though for Vercel Sandbox and Cloudflare Sandbox, memory keeps billing on provisioned resources even while the sandbox waits. Other platforms bill continuously, running the compute meter for the sandbox's full lifetime regardless of what's happening inside it. A third approach, autopause, suspends the sandbox entirely when it goes idle and resumes it later. Blaxel's published spec claims resume times under 25 milliseconds with full filesystem and memory state intact, fast enough that the agent barely notices the pause happened.
Vercel's model deserves a closer look, because it's a specific trap and an easy one to miss during a pilot. CPU billing stops during idle time, which sounds like exactly what a bursty agent wants, but memory stays provisioned and billed for the sandbox's entire duration. An agent waiting on an LLM response pays nothing for CPU during that wait but keeps paying for memory the whole time. For a memory-heavy agent, that idle memory charge becomes the dominant line item, not the compute, and teams that benchmarked on CPU price alone find that out the hard way. Autopause fixes the idle-cost problem, but only if resume latency stays low enough that the agent doesn't stall waiting for its own sandbox to wake up. That's exactly where idle billing and provisioning speed start depending on each other. Worth flagging separately: Vercel Sandbox snapshots expire after 30 days by default. An agent's saved state doesn't stick around indefinitely unless someone configures it to.
Storage and egress: the compounding costs that surface only after workloads run for weeks
Storage hides two different billing behaviors under one word, and keeping them apart matters. Ephemeral storage lives only as long as the session does and vanishes on teardown; most providers throw in some free allocation, often in the range of several gigabytes as a baseline, with higher allocations available on paid tiers. Persistent storage survives across sessions and gets billed per gigabyte per month, similar to ordinary cloud block storage, and it's what an agent needs if it keeps checkpoints or cached artifacts between runs.
The trap shows up slowly, which is exactly why teams miss it during evaluation. An agent that writes output files on every run and never cleans up racks up storage charges that grow with time elapsed, not with how much work actually got done. Without an explicit cleanup policy, that's a fixed cost climbing quietly in the background until a monthly invoice puts it in plain figures nobody budgeted for. Novita includes 60 GB of storage free, which changes the math meaningfully for teams that would otherwise cross into paid tiers early. Vercel Sandbox charges $0.023 per GB-month for snapshot storage specifically, which matters for any team leaning on snapshots to preserve agent state between sessions.
Egress follows a similar arc: invisible in a dev environment, real once the workload scales. Outbound data transfer from the sandbox to the public internet gets charged, and agents that do browser automation, download datasets, clone repositories, or pull model weights generate a volume of egress that local testing never surfaces, because a laptop running ten test calls looks nothing like production running ten thousand. Cross-region egress, where the sandbox sits in a different region than the application server, stacks another layer of charges on top of that. Package caching is a related lever worth checking: if every cold start re-downloads the same dependencies from scratch, that's network cost piling up on every single sandbox spin-up. Platforms that cache packages across sessions cut both the egress bill and the startup latency at once, one design choice paying off on two axes at the same time. The questions worth asking here mirror the ones for session overhead: is there a per-session or per-day egress cap, does the platform cache packages between starts, and do snapshot files count against the storage bill or sit outside it?
Provisioning speed as an economic variable, not just a performance one
Provisioning speed reads like a performance metric on the surface, but it works as an economic lever, and treating it as a pure latency question is where most cost comparisons fall short. If a sandbox spins up fast enough that starting fresh per task never stalls the agent, teams can tear down completely between tasks and carry zero idle cost. If startup is slow, that option disappears, and sandboxes have to stay resident just to avoid stalling the agent, which shifts the cost profile from zero idle straight to continuous billing or provisioned-memory billing, depending on the platform.
Isolation strength carries its own price tag. Firecracker microVMs report boot times around 125 milliseconds with memory overhead under 5 MiB per microVM, according to Oracle's published benchmarks. That's entirely fine for production agents that need strong tenant isolation, but it's still meaningfully slower than process-level isolation. Blaxel takes a different route to the same destination: standby sandboxes resume in under 25 milliseconds with filesystem and memory state fully intact, suspending rather than tearing down. Purpose-built agent runtimes are pushing toward sub-90-millisecond provisioning, and at that speed the economic case for keeping sandboxes warm mostly falls apart, since a fresh start barely costs any latency at all.
Scale this out to 30,000 sessions a month and the gap between a 2-second cold start and a sub-100-millisecond one stops being a latency footnote. A 2-second cold start forces a warm pool into existence just to keep the agent responsive, and that warm pool carries idle billing across every sandbox in it, all month long. A sub-100-millisecond cold start skips the warm pool entirely, and that's where the real savings sit, not in the compute rate anybody negotiated. Provisioning speed belongs in the cost model as the variable that decides which idle-billing regime a team ends up locked into, not as a separate performance conversation to have later.
How the axes interact: four workload patterns and what they actually cost
No platform wins across every workload shape, because the six axes trade off against each other differently depending on what the agent is actually doing. Pattern-level analysis matters more than any single headline rate: the billing model has to fit the shape of the workload, not the other way around. Picking a platform off its lowest advertised compute rate is the single most common way teams get this wrong: compute rate is close to the least important number on the page for most agent workloads.
Take a high-frequency, short-lived pattern first, something like a code interpreter that spins up a new sandbox on every chat turn. Here, the axes that decide cost are session overhead, per-second compute, and provisioning speed, in that order. A platform with no per-session fee, fast cold starts, and per-second billing with no rounded-up minimum wins clearly. A platform charging a flat startup fee per session, or rounding every run up to a full minute, loses badly here, because that tax gets paid over and over across every single turn of the conversation, and it compounds faster than the compute itself ever does.
