Skip to content
sandboxer
Start free trial
Guides · Benchmarks

CPU Performance by Sandbox Size, Measured

Updated October 27, 2026 .md

Short answer: Measured on 2026-10-27 in eu-central, 3 runs per size. Single-thread speed was about the same on every size, a sysbench median of 2,130 to 2,297 events per second. All-thread throughput scaled with vCPUs, 4,553 on small, 8,424 on default and 16,824 on large, so the cost per unit of work stayed within about 8%.

Conditions#
Date and time 2026-10-27. small 09:38 to 09:40 UTC, default 10:19 to 10:22 UTC, large 10:22 to 10:25 UTC
Region eu-central
Sizes small (2 vCPU, 4 GB), default (4 vCPU, 8 GB), large (8 vCPU, 16 GB)
Runs One fresh sandbox per size, 3 runs of every test inside it, then the sandbox was deleted
Isolation One of our sandboxes at a time. Other sandboxes on the same account were running at the same time, so the host may not have been idle
Tools sysbench 1.0.20, 7-Zip 23.01, Python 3.12.3, all from Ubuntu 24.04's apt

These are measurements of Sandboxer only. We didn't run this on any other service, and results vary by host: your sandbox can land on a different machine, and busy neighbors move the numbers.

What lscpu showed#

On 2026-10-27, lscpu showed the same CPU in all three sandboxes. The CPU depends on the host machine a sandbox lands on, so yours can differ:

Model name:            AMD Ryzen 9 7950X3D 16-Core Processor
Thread(s) per core:    1
Hypervisor vendor:     KVM
flags (selected):      aes avx2 avx512f sha_ni

CPU(s) was 2, 4 and 8, matching the size. Each vCPU shows as its own core (one thread per core). AVX2 and AVX-512 are exposed, so libraries that pick vector code paths at runtime (NumPy, ffmpeg, compression tools) can use them.

Results#

Median of 3 runs, with the lowest and highest run. Higher is better, except for Python, where lower is better.

Test small default large
sysbench CPU, 1 thread (events/s) 2,297 (2,285 to 2,298) 2,130 (2,121 to 2,213) 2,237 (2,012 to 2,297)
sysbench CPU, all threads (events/s) 4,553 (4,550 to 4,570) 8,424 (8,146 to 8,502) 16,824 (16,374 to 17,130)
7-Zip 7z b, all threads (total MIPS) 11,381 (11,085 to 11,703) 16,451 (15,322 to 19,635) 38,261 (37,372 to 38,980)
Python loop, 1 thread (seconds) 1.10 (1.09 to 1.10) 1.21 (1.15 to 1.43) 1.19 (1.14 to 1.19)

How to read it:

  • Single-thread work doesn't get faster with size. sysbench on one thread and the Python loop landed within about 10% of each other on all three sizes. A bigger sandbox gives you more cores, not faster ones.
  • Multi-thread work scales with vCPUs. All-thread sysbench went 4,553 to 8,424 to 16,824 events per second: 1.85 times small on default and 3.70 times on large. Per vCPU that is 2,277, 2,106 and 2,103 events per second.
  • 7-Zip scales too, with more noise. large scored 3.4 times small. default had the widest spread of any test (15,322 to 19,635, about 26%), which points at a busy host during that window rather than at the size.
  • Spread was small on small (under 1% for sysbench and Python) and wider on the other two: about 13% for one-thread sysbench on large and about 23% for Python on default (1.15 to 1.43 s). Don't trust a single run; use the median of several.

Price per unit of work#

Prices from our pricing: small $0.018/hour, default $0.036/hour, large $0.072/hour, billed per second. Using the all-thread sysbench median, here is what 1 billion sysbench events would cost if a job kept every vCPU busy:

Size Hours for 1 billion events Cost
small 1,000,000,000 / 4,553.06 / 3,600 = 61.01 h 61.01 × $0.018 = $1.10
default 1,000,000,000 / 8,423.69 / 3,600 = 32.98 h 32.98 × $0.036 = $1.19
large 1,000,000,000 / 16,824.41 / 3,600 = 16.51 h 16.51 × $0.072 = $1.19

The price doubles with each size and so does the parallel throughput, so a job that uses all cores costs about the same on any size and finishes up to 3.7 times sooner on large. small came out about 8% cheaper per event because its per-vCPU score was a little higher in our runs.

The picture changes for single-threaded work. A one-thread job ran at the same speed on every size, so on large it costs 4 times what it costs on small. Pick the size by how many cores your workload actually uses:

