Modal Sandbox bursting: pay for average use, not the peak

Modal Sandbox bursting changes how you should size the machine your coding agent runs in. In a post on November 12, Modal explained that each Sandbox reserves a small minimum and bursts into spare capacity when it needs more. You pay each second for the higher of your request or your real use. An agent sandbox is idle most of the time, so the bill follows the average, not the peak.

What actually happened

Modal published Sandbox resourcing: burst, don't reserve. The mechanics:

• The billing rule. Each second, a Sandbox is billed for the higher of its request and what it uses.
• The floor. The default request is 0.125 cores and 128 MiB of memory. An idle Sandbox is billed at that floor.
• The ceiling. By default a Sandbox can burst up to 16 cores above its request. Memory has no default limit.
• The rates. Modal's list price in the post is 14.19 cents per CPU-hour and 2.40 cents per GiB-hour. One Modal CPU is a physical core, about 2 vCPU. The pricing page gives the same Sandbox rates per second.
• The controls. In the SDK, modal.Sandbox.create(cpu=(0.125, 4.0), memory=(128, 2048)) sets a request and a hard limit: 4 cores and 2 GiB in this example.

Modal's own example is a 20-minute coding agent task with a peak of 6 cores and an average of 0.44 cores and 0.94 GiB. Its calculator puts that at about 8.4 cents per Sandbox-hour, against 20 cents for a fixed 1.5-CPU, 3 GiB reservation. Modal labels these as illustrative workloads, not production traces, and the reservation rates are an assumption you can edit. The post also says a typical Sandbox spends more than half its life below 6% of its peak CPU.

Why Modal Sandbox bursting matters for your business

If you run agents that write and test code, the sandbox is a line on your bill. Most of that time the agent waits for a model call. A fixed reservation makes you pay for the pytest spike all day.

But burst capacity is shared capacity, and Modal states the cost plainly:

• CPU. If the machine runs out, a bursting Sandbox slows down until CPU frees up. Your request is always guaranteed.
• Memory. If the machine runs out, a Sandbox above its request can be evicted with an out-of-memory error. Modal's target for bursting Sandboxes under 8 GiB is about 1 eviction per 694 Sandbox-days. There is no target yet for larger ones.
• Your own limit. If a Sandbox crosses its memory limit, it stops.

What to do:

1. Measure before you size. Record average and peak CPU and memory for one real agent task.
2. Set a memory limit above the real peak. No default memory limit means a leak becomes a bill.
3. Request more only where an OOM is expensive. Long jobs with no checkpoint need a higher memory request. Short retryable tasks do not.
4. Make the request equal to the limit for evals. Benchmarks need the same machine each run.
5. Handle the eviction. Detect the termination reason and retry from a snapshot.

Sources: Modal: Sandbox resourcing: burst, don't reserve, Modal pricing.