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 ($0.15/hr × N × X). 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.
Warm pool (macOS)
Each Mac mini keeps 2 macOS VMs pre-cloned and pre-booted from a base image. When you call create(), the gateway picks a warm VM on one of your Macs, marks it occupied, and returns a sandbox_id — typically in under a second.
When you destroy() (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.
Apple simulators
Simulator sandboxes don't have a warm pool yet (WIP) — booting one takes ~45 seconds. Each Mac mini can run up to 2 simulator sandboxes concurrently.
The wire API route is type="ios" for historical reasons, while the Python SDK
exposes this as type=SandboxType.IOS. The simulator family can be selected with
family=SimulatorFamily.IPHONE, IPAD, or WATCH; underneath, the gateway
still receives a compatible device_type + runtime pair. Compatible pairs are:
| Device family | Runtime |
|---|---|
| iPhone | iOS |
| iPad | iOS |
| Apple Watch | watchOS |
The dashboard shows simulator families separately from installed runtimes. iPhone/iPad launch with the iOS runtime; Apple Watch launches once watchOS is installed on the fleet. If you omit both fields, the gateway defaults to iPhone 17 Pro on the latest installed iOS runtime.
Apple TV (tvOS) and Apple Vision (visionOS) simulators are coming soon.
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 other reservations or desktop platforms.
- The Macs go back into the available pool.
- Your row moves to "Past reservations" in the dashboard.