# CPU Performance by Sandbox Size, Measured

> 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%.

Source: https://sandboxer.com/guides/cpu-performance-by-sandbox-size. Updated 2026-10-27.

**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:

```text
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](/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.

```bash
#!/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:

```bash
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:

```text
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`.

## Related

- [Machines and sizes](/docs/machines)
- [Billing](/docs/billing)
- [How fast does a cloud sandbox start, resume and fork?](/guides/how-fast-does-a-cloud-sandbox-start-resume-and-fork)
- [Run a long job in a cloud sandbox](/guides/run-a-long-job-in-a-cloud-sandbox)