Budget one: memory, usually the binding constraint

This is the most straightforward budget: total unified memory, minus what macOS and whatever else is running on the host needs, divided among however many workspaces are running concurrently. The memory sizing post covers picking a per-workspace figure; multiply that by concurrent workspace count and check it against real available memory, not total installed memory — the difference matters more the fewer gigabytes you're working with. The memory balloon device gives some slack if a workspace is idling rather than under active load, but it's not a substitute for the arithmetic holding up in the first place.

Budget two: CPU, softer but real under concurrent load

The CPU performance post covers why every vCPU behaves like a P-core-priority thread with no efficiency-core fallback. The consequence for running several VMs at once: two workspaces each doing genuinely parallel, CPU-heavy work compete for the same limited P-core pool, and total available P-cores — not total vCPUs assigned across all your workspaces — is the real ceiling. This budget is softer than memory in one specific way: an idle or lightly-loaded workspace costs almost nothing here, so several mostly-idle workspaces running alongside one actively-busy one is a realistic, comfortable pattern. Several workspaces all doing heavy parallel work at the same moment is the case that actually hits this ceiling.

Budget three: disk space, and why it's cheaper than it looks

This is the budget most likely to be overestimated, because it's easy to assume each workspace costs its full allocated disk size. It doesn't, in practice: cloning a workspace from a base image is an APFS copy-on-write operation — covered in full here — meaning a freshly cloned workspace shares nearly all of its disk blocks with the base image it came from, and only starts consuming meaningfully more space as its content actually diverges from that shared starting point. Ten workspaces cloned from the same base image, lightly used, cost nowhere near ten times that base image's size on disk — genuinely more like the base image's size plus each workspace's own incremental changes.

Where this budget does bite: workspaces that diverge heavily from their base image (a full toolchain install, a large dataset written to disk) each carry that divergence as real, separate disk usage, and sealed base images themselves — covered here — are each a full, standalone copy that accumulates real space of its own if you don't prune old generations.

Putting the three together

A practical way to reason about your own ceiling: work out how many workspaces your memory budget allows if they're all running at once, treat that as the hard number, then check whether your actual usage pattern is "several running, one or two actively busy" (comfortable on the CPU budget) or "several all doing heavy parallel work simultaneously" (the case where CPU contention becomes the real limit before memory does). Disk space is rarely the binding constraint unless workspaces are diverging heavily from their base images or old base image generations have accumulated unpruned.

Related reading: how much memory to give a Linux VM, how vCPU core allocation actually works, and why cloning is cheap, the mechanism behind this post's disk-space math. Or download Velo Workspaces and try it yourself.