Modal plans to add NVIDIA’s Vera processors to the computers that run its AI agent sandboxes. The October 19 announcement follows early company tests reporting up to twice the task throughput of a comparable Intel Granite Rapids system under load. It would bring Arm processors, which use a different instruction set from Intel and AMD’s x86 chips, into Modal’s execution fleet.
For a developer waiting for a coding agent to finish, that sounds like an immediate speed upgrade. The more interesting result concerns how a shared machine behaves when many jobs compete for it. More finished work from a crowded host can help an infrastructure provider serve more customers, even when an individual job on an otherwise quiet machine gains little.
Stephen Nellis’s Reuters report supplies a useful detail about the intended purchase: Modal chief executive Erik Bernhardsson says NVIDIA will join a mixed fleet alongside Intel and AMD. New rival processors will be tested when available. I think that is the right way to approach this announcement. Vera has earned a place in a workload comparison; the next decision is which jobs benefit enough to move.
The Computer Behind the Agent
A coding agent needs somewhere to run commands. The language model may propose a change, but another computer checks out the repository, installs packages, compiles code and runs tests. Modal sells that execution environment through Sandboxes, isolated containers that can run code selected by a user or an agent.
This distinction matters because changing the execution computer changes only part of the workflow. It does not, by itself, improve the model’s ability to choose a correct patch. A useful system needs both sensible decisions and a place to execute them reliably. A faster failed test can shorten a feedback loop; it does not turn a failed patch into a successful one.
Modal’s current documentation also describes different execution runtimes. Its VM runtime supplies a Linux kernel for requirements such as running Docker inside a sandbox; gVisor provides a different isolation environment. Those are practical compatibility requirements to carry into a hardware trial. The CPU announcement does not establish that every existing runtime combination is already available on Vera.
What Twice the Throughput Means
Modal’s engineering account, by Erik Dunteman, emphasizes bursty work. Many sandboxes can be quiet while waiting for a model, then compete for CPU resources when commands arrive. Its early loaded tests showed the strongest Vera advantage; quiet, serial tests were mixed. Modal attributes the loaded result to memory bandwidth and the ability to sustain more concurrent work.
Throughput counts finished tasks over time. Latency measures how long a task takes. A provider can improve the former by serving more concurrent jobs without making every individual job twice as fast. That can still be valuable: a platform that preserves response times through a busy period has solved a problem users actually feel.
The important comparison therefore includes demand. If your service slows when many repositories build together, host contention deserves attention. If a single agent spends most of its session waiting for model responses, a host-level throughput figure tells you much less about its completion time. These are different operating conditions, and the buying decision should follow the one your users encounter.
Even a genuine reduction in CPU execution time affects only its share of a session. In a hypothetical workflow with 60 units of model or network waiting and 40 units of CPU work, cutting CPU time in half produces 80 units overall: a 20% reduction. That arithmetic illustrates the dependency; Modal’s throughput result does not establish the assumed CPU reduction for an individual session.
What the Test Includes
The public Agentless Agent Bench repository explains what is being replayed. It uses 50 tasks drawn from Terminal-Bench 2.1, with supplied correct solutions rather than a model deciding what to do. Network activity is removed, Docker images are prepared in advance, and containers stay warm. This isolates local execution from model response time and much of the setup path.
Its verifier checks the result after a solution runs. In the inspected throughput implementation, only successful solve-and-verify iterations increase the completed count; failures are counted separately. Each task repeats inside the timed window, with its working state reset between iterations. This is useful evidence about a machine doing repeated local work under contention.
It is also a specific workload mixture. A short task can complete more cycles than a long one, so the aggregate is not an equally weighted pass through 50 customer projects. Changing task proportions, CPU allocation, concurrency or test duration can change what the total represents. The public code makes those choices inspectable; it does not make the published result universal.
For a platform operator, I would keep the same application-level jobs in the acceptance test and count successful completions within a useful time limit. That preserves the reason for adding capacity: customers receive completed work. A host that does more repeated operations but leaves the slowest customer jobs waiting may not solve the customer problem the hardware is supposed to solve.
Moving the Software to Arm
Vera is a CPU that can be deployed in standalone servers, as well as alongside NVIDIA GPUs. NVIDIA’s May hardware description lists 88 Olympus cores and up to 1.2 TB/s of memory bandwidth. Those specifications help explain the product’s intended role, but the peak bandwidth is not a measurement of Modal’s application performance.
The architecture change reaches beyond selecting a faster box. An x86 container image may include architecture-specific binaries, language extensions or build tools. Docker’s documentation distinguishes linux/amd64 and linux/arm64 targets and describes native builders, cross-compilation and emulation as different ways to produce multi-platform images.
Docker also warns that QEMU emulation can be much slower than native execution for intensive work such as compilation and compression. That warning is especially relevant when the proposed benefit comes from doing local work faster. It does not mean Modal has promised an emulation path for Vera; it means buyers should establish native compatibility before assuming a container will preserve the advertised advantage.
A mixed fleet offers a practical migration route. Jobs with verified Arm images can be compared on their merits, while an x86-only dependency keeps a reason to use the existing machines. The strongest case for Vera is a recurring workload whose dependencies already work on Arm and whose commands visibly wait for CPU time at peak concurrency. Such a team has less migration work to recover before a performance gain becomes useful.
A Denser Host and a Lower Bill Are Separate Questions
Modal’s resource documentation says Sandboxes can burst beyond their requests when spare host capacity exists. The request guarantees a minimum; the extra capacity depends on availability. Billing uses the higher of requested and actual resources, measured by the second. A more capable host may improve the conditions for bursting, but it does not turn extra CPU consumption into free work.
The current price page also separates Sandboxes and Notebooks from ordinary CPU tasks. As observed on October 20, sandbox CPU is listed at $0.00003942 per physical core-second, and memory at $0.00000667 per GiB-second. Using the lower general CPU-task rate would produce the wrong sandbox estimate.
For scale, those sandbox rates imply about $0.1419 for one physical core-hour and $0.0240 for one GiB-hour. A hypothetical sandbox metered at one core and one GiB for a full hour would therefore incur about $0.1659 for those two resources. That illustration excludes plan charges, credits, storage, network transfer, model calls and other resources. It is a current pricing example, not an announced Vera price.
A shorter job can reduce the time for which memory is retained, while higher instantaneous CPU use can change the CPU component. The actual bill follows the metered quantities and applicable rates. Host throughput alone cannot settle that calculation. A provider’s ability to fit more work onto its machines is an encouraging operating result, but customer savings require either less charged usage, better prices, or a more valuable completed outcome.
This is how I would apply the announcement to a deployment decision:
| Your workload | Useful next comparison | Decision it supports |
|---|---|---|
| Many native Arm jobs compete for CPU at peak demand | Successful completions and slowest-job times at matching concurrency | Whether denser placement preserves the service experience |
| One agent mostly waits for its model or external services | Whole-session time split between waiting and local commands | Whether changing the execution host addresses the delay |
| The project depends on x86 binaries | Native Arm build and identical application tests | Whether this job is ready to enter the hardware comparison |
| The aim is a smaller monthly bill | Charged CPU, memory time and total completed jobs | Whether an observed performance gain becomes customer savings |
These are evaluation criteria, not TechReadly measurements of Vera. Modal has described a planned rollout; the announcement does not supply a customer general-availability date, region list, customer CPU-selection control or Vera-specific tariff. A team can prepare its workload comparison now, but should distinguish that preparation from buying an already specified service.
Bernhardsson’s mixed-fleet position is the most useful part of the story for customers. It leaves room to assign work according to compatibility, price and measured results, and to reconsider the choice when Intel or AMD introduces a stronger alternative. I would keep that flexibility in the acceptance criteria: a successful Vera trial should make one class of jobs a better purchase, without requiring every other job to move with it.