Budget one: memory, usually the limit

The simplest budget: total unified memory, minus what macOS and your other apps need, shared among the workspaces running at the same time. The memory sizing post covers choosing a per-workspace figure; multiply it by how many run at once and compare with the memory you really have free, not the total installed. The difference matters more the smaller your Mac. The memory balloon gives some slack when workspaces are idle, but the arithmetic still has to work.

Budget two: CPU, softer but real under load

The CPU post explains why every vCPU runs like a P-core thread with no efficiency-core fallback. With several VMs running, two workspaces doing parallel, CPU-heavy work compete for the same P-cores, and the number of P-cores, not the total vCPUs you've assigned, is the real ceiling. It's softer than memory in one way: an idle workspace costs almost nothing here, so several mostly idle workspaces next to one busy one is a comfortable pattern. Several all doing heavy parallel work at once is what hits the limit.

Budget three: disk, cheaper than it looks

This is the budget people overestimate, assuming each workspace costs its full disk size. It doesn't. Cloning a workspace from a base image is an APFS copy-on-write operation (covered here), so a fresh clone shares nearly all its blocks with the base image and only uses more space as it diverges. Ten lightly used clones of the same base image cost roughly the base image plus each one's own changes, nowhere near ten times the size.

Where disk does bite: workspaces that diverge a lot (a full toolchain install, a big dataset) carry that as real, separate usage; each saved base image is a full standalone copy (see pruning); and since 1.2, the cloud images and installer ISOs you download stay in Settings › Images until you delete them. A workspace created from a cloud image gets its own converted disk rather than a clone, so it costs roughly what the guest actually writes.

Putting it together

Work out how many workspaces your memory allows if they all run at once, and treat that as the hard number. Then look at how you use them: "several running, one or two busy" is comfortable on CPU; "several all doing heavy parallel work at once" is where CPU contention becomes the limit before memory does. Disk is rarely the limit unless workspaces diverge heavily or old base images and downloads pile up.

Related reading: how much memory to give a Linux VM, how vCPU allocation works, and why cloning is cheap. Or download Velo Workspaces and try it yourself.