61, then 88, then 133, then 274. Same n2-standard-48 GKE node, same OpenClaw agent profile, four isolation and idle policies. That ladder is the July 30 Google Cloud post from product manager Drake Williams and engineering manager Steve Linde, packing more agents onto fixed capacity without pretending every replica is busy all day. Kata microVMs hit a wall at 61 before health checks failed regularly. GKE Agent Sandbox (gVisor user-space kernel instead of a full guest OS per agent) reached 88, +44%. Google says that was more than 40% more agents per vCPU and more than 30% lower cost per agent at a similar performance profile. Agent Sandbox went GA in May. Usage grew more than 7× in under four weeks. Demand signal, not a quality medal, but it explains why they're talking unit economics now.
Why 61 is a guest-OS tax, not a law of nature
Agents arrive in bursts. Think, call tools, write code, then idle waiting for a human or a webhook. Static VM math bills the idle stretch like peak. One microVM per agent, Kata and friends, buys hardware-backed boundaries and a guest OS on every replica. On Google's n2-standard-48 test that tax showed up as a hard stop at 61 OpenClaw agents. Not a universal constant. Calibrated baseline for this profile on this shape of machine. Fatter memory, GPU sidecars, stickier session state will move the cliff.
Agent Sandbox is Google's Kubernetes-shaped primitive for untrusted agent code: gVisor's Sentry intercepts and filters syscalls, production-grade isolation with a container-like footprint. 61 → 88 is that swap. MicroVMs and gVisor are different threat models. Teams that standardized on Kata for compliance still need their own review before chasing the chart. Google's claim is that gVisor-class isolation is the density sweet spot for many agent workloads, not a free upgrade for everyone.
I've sat through enough security reviews to know "gVisor is fine for this" and "our auditor expects Kata" can both be true in the same company depending on which workload and which questionnaire. The blog post does not settle that argument. It just gives the density side more ammunition.
Warm pools at 133, suspend/resume at 274
Active-sandbox density only fixes half the bill. Second move: orchestration aimed at idleness. GKE Pod snapshots checkpoint a frozen agent to persistent storage, free CPU and memory, then a lightweight controller or event gateway resumes when work arrives, milliseconds on the snapshot path, Google says, with broader startup targets depending on config. Oversubscribe without keeping every conversational agent warm forever.
Three latency temperaments in the post. Real-time coding assistant: sub-second starts, hates queues, snapshots plus Agent Sandbox warm pools. Interactive "autonomous teammate": a few seconds of restore via suspend/resume is fine. Headless nightly researcher: can wait for capacity. Performance-optimized warm-pool setup: 133 OpenClaw agents on the same node. Cost-optimized suspend/resume: 274, more than 3× the Kata baseline, with startup under five seconds. Combined messaging: up to ~3.5× density and up to 75% lower cost per agent for intermittent activity.
They name OpenClaw and Hermes as the open frameworks people bolt onto a VM and hope. That's why the ladder matters: early agent platforms inherit VM habits, then discover the idle bill after growth. Orchestration belongs in day-one architecture, not as a patch after the invoice. Also, this is not Kubernetes in-place pod resize. That hit GA in 1.35 (Dec 2025). Pod-level in-place vertical scaling went beta in 1.36 (April 2026). Different lever than Agent Sandbox / warm pools / suspend-resume for bursty agents. I've already seen people conflate the two in Slack. Please don't.
Millisecond resume claims deserve a skeptical eyebrow until you measure them on your storage class and your agent image size. Google's numbers are their numbers. Your EBS-equivalent latency is your problem.
By combining GKE Agent Sandbox with GKE's suspend and resume capabilities, you can freeze idle agents to oversubscribe fixed compute capacity. For agents with intermittent activity, this can enable up to 3.5x greater agent density and cost reductions of up to 75% per agent.
Vendor numbers, still useful as a sequence
OpenClaw on n2-standard-48 is a fair demo scaffold and still vendor benchmarking. Isolation mechanism plus idle policy dominate cost-per-agent more than raw node shopping once you're past toy scale, that directional lesson travels even when your cliffs differ. A tool-calling agent with a fatter memory footprint or GPU sidecars will not reprint Google's chart. Nobody serious thought it would.
If I were sequencing adoption the way the blog sequences the story: stop paying a full guest OS per mostly idle agent if security accepts gVisor (61→88, the >30% cost-per-agent claim). Classify agents by wake-up SLA before maxing oversubscription, 133 and 274 are different products sharing a node-pool strategy. Instrument thundering herds. Google names the failure mode: everything resumes at once and your savings become a latency incident unless warm-pool buffers and scheduling policy are tuned on purpose.
I've seen platform teams chase the 274 number first because it's the biggest. That's usually backwards. Warm pools and suspend/resume without a wake-up taxonomy just moves the outage from "we ran out of nodes" to "everyone woke up at 9:01." The compliance conversation about gVisor versus Kata also belongs before the spreadsheet celebration, not after someone has already promised finance a 75% cut.
"Scaling agents shouldn't mean linearly scaling the infra budget" is the slogan. Narrower version I'd keep: on this published test, sandbox choice and idle freezing moved cost per agent more than any "agentic era" architecture talk. Match the 61/88/133/274 ladder to your latency classes, then argue about whether 75% survives production traffic. I'd wait on that last number until you've seen a resume storm, and until your security folks have said out loud which isolation model they're willing to sign.
The 7× adoption note
Google's aside that Agent Sandbox usage grew more than 7× in under four weeks after May GA is doing a lot of rhetorical work. Demand is real. That much I'll buy. It does not prove the 274-agent configuration is what those new users are running. Most early adopters are probably somewhere between "we tried the sandbox" and "we redesigned idle policy." Don't let a growth multiple stand in for an architecture review. The ladder is still 61 → 88 → 133 → 274, and most teams will stop at a rung that matches their wake-up SLAs and their auditor's stomach.
Reproduce the OpenClaw profile on your own node shape before you promise finance anything close to 75%. If you can't reproduce even the 61→88 step, the rest of the blog is science fiction for your cluster. If you can, then, and only then, start arguing about warm pools versus suspend/resume like adults with latency budgets and a shared spreadsheet everyone actually opens.
61, 88, 133, 274. Keep the ladder taped above the desk. Ignore the slogans underneath it until your own numbers show up on a real production cluster you actually own, operate, observe closely, and pay for.
- Kubernetes
