E2B reports up to 1,550 loaded sandboxes on an NVIDIA Vera server

By Elena Vasquez

E2B reported that four tuned runs on one dual-socket NVIDIA Vera server sustained 1,400 to 1,550 loaded sandboxes. The company published the pre-production results on November 9, 2026.

E2B’s target is the execution layer around an AI agent. The company’s sandboxes keep command sessions, files, and restored memory available to models that may run elsewhere. E2B’s design makes host capacity and memory movement central to the product’s operating case.

E2B provides isolated microVMs through an SDK. Agents can execute commands, work with files, and return to a preserved running state. Each sandbox resumes from a snapshot and loads its memory as needed.

Much of that session work happens on the CPU even when the model runs elsewhere. E2B therefore tested both individual operations and large numbers of concurrent environments.

What did E2B test on NVIDIA Vera?

E2B ran the Vera tests from October 9–13, 2026, on one pre-production dual-socket server with 176 physical cores and 1,479 GiB of RAM. The company took its AMD EPYC 9B45 reference measurements in August 2026.

E2B ran the Vera tests on that one host. It did not distribute the test across a cluster or treat it as a production deployment. The reported results therefore describe one pre-production host and the configurations E2B tuned for that host.

The single-server setup also narrows what the October results can prove. They describe one pre-production configuration, not a fleet spanning multiple machines. E2B lists a multi-node Vera cluster among its next steps. Single-host capacity does not automatically establish cluster-wide behavior.

The test design reflects an agent-runtime pattern: models may run elsewhere, while commands, file handling, and session restoration continue to consume local CPU and memory.

What did the microbenchmarks show?

E2B separated its bare-host processor and memory tests from its full-stack capacity runs.

• Compute: In a bare-host, single-thread compute test, E2B reports 7,759 events per second for Vera and 5,131 for the AMD EPYC 9B45. That equals 1.51 times the reference throughput, according to E2B, based on the median of at least three runs. The compute test used Vera’s 64K-page kernel.
• Memory: E2B populated a 2 GiB region using 4K kernels and 2 MiB huge pages, the same huge-page backing used by its sandboxes. E2B reports 62.8 GB/s for Vera and 17.4 GB/s for AMD, or 3.61 times the throughput. This measured memory population, not a complete sandbox startup. E2B calls the operation important for repeated snapshot-backed restores.

The compute figure counts raw events on a single thread. The memory figure measures how fast E2B can populate a region. E2B did not combine those primitives into an end-to-end agent benchmark.

Together, the microbenchmarks indicate stronger compute and memory throughput on Vera, without proving that every agent tool will gain the same speed on production workloads.

E2B also says gains for individual tools and applications will vary. According to E2B, its charts cover named systems in specific microbenchmarks. They do not establish equivalent end-to-end agent speedups or a fleet-capacity advantage over AMD.

The distinction matters to buyers comparing chips. E2B’s 1.51× compute result and 3.61× memory result describe different primitives under controlled tests. They cannot be combined into one blanket speed multiplier for E2B sandboxes.

How many sandboxes could E2B run under load?

The full-stack evaluation used E2B Embed, E2B’s single-machine packaging of the open-source E2B Runtime and dashboard, with the stack running directly on the host. E2B says Embed provides Firecracker microVM isolation and Python and JavaScript SDK support.

E2B’s evaluation covered sandbox creation, command execution, snapshot restore, capacity, and repeated creation and teardown. The company reports each operating measure separately rather than folding them into one end-to-end score.

The results combine several operational questions rather than one stress test. Startup tests cover already warmed environments. Command tests measure responsiveness. Churn repeatedly creates and removes environments. Capacity then asks how many can remain active while meeting latency and error targets.

E2B reports 50 ms warm, sequential sandbox starts and 3.8 ms command round trips at low load. Both figures came from separate Vera bare-metal tests, not fleet-load measurements. A separate churn campaign completed 22,145 create-and-destroy cycles with zero errors.

In the mixed capacity workload, each sandbox repeatedly performed a CPU burst, a 10 MiB disk write, and a pause. One in 10 sandboxes ran continuously. At the upper end of the capacity range, E2B reports 95th-percentile command round-trip latency of 255 ms.

When every sandbox ran continuously, a separate test sustained 550 sandboxes. E2B presents that as a distinct condition from the mixed workload, not as its overall peak.

E2B reserved 512 MiB per sandbox in those capacity runs. Their objectives required 95th-percentile latency to remain within 5× each run’s warmed burst baseline and imposed a 1% error limit per step. The result describes capacity under specified responsiveness and reliability targets, rather than an absolute loading limit.

E2B’s default host settings supported 320 sandboxes. E2B’s network-neighbor tuning raised that figure to 1,000 while leaving a 1,024-device limit in place. Full tuning was required for the main capacity result. E2B describes that progression as a same-server configuration comparison, not a Vera-versus-x86 speedup.

Those figures describe a tightly constrained workload, not a universal ceiling, because E2B defined acceptable service levels before counting sandboxes and required additional host tuning.

What remains unresolved before deployment?

These were pre-production results, not a production deployment. E2B found that x86 reference systems still completed some restore operations more quickly. Nested virtualization also requires additional work.

E2B took no cost or power measurements. That leaves the operating economics of a large Vera sandbox fleet outside the evaluation. For infrastructure buyers, the missing data matters as much as the peak sandbox count.

E2B lists three next steps:

• Test a multi-node Vera cluster.
• Back cold resumes with object storage.
• Compare against x86 using the same E2B packaging and host tuning.

Two questions stand between E2B’s test and production: whether a comparably packaged, tuned x86 system holds up in full-stack tests, and whether clusters preserve single-server capacity.

The next milestone is not another headline sandbox count. It is a matched x86 run, a multi-node Vera test, and cold resumes backed by object storage. Those results will help determine whether E2B’s single-server density survives broader fleet deployment or remains a pre-production benchmark.