Ask an AI assistant to fix a website and the job can continue long after it has written a proposed change. It may need to download software, start the application, run tests and inspect the errors. Each of those steps needs a computer to do real work before the assistant can decide what to try next.
Advertisement
Modal rents out cloud computers for this part of the job. On October 19, it said NVIDIA’s Vera CPU—a processor that executes software instructions—finished up to twice as many benchmark tasks as a comparable Intel Granite Rapids system in its early tests with many jobs running together. Modal plans to add Vera to its service. The result offers a reason to investigate how a busy computer could keep more AI work moving.
That makes this a story about the waiting behind AI. Choosing a capable model is one part of getting a task done. The computer carrying out its instructions can also become the reason a user is still watching a progress indicator. My view is that Vera deserves a trial where that computer is the source of the delay. Its value to customers will depend on whether the complete job gets better, including the bill.
Where the Waiting Comes From
A model generates instructions: change this file, run this command, check that result. An AI agent connects those instructions into a sequence, using tools and feeding their results back to the model. The computer executing a command might be your laptop, or it might be a server in a data center.
Modal’s Sandboxes provide a separate workspace for running code. Its documentation gives examples such as checking out a project, running a test suite and executing code generated by a language model. A sandbox lets a service give each job an isolated place to work, rather than putting every customer’s files into the same workspace.
Separate workspaces can still share the resources of a physical server. Think about several people using the same computer at once: opening a small file may be easy, but several large jobs arriving together can make everyone wait. The relevant question is how much work the shared machine can handle while keeping each job moving.
For someone using an AI coding service, the distinction is mostly invisible. A screen may say that the agent is working whether it is waiting for a model’s answer, downloading a package or running a test. Those delays need different fixes. A faster execution computer helps most when local commands are the part holding up the job; it has less leverage over time spent waiting for an outside service.
Two Different Meanings of Faster
Imagine a service that completes more customers’ tasks during its busiest hour while each customer waits about the same amount of time. The operator has gained useful capacity. That is a different benefit from cutting one customer’s waiting time in half. Both improvements matter, but they answer different questions.
The first is called throughput: the amount of completed work over a period. The second concerns latency: the time one job takes. Modal’s reported up-to-twofold gain concerns throughput under load. Its engineering account says the gain was strongest when many tasks competed for resources. Tests run one at a time on a quiet machine showed mixed results, with Vera ahead on some tasks and behind on others.
That distinction gives the announcement a practical audience. A company running many agents at once may care deeply about preserving response times during a rush. An individual whose agent mainly waits for the model to answer has a different problem. The same hardware headline cannot tell both readers how much time they will save.
A simple example shows why. Suppose a hypothetical task spends 60 seconds waiting for model or network responses and 40 seconds executing local commands. Even if a new computer halves the command time, the whole task falls from 100 seconds to 80 seconds. That is a 20% reduction. This is an illustration, not a Vera test result; Modal’s throughput measurement does not establish that an individual task’s command time will halve.
Inside the Test
Modal published a benchmark called Agentless Agent Bench. Its README describes 50 tasks from Terminal-Bench 2.1, using supplied correct solutions. The computer follows those prepared solutions and checks their results. A live model is not choosing each next step, and network activity has been removed. The test therefore gives a clearer view of local execution work than a full conversation with an AI would.
The software environments are also prepared before timing starts. That is useful when the question is how a busy computer handles repeated work. It leaves out parts of a customer’s experience, including waiting for the model and some of the preparation needed to start a fresh job.
The public implementation counts an iteration as completed only when its solution and verification succeed. It also records failures. Tasks repeat during a timed window, so a short task can finish more repetitions than a long one. The total depends on which jobs are included and how they are mixed. It is not a count of entirely new customer projects solved by an AI.
For a buyer, the next comparison should keep a recognizable job intact: the same project, commands, tests and definition of success. Count how many jobs finish correctly, and check whether the slowest jobs become more tolerable. Otherwise, a busy server can look productive while the particular task a customer cares about is still stuck.
The Programs Must Work on the New Chip
NVIDIA offers Vera for standalone servers as well as systems containing its graphics processors. This matters because Modal’s announcement concerns the computers executing agents’ commands, rather than a newly released language model.
There is a software move to make, too. Vera uses Arm instructions, while Modal’s existing Intel and AMD fleet has used x86 instructions. These are different processor families. Software written in a portable language may be straightforward to move, but a project can depend on prebuilt components that target a particular family.
Containers package an application with its software dependencies, but the package still needs to suit the processor. Docker, a widely used container system, distinguishes Arm and x86 build targets. Its documentation also describes emulation, which makes one kind of processor imitate another. Docker warns that this can be much slower for demanding work such as turning code into a runnable program or compressing files. Modal has not promised an emulation option for Vera.
The practical first step is therefore ordinary: can the project build and pass its tests on Arm? A team whose software already works there has less migration work to recover. A team dependent on an x86-only component may have a good reason to keep that job on an existing server. Modal has not announced that every current software configuration is already available on Vera.
What Happens to the Bill
A platform can fit more work onto a server without automatically charging every customer less. Its costs and the customer’s invoice are related through the service’s pricing rules. The useful question is what resources a completed job consumes and what the customer pays for them.
Modal’s current sandbox documentation says customers are billed by the second for the higher of their requested or actual resource use. A request reserves a minimum. When the host has spare capacity, a sandbox can use additional resources, but that extra capacity is not guaranteed. Using more CPU at once can affect the charge even if a job finishes sooner.
A small example makes the pricing easier to picture. Under Modal’s October 20 sandbox list rates, one physical CPU core and one GiB of working memory would together cost about 17 U.S. cents if metered at those levels for a full hour. Working memory is the space programs use while they are running. These are the sandbox rates, which differ from Modal’s general CPU-task rates.
That example excludes plan charges, credits, storage, network transfer, model calls and other resources. It also is not an announced Vera price. A faster job might hold memory for less time or use a different amount of CPU. Those measured quantities, together with the applicable prices, determine whether the invoice improves. A doubled host-level work count cannot settle the calculation on its own.
What Customers Should Take From This
Stephen Nellis’s Reuters report adds a useful detail: Modal chief executive Erik Bernhardsson says Vera will join Intel and AMD in a mixed fleet. The company plans to test newer rival processors when they become available. It is keeping the option to put each kind of work on hardware that suits it.
That approach fits the customer problem. A useful service does not need every job to run on the same processor family. It needs the right software to run reliably, finish within an acceptable time and cost an acceptable amount. These are the questions I would bring to a trial:
| What you notice | What to compare |
|---|---|
| Commands slow down when many agents work together | Correctly finished jobs and individual waiting times at the same demand |
| Most waiting happens between commands | Time spent on model responses and network requests, compared with local execution |
| A project uses components built for x86 | Whether the same project builds and passes its tests on Arm |
| The goal is a smaller bill | Actual charged resources and the cost of each successfully completed job |
These are decision criteria, not TechReadly measurements of Vera. Modal’s announcement does not provide a customer launch date, region list, Vera-specific price or a way for customers to select that CPU. Preparing a suitable test is possible now; a purchase still needs a defined service offer.
For users of an AI assistant, the broader lesson is useful even if they never choose a processor themselves. The model writes the proposed instructions, but a computer still has to carry them out. I would judge the service by how well that whole sequence works. Vera’s strongest case is where a better execution computer removes a delay people actually encounter.