Cua benchmarks Linux container starts at 235 ms on a Mac Studio

• Headless Linux containers reached a 235 ms median start on a Mac Studio, with Cua's comparison reporting 341 ms for microVMs and 637 ms for full VMs.
• A batch of 256 Linux Spaces finished starting in 26 seconds; Cua's batch test recorded zero failures across 2,560 creates.
• One Mac held 448 idle containers in Cua's density run. That figure measures idle capacity.
• A VM fork answered its first command in 329 ms from an existing checkpoint, according to Cua's fork test.

Cua's startup methodology discloses a 13-second first create excluded from the 235 ms headline: it pulls the image and records a golden snapshot. Its 256-Space burst keeps at most 64 create calls in flight.

Cua measured the startup comparison on October 25 using Spaces 0.15.0 on a 12-core M2 Max Mac Studio with 96 GB of RAM. Median create-to-first-command times, across 30 serial samples per mode, were:

• gVisor container: 234.6 ms, running inside the shared Lima Linux runtime VM.
• microVM: 341.1 ms, with one Virtualization.framework VM per Space.
• QEMU VM: 637.3 ms, using QEMU 10.2.2 with Apple's HVF accelerator.

Each Space was configured with 1 vCPU and 1 GiB of memory, running only cua-spacesd without a desktop. The timer includes create, attach and the first successful sh -c true.

The warm pool was disabled, but default golden snapshots remained enabled: subsequent creates restored the snapshot recorded during the excluded warm-up. With golden snapshots disabled for gVisor, a separate ten-sample run reached a 257.9 ms median; equivalent snapshot-free microVM and QEMU results were not published.

Cua used rollout_bench create --n 256 --conc 64 --keep for the batch benchmark. All 256 headless gVisor Spaces shared one already-running Linux runtime VM configured with 4 vCPUs and 32 GiB of memory.

The 26.05-second median spans the first create call through the last Space's first successful command. Batch times ranged from 25.16 to 26.59 seconds across ten runs; Cua deleted all Spaces and allowed ten seconds for the host to settle between batches.

Cua increased the population in steps for its density benchmark, probing every running Space with ten serial command round trips after each step.

• 448 gVisor containers: the last step where every check passed. Command p95 was 5.9 ms, versus 4.9 ms with one Space; creates and command checks failed at the next step, 512.
• 126 microVMs: the run hit the documented macOS limit of 128 VMs per host, with two slots already occupied by other VMs.

Both populations were idle and headless. Cua explicitly says running a workload in each container lowers the achievable count.

Cua's fork benchmark used a QEMU VM checkpoint holding 300 MB in RAM and 100 MB on disk. The clock starts at the fork call against that existing checkpoint and ends when the fork answers its first command.

Across 30 serial samples, the median was 328.8 ms and the slowest was 447.9 ms. Creating the checkpoint sits outside that timing.

Cua did benchmark nerds a favor by pinning its reproduction steps to the public cua-spaces-v0.15.0 release tag. Those steps compile the Rust SDK's rollout_bench and channel_bench examples; the promised cua bench run wrapper is not in a release yet.

Individual results include CSV samples, machine details and commands, with the suite also available as machine-readable JSON. The benchmark index still marks these workloads “To be measured”:

• Windows and macOS Space startup on a Mac.
• Browser sessions per hour on one Mac and across a mixed fleet.
• Whether work survives machines failing mid-run.