We run persistent Vercel Sandboxes for coding agents (/sandbox 2.2.1, getOrCreate with a fixed name, persistent: true, node22, 8 vCPU / 16 GB, iad1). Each attempt calls stop() and later resumes with Sandbox.get({ resume: true }).
We measured the same CPU-bound test suite over 5 sandboxes, 25 sessions and 37 runs. The CPU was 87-90% busy, with 0-3% iowait and 0-2.6% steal:
- Sessions on 2.50 GHz Cascade Lake (CPU model 85): median 94.7 s (83-115 s)
- Sessions on 2.90 GHz Ice Lake (CPU model 106): median 68.3 s (58-104 s)
- Reruns within one session move by -9 to +4 s. Across sessions, the same run differs by up to 57 s.
- It isn't resume hydration: reading the whole 4.8 GB tree after a resume takes 3-7.5 s, and no warm-up helped.
Every resume draws a new host, so the same workload swings about 40% with placement. Keeping sessions alive with extendTimeout doesn't help us, because provisioned memory is billed while a session is up, and that's already about half our Sandbox bill.
Request: a way to ask for a CPU class (Ice Lake or newer) for Sandbox sessions, or to keep a persistent sandbox's host class across resumes.