What happened
In a November 12, 2026 engineering post, Modal describes resource use across its Sandboxes: isolated environments the company positions for coding agents, reinforcement-learning rollouts, and untrusted code. Modal says a typical Sandbox spends more than half its life using less than 6% of its peak CPU. In the company's account, coding-agent sessions have this shape because the model often reasons between tool calls while the Sandbox does little work; demand rises when the agent installs dependencies, runs tests, or builds a project.
Modal says it observes the same general pattern in other common Sandbox workloads: RL rollouts, evaluations, and app builders. The company frames the observation as a capacity-planning problem. A system that reserves resources for every session's highest expected demand can hold capacity during long inactive intervals, even though it must still serve short, compute-intensive actions promptly when they occur.
The post illustrates that argument with a replay of a coding agent fixing a vulnerability. The task is labeled Terminal-Bench 2.1 “Fix-Code-Vulnerability” and runs for 2 minutes and 46 seconds. Modal says CPU stays near zero apart from brief pytest spikes, while memory remains near 47 MiB. The session shown has a request of 0.125 CPU cores and 128 MiB of memory.
The timeline also shows the agent waiting on the model for 33 seconds and requesting two waits of 60 seconds each. It moves through repository inspection, test execution, code reading, a patch, and completion over 10 model calls. Modal uses this trace to support the title's prescription, “burst, don't reserve”: provision for execution bursts rather than treating a session's peak demand as a continuously occupied allocation. The post is an engineering observation and an example trace, rather than an announcement of a new Sandbox price, limit, or access tier.
The distinction matters when interpreting the numbers. A low average CPU level is not itself a cost result, and a burst-oriented policy can introduce its own constraints around scheduling, startup latency, concurrency, and the resources that must remain ready. Modal's claim is narrower: agent environments can be idle for substantial portions of a task even when they need occasional periods of active execution.
What the archive adds
New Runtime's earlier coverage of Modal's $750 million Series D and annualized revenue milestone treated the company as a business-scale signal for AI infrastructure, while noting that its underlying economics were not independently verified. This is a new technical fact on the broader Modal story: it describes the utilization profile that can shape how sandbox capacity is planned.
Trend signal
This does not yet fit a pattern New Runtime tracks. The post provides a useful observation about CPU and memory utilization in sandboxed agent workloads, but it does not establish cost per verified completed task, a new runtime security boundary, or a reusable agent interface. It is best read as an infrastructure design signal, not evidence of a broader shift in agent economics.
Why it matters
Agent workloads differ from continuous batch jobs. A coding agent may spend time awaiting a model response, examining output, or sitting through a command's requested wait; then it may need CPU immediately to install packages, compile code, or run a test suite. Treating every active session as if it continuously consumes its peak allocation can create a mismatch between reserved capacity and actual use.
For a team operating many agent sessions, that mismatch can affect both infrastructure cost and responsiveness. Under-provisioning can delay the short actions that move a task forward; over-reserving can consume a scarce concurrency pool while a model is thinking. Modal's trace does not choose the correct policy for every deployment, but it makes phase-level telemetry a more useful planning input than a single peak request.
Limits and uncertainty
Modal's post is a company engineering account, and the replay is one coding-agent task. The reported “more than half” and “less than 6%” figures characterize what Modal calls a typical Sandbox, but they are not an independently audited benchmark. The published example does not establish that all coding agents, RL rollouts, evaluations, or app builders share the same ratio of waiting to execution.
Nor does the post report a before-and-after comparison for cost, latency, throughput, or reliability under a burst policy. Those outcomes depend on workload mix, task duration, concurrency, scheduling behavior, startup characteristics, and the execution platform. Teams should therefore treat the trace as a hypothesis to test in their own operating environment rather than a universal sizing rule.
Skill to build now
Instrument an agent run as a sequence of phases this week: model wait, command execution, dependency installation, test run, build, and explicit sleep. Record CPU, memory, elapsed time, queue delay, and failures for each phase. Then compare a peak-reserved configuration with a policy that can serve short bursts. If you run coding agents in sandboxes, use representative repositories and task mixes rather than one successful repair trace.
Reader takeaway
Modal's example shows why an agent sandbox's peak CPU request can be a poor proxy for its typical consumption: much of a session may be waiting on the model. Measure idle intervals and execution bursts separately before changing capacity policy. The post supports that measurement discipline, not a guaranteed claim of lower spend.