The headline in browser-use’s engineering writeup is a price cut — cloud browser sessions from $0.06 to $0.02 an hour, starting in under a second. The operational story underneath is the part worth your time. The old unikernel setup was cheap at idle but couldn’t autoscale, so a single load test rode a traffic spike straight into a 45-minute production outage. Cheap-when-idle is a trap when your agents arrive in bursts.

For anyone running agentic systems, a browser is just a tool call, and every tool call needs an isolated, disposable sandbox you can spin up by the thousand and discard when the session ends. Their answer is Firecracker microVMs — but run nested inside EC2 instances that AWS has already virtualized, rather than on bare metal. Nested virtualization should be slow; most of the post is about clawing that cost back, and it ends by naming the real remaining bottleneck: Chromium startup, not the VM.

That last point generalizes. Once isolation is cheap, the long pole in agent tool latency stops being infrastructure and becomes the workload itself — the browser booting, the model’s first token, the cold cache. I hit the same wall budgeting latency for tool execution in production AI work: the sandbox gets solved, the thing inside it doesn’t. The HN thread has good back-and-forth on the nested-VM tradeoff and whether it holds under real adversarial load. If a browser session is sub-second and two cents an hour, does per-agent isolation stop being a cost argument and quietly become the default?