Your workload Size to start with
One process, one thread (a Python script, most test runners without -j) small
A build or test suite run with -j4, or a few agents side by side default
make -j8, parallel compression, many containers large

You can grow a sandbox later with sbx resume <id> --type large. Moving to a smaller size isn't supported yet: create a new sandbox of that size and copy your files across.

The script#

This is the script we ran inside each sandbox, unchanged. It installs sysbench and 7-Zip, prints the CPU summary, then runs each test 3 times.

#!/usr/bin/env bash
# cpubench.sh: CPU benchmark for one sandbox, 3 runs of each test.
set -euo pipefail
sudo apt-get update -qq >/dev/null
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq sysbench p7zip-full >/dev/null
echo "nproc: $(nproc)"
lscpu | grep -E '^(Model name|CPU\(s\)|Thread\(s\) per core|Hypervisor vendor):'
echo "flags: $(grep -m1 -ow -E 'avx2|avx512f|avx_vnni|sha_ni|aes' /proc/cpuinfo | sort -u | tr '\n' ' ' || true)"
sysbench --version; 7z | sed -n 2p; python3 --version
for run in 1 2 3; do
  st=$(sysbench cpu --cpu-max-prime=20000 --threads=1 --time=10 run | awk '/events per second/{print $4}')
  mt=$(sysbench cpu --cpu-max-prime=20000 --threads="$(nproc)" --time=10 run | awk '/events per second/{print $4}')
  z=$(7z b -mmt"$(nproc)" | awk '/^Tot:/{print $4}')
  py=$(python3 -c 'import time;t=time.perf_counter();s=sum(i*i%7 for i in range(30_000_000));print(f"{time.perf_counter()-t:.2f}")')
  echo "run=$run sysbench_1t=$st sysbench_all=$mt 7z_total_mips=$z python_s=$py"
done

And this is how we ran it from our machine, once per size. The benchmark takes about two minutes, so we started it with --detach and polled for the result rather than holding one long request open:

id=$(sbx new --type large --name cpu-bench --json | jq -r 'select(.event=="ready") | .id')
sbx scp ./cpubench.sh "$id":/home/user/
sbx exec "$id" --detach "bash /home/user/cpubench.sh > /home/user/bench.out 2>&1; echo exit=\$? >> /home/user/bench.out"
until sbx exec "$id" "grep -q '^exit=' /home/user/bench.out"; do sleep 10; done
sbx exec "$id" "cat /home/user/bench.out"
sbx delete "$id" --yes

The large sandbox printed:

nproc: 8
CPU(s):                                  8
Model name:                              AMD Ryzen 9 7950X3D 16-Core Processor
Thread(s) per core:                      1
Hypervisor vendor:                       KVM
flags: aes avx2 avx512f sha_ni
sysbench 1.0.20
7-Zip 23.01 (x64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20
Python 3.12.3
run=1 sysbench_1t=2236.52 sysbench_all=17129.99 7z_total_mips=37372 python_s=1.14
run=2 sysbench_1t=2011.90 sysbench_all=16824.41 7z_total_mips=38980 python_s=1.19
run=3 sysbench_1t=2296.95 sysbench_all=16373.82 7z_total_mips=38261 python_s=1.19
exit=0

The three sandboxes together ran for about 8 minutes, including the apt install.

FAQ#

Does a bigger sandbox make a single-threaded script faster?#

No, not in our runs. One-thread sysbench and a Python loop ran within about 10% of each other on small, default and large, so a single-threaded job costs least on small.

Do vCPUs share a physical core with another thread?#

lscpu inside every size showed one thread per core, and all-thread throughput grew almost linearly with the vCPU count (2,277, 2,106 and 2,103 events per second per vCPU). The host details behind that aren't visible from inside the sandbox.

Will I get the same CPU model?#

All three of our sandboxes showed an AMD Ryzen 9 7950X3D on 2026-10-27. That isn't a promise: the CPU model can differ between machines, so run lscpu in your own sandbox. If your code is built for specific CPU flags, check for them at startup.

Why did the same test vary between runs?#

Other sandboxes share the host, so a busy neighbor can slow a run. Our widest spread was 7-Zip on default at about 26%. Run each test several times and use the median, as we did.

Can I run this on xlarge?#

xlarge (16 vCPU) needs the $100/month plan or higher, and we didn't measure it here. The same script works on any size; pass --type xlarge to sbx new.

More guides

Top AI sandbox platforms for code execution in 2026, ranked

For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.

Read the guide
Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked

For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.

Read the guide
Best Daytona sandbox alternatives in 2026, ranked

The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.

Read the guide
Best E2B alternatives in 2026, ranked

If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.

Read the guide