Google wants to cut the cloud bill for AI agents that spend most of their time waiting

When an AI agent is waiting on a human approval or a slow tool call, the underlying cloud VM is still running and still being billed. That idle time, multiplied across a fleet of thousands, is the line item enterprise platform teams are now flagging as the constraint. The three hyperscalers are converging on the same fix: teach the cloud to pause the agent without losing its place.

Google's entry is Agent Compute Engine (ACE), announced this week at AGNTCon and MCPCon. The service already powers Gemini as an agent for work tasks, and Google says it will open in preview "in the coming months." One outside analyst, however, told InfoWorld the engine is "not yet in preview", so treat any near-term availability claim as caveated.

The mechanism is the story. ACE runs multiple agents on a single operating-system template using copy-on-write memory sharing. When an agent is between turns, the host pauses the sandbox and writes its working state to a checkpoint. The next prompt restores the sandbox from that checkpoint rather than reinitializing it. Google also pairs ACE with its Titanium offload IPU for what the company calls "silicon-rooted defense-in-depth," a vendor characterization aimed at untrusted AI-generated code rather than an independent security claim.

A microVM is a small, fast-booting virtual machine with its own kernel, isolating one agent from its neighbors more strictly than a container, at the cost of more overhead per instance. That isolation matters because agents execute tool code and shell commands on behalf of users. The cost of isolation is also the trade-off: each microVM carries its own disk for working state, which InfoWorld notes raises storage spend and partially offsets the idle-time savings.

The price signal is the part a platform engineer can take to a budget meeting. Google lists Agent Compute at $0.085 per vCPU-hour and Agent Memory at $0.009 per GiB-hour, with usage rounded to the nearest second. Time the agent spends waiting for the next prompt between turns is not billed. The first 0 to 50 hours per project are free; after that, the same $0.085 rate applies. For a fleet of 1,000 agents idle 80% of the time, that "not billed" clause is the line item.

AWS has been running a version of this pattern since 2025: InfoWorld reports that AWS has run a microVM per session in AgentCore since 2025 and stops billing CPU while the agent waits. Per the AgentCore runtime-sessions documentation, every session runs in its own dedicated microVM with isolated compute, memory, and filesystem. The runtime lifecycle settings show a default 15-minute idle session timeout and a maximum session lifetime of 8 hours on microVMs, configurable from 60 to 28,800 seconds and extendable to 14 days on full Instances. Session storage can persist the filesystem across stop and resume. That is the same trick Google is now marketing.

Microsoft's hosted agents in Foundry take a third path, according to the same InfoWorld report: the environment suspends between turns and keeps the filesystem. That characterization comes from a trade-press source rather than Microsoft primary-source documentation, so the specifics should be hedged until Microsoft publishes equivalent lifecycle documentation.

Google, however, is claiming a step beyond suspending an environment between tasks. With ACE's checkpointing, memory and execution state are preserved so an agent resumes from where it left off rather than reconstructing its context and restarting execution. For long-running agents with large working sets, that distinction is where the cost math and the latency budget start to diverge.

The structural critique should not get lost. The "idle cost" problem is partly self-inflicted by agent architectures that block on synchronous calls. Suspendable compute is a useful workaround; it is not a fix. An agent harness that serially waits on a human approval, then a slow tool, then a human review, will spend most of its life paused. Re-architecting the harness to batch work, fire tool calls in parallel, and stream progress to the user can cut the bill more than any cloud feature. Vendors will not say that out loud because it reframes the savings story as a design problem rather than a platform feature.

Manoj Chandra Jha, principal analyst at Nord-IQ Research, told InfoWorld that as agents move from pilots to fleets of thousands, idle compute cost on traditional cloud becomes "a major binding constraint for a CIO." That is a stronger claim than the typical launch line, and it sets the bar for whether the hyperscaler rollouts actually help. Watch the storage line item on the next cloud invoice: if per-microVM disk scales linearly with the agent fleet, the idle savings will be partly clawed back. Watch the preview timing: Google says "coming months," Jha says "not yet." One of them is right, and the difference shows up in the next quarter's CFO briefing.