Lifecycle
Reservations, warm pool, and how sandboxes are reaped.
Why not sandboxes measured per second?
Because these are real Apple devices, not generic Linux VMs. Apple's macOS software license allows leasing Apple Software and Apple-branded hardware for permitted developer services, but the lease period must be at least 24 consecutive hours (AWS implements the same floor for the same reason). That makes per-second public billing the wrong abstraction for us.
So use.computer sells reservations: you reserve one or more physical Mac minis for at least 24 hours, and then create/destroy as many sandboxes as you need inside that reservation. The sandboxes still feel ephemeral — warm macOS VMs can be claimed in under a second and destroyed when idle — but the billing and isolation boundary is the Mac mini reservation.
Reservation
A reservation is a contract for N Mac minis for X hours. You pay up front (hourly rate × N × X) at the model's configured rate shown in the live dashboard. Activation binds physical Mac mini IPs to your reservation. Your account API key starts with uc_live_* and is managed in Settings.
The plaintext key is available to copy from Settings. The gateway stores a SHA-256 hash for inbound auth. When an account has one active Mac reservation, create() can infer it; if you have multiple active Mac reservations, pass reservation_id so the sandbox is constrained to the right Macs.
While the reservation is active, the gateway will only schedule sandboxes for you on those Macs.
Choose the Mac model when reserving with mac_model: m4 (the default; 10 cores, 16 GiB), m4-pro (12 cores, 24 GiB) or m5-pro (Apple M5 Pro, Mac17,16; 15 physical CPU cores, 24 GiB, nominal 512 GB SSD). You reserve the whole Mac in every case, for at least 24 hours. Check the live dashboard for each model's current price and availability; a reservation keeps the rate it was bought at, including for later edits.
Each sandbox create picks its own size with cpu, memory_gib and disk_gib. The sandboxes on one Mac can together use all of its cores and all of its memory, with at most two sandboxes per Mac. On an M4, for example, 7 vCPU + 3 vCPU works, and so does 4 GiB + 12 GiB. Fields you leave out use the model/layout defaults below. The smallest sandbox is 2 vCPU / 4 GiB, and disk_gib must be the image's disk size: disks are not resized at create. A create that doesn't fit is refused with resources_exceed_mac (bigger than the whole Mac), insufficient_capacity (bigger than what your other sandboxes leave free) or sandbox_limit_reached (the Mac already runs two).
vm_layout picks which VMs are pre-booted. On an M4, split (the default) keeps two 5 vCPU / 8 GiB VMs warm, and whole keeps one 10 vCPU / 16 GiB VM warm. On an M4 Pro, the sizes are two 6 vCPU / 12 GiB VMs or one 12 vCPU / 24 GiB VM. On an M5 Pro, split is 8 + 7 cores · 12 GiB each, and whole is one 15 vCPU / 24 GiB VM. Whole runs one sandbox at a time. Custom 7 vCPU / 12 GiB plus 8 vCPU / 12 GiB VMs can coexist on a split M5 Pro.
An M5 Pro default create or snapshot restore takes whichever split slot is available and reports its actual 7 or 8 vCPUs and 12 GiB; it does not promise the first slot or preserve a snapshot source's CPU count.
Existing reservations may retain earlier warm profiles until their Macs become idle, including M4-sized pools on an M4 Pro and legacy 12 GiB whole VMs. Their workloads and reservation end times stay unchanged; new reservations require the model's current profile.
New macOS 26.2 base images are base-macos-26 for split and base-macos-26-whole for whole. Use the reservation-scoped /v1/platforms catalog to discover currently available images and capacity; existing image names remain valid where offered.
On M5 Pro, the split base's 8 vCPU / 12 GiB settings seed only the first producer profile: the pool sizes the second clone to 7/12. The whole profile is 15/24. These are macOS 26.2 guest bases; the catalog, not the host OS version, determines guest image availability.
Reservation edits accept vm_layout; leaving it out preserves the current layout. Stop all sandboxes before changing layout. A layout change does not itself change the reservation price.
Warm pool (macOS)
Each Mac mini keeps a warm pool sized for its reservation layout: two split VMs or one whole VM. When you call create() without a size, or with the warm VMs' size, the gateway picks a warm VM on one of your Macs, marks it occupied, and returns a sandbox_id with boot: "warm". Any other size resizes a warm VM and boots it, which takes as long as a macOS boot (a minute or two); the response says boot: "cold". When your sandboxes leave too little room for the Mac's other warm VM, the gateway stops that VM and keeps it aside, so the VMs running on your Mac never add up to more than it has; your next sandbox boots from it, and it goes back to the warm pool once there is room.
When you delete() (or your sandbox times out), the gateway throws away the dirty VM and clones a fresh one in the background. The next caller already has a warm VM waiting.
Idle reaper
Sandboxes that go ~2 minutes without an HTTP touch, SSH session, or VNC connection are reaped automatically. For long exec or downloads, send a keepalive heartbeat from a sidecar thread.
End of reservation
When end_at passes:
- All your sandboxes are destroyed.
- The account API key stays valid for future reservations.
- The Macs go back into the available pool.
- Your row moves to "Past reservations" in the dashboard.