An agent can decide which command to run in a moment. It still needs a computer to execute it. At E2B, we give agents isolated computers through a simple SDK.
Our runtime has no cold start. Every sandbox begins by resuming a snapshot, with memory loaded only as needed, so agents can get to work quickly. NVIDIA Vera fits that design: fast compute, strong memory bandwidth for snapshot restores, and capacity for many sandboxes on one server.
We tested those strengths. Vera delivered 1.5× the single-thread compute throughput and 3.6× the memory-population throughput of our AMD EPYC 9B45 reference. Running E2B on one dual-socket Vera server, we sustained 1,400 to 1,550 concurrent loaded sandboxes within our test’s latency and error objectives.
Those results give us a clear reason to keep building on Vera. They address two needs at the center of E2B: making individual environments responsive and supporting many of them together.
Why Vera matters for agent workloads
A coding agent fixing a bug might search a repository, edit a file, run a test, and inspect the failure. Each operation needs a real environment: a shell, a filesystem, dependencies, and processes that can keep running between calls.
E2B provides that environment in an isolated microVM. Developers create and manage it through our SDK. The agent can execute commands and work with files, while E2B handles the environment’s lifecycle.
An agent can also pause a session and return to its files and running state later. As work spans more commands and longer sessions, the speed of starting, using, and restoring those environments becomes part of the product developers build.
Much of that work happens on the CPU. When a test blocks the next step, faster execution can help the agent move forward sooner. Across a longer task, those waits repeat. CPU performance matters even when the model runs elsewhere.
The workload also changes throughout a session. One sandbox is waiting for a model response. Another is installing a package. A third is running a script. Across hundreds of sessions, those phases overlap.
Vera combines strong performance for individual operations with resources for a large sandbox fleet. We tested both, from the processor and memory paths through the full E2B lifecycle.
Vera delivers 1.5× single-thread compute throughput
In our single-thread compute test, Vera delivered 7,759 events per second, compared with 5,131 on the AMD EPYC 9B45 reference. That is 1.51× the throughput.
That is a meaningful advantage for CPU-bound work. An agent cannot always parallelize its next step; it often needs the current command’s output first. Vera’s result gives us a stronger compute foundation for those sequential operations. The gain for individual tools and applications will vary.
3.6× faster memory population for sandboxes
Memory performance connects to how we start sandboxes. E2B resumes environments from snapshots and populates their memory as they run. We tested the memory-population operation using the same 2 MiB huge-page backing our sandboxes use.
Vera reached 62.8 GB/s, compared with 17.4 GB/s on the AMD reference: 3.61× the throughput.
| Benchmark | NVIDIA Vera | AMD EPYC 9B45 | Vera throughput |
|---|---|---|---|
| Single-thread compute | 7,759 events/s | 5,131 events/s | 1.51× |
| Memory population, 2 MiB huge pages | 62.8 GB/s | 17.4 GB/s | 3.61× |
For E2B, this is a particularly useful strength. Starting and resuming environments happens throughout the day. A faster memory-population path helps the runtime bring sandbox memory into use efficiently, making Vera attractive for infrastructure built around snapshots.
These component results make Vera compelling. To understand how they translate to a working environment, we also tested the complete E2B stack.
Vera supports 1,550 loaded sandboxes on one server
We used E2B Embed, the single-node distribution of our open-source runtime, with the stack running directly on the host. The evaluation covered creation, command execution, snapshot restore, capacity, and repeated creation and teardown.
On Vera bare metal, we measured 50 ms warm, sequential sandbox starts and 3.8 ms command round trips at low load.
50 ms sandbox start · 3.8 ms command round trip
Warm, sequential starts and low-load command round trips were separate tests on Vera bare metal. These are not fleet-load latencies. Evaluation figures 7–8, page 11.
Those results show Vera supporting both sides of an agent session: getting an environment ready quickly and keeping command overhead low as the agent works. We then tested how much work the server could support as the fleet grew.
Each sandbox ran a repeating cycle of a CPU burst, a 10 MiB disk write, and a pause. One in ten ran continuously.
Across four tuned runs, the server held 1,400 to 1,550 loaded sandboxes within the test’s objectives. At 1,550, command round-trip latency was 255 ms at the 95th percentile. When every sandbox ran its work loop continuously, the host sustained 550.
For E2B, that is useful capacity: many isolated environments sharing one host while doing real work within defined latency and error objectives. The mixed workload captures an important characteristic of agent sessions: periods of activity interspersed with waiting. Capacity depends on that workload shape.
Vera also had capacity that our initial host settings were not making available. Early runs hit network and device limits. With E2B’s admission caps already raised, correcting those settings moved the same server from 320 sandboxes to as many as 1,550.
This is where hardware and runtime engineering meet. Vera provided the resources; tuning E2B’s host configuration let us put more of them to work. The evaluation gave us concrete improvements to carry into our host setup.
Sandboxes are created and destroyed throughout the day, so we tested that path separately. Our churn campaign completed 22,145 create-and-destroy cycles with zero errors.
22,145 cycles. Zero errors.
Separate create-and-destroy campaign on Vera bare metal.
A stronger foundation for E2B’s agent cloud
Consider a team evaluating a coding agent across a large set of tasks. Every attempt needs its own environment, and the team wants to run attempts in parallel without managing a separate server for each one.
E2B handles the isolated environments, their state, and their lifecycle. Vera’s results show a promising way to support that work: faster compute and memory population in our benchmarks, alongside substantial capacity running our sandbox stack.
For developers, the opportunity is straightforward: responsive environments for individual agents and capacity to run many attempts in parallel. E2B makes those environments accessible through an SDK. Vera gives us a strong hardware foundation to build on.
Our next steps are a multi-node Vera cluster, cold resumes backed by object storage, and an x86 comparison using the same E2B packaging and host tuning. These will extend the evaluation from a single server toward the demands of a larger agent cloud.
Vera has already demonstrated strengths in operations our runtime depends on and in running a large fleet of E2B sandboxes. That combination is why we see it as a compelling platform for the next generation of agent workloads.
You can start building with E2B today. We will share more as our Vera evaluation progresses.
Methodology
Vera tests ran October 9–13, 2026, on one pre-production dual-socket server with 176 physical cores and 1,479 GiB RAM. AMD reference measurements are from August. Compute uses Vera’s 64K-page kernel; memory population uses 4K kernels and 2 MiB huge pages. Capacity tests used E2B Embed with raised caps and tuned host settings. 95th-percentile latency objectives were within 5× each run’s warmed burst baseline, with an error limit of 1% per step. Startup, low-load command latency, capacity, and churn were separate tests.
Comparison scope
Compute and memory charts compare named systems in specific microbenchmarks. They do not establish equivalent end-to-end agent speedups or a fleet-capacity advantage over AMD.
Capacity scope
Range across four tuned runs: 1,400–1,550. Sandbox memory reservations were 512 MiB each. The full-busy test and the mixed-load test are separate workload shapes.
Evaluation status
This is a pre-production evaluation. Some restore paths remain faster on the x86 references, and nested virtualization needs further work. Cost and power were not measured.