Agent Substrate is worth a pilot if your agents run CPU-only on GKE Standard and can rebuild their database and MCP connections every time they wake. Google announced on November 5 that Agent Substrate 1.0 is generally available on GKE and that it is donating the project, gVisor and OpenRL to the CNCF. The GKE documentation sets limits the announcement leaves out: Standard clusters on 1.37 or later, no GPU passthrough into agent containers, and no open connections kept across a suspend. Google's install guide says there is no extra charge, so your cost sits in the GKE resources you run.
Every performance figure published so far is Google's own. Production terms also need confirming: Google's September post put production support behind an allowlist, and neither the November post nor the November 9 GKE release note listing the product as GA says whether that has ended.
What Google Launched on November 5
Google shipped a 1.0 release of an open source agent runtime and started moving it into neutral governance. Agent Substrate is a system you deploy on your own GKE Standard clusters that suspends an idle agent, snapshots its memory and files, and restores it onto a warm sandbox, per the overview docs. An Actor is one running agent. A Worker is the sandbox it runs in, and a WorkerPool is a group of pre-started Workers waiting for an Actor.
The argument for it is idle time. Google's open source blog says an interactive agent "can spend 90% to 95% of its time waiting for model inference, external APIs, or human reviews," and that with serverless containers, wakeup latency "climbs past 20 seconds." Substrate frees the sandbox while the agent waits and, by Google's figure, restores it in under 500 milliseconds.
Agents run as standard OCI containers, and isolation comes from gVisor or Cloud Hypervisor microVMs. The code is Apache 2.0, and Google says it also runs on any Kubernetes cluster. The launch post says Anthropic and OpenAI use gVisor to contain code execution, and that Ant Group, Modal and Tines have committed to join its maintainers. OpenRL, the third donation, handles reinforcement learning post-training and has no bearing on your runtime decision.
Is Agent Substrate Ready for Production?
Google says yes in its launch post, and a November 9 GKE release note lists it as GA for Standard clusters on 1.37 or later, but neither spells out support terms. The November 5 post says Substrate "is now generally available as Agent Substrate on GKE." Seven weeks earlier, the September 15 post said it was "available to all GKE customers for non-production workloads" and that "GA support for production is available via allowlist."
Neither the November post nor the release note mentions that allowlist. Google's general definition of GA is "open to all customers, ready for production use, and covered by a Google Cloud SLA, where applicable," which suggests the allowlist has ended, but Google has not said so for this product. The overview page and the install guide state no launch stage for the product and no SLA. The install guide does say that production support for one optional piece, Filestore agent volumes, "is limited GA, so you need to request access." Google's open source blog, published the same day as the GA post, calls the project "open source and ready for testing today."
The repository is more reassuring on API stability. Its README says "We will not break existing APIs or configuration formats without a major version bump," and in the same file that "the project is VERY young."
The CNCF move improves your exit options and governance. It tells you little about production readiness, since the CNCF's projects page describes Sandbox as "Experimental projects not yet widely tested in production." Named users are thin too. Google quotes SPIRITT's CEO on security isolation and density, and says design partner Nous Research is building Hermes Enterprise on it. Neither gives a production metric.
Which Clusters and Workloads Agent Substrate Rules Out
Check your clusters first, because Substrate turns away several common GKE setups before you run a single test. Google's docs say "Autopilot clusters and versions earlier than 1.37 aren't supported," so a company standardized on Autopilot needs a separate Standard cluster for this.
Clusters on the Extended release channel can't use the installer either. The install guide says it turns on beta versions of the podcertificaterequests and clustertrustbundles APIs, which that channel does not allow. If your change policy forbids beta Kubernetes APIs in production, take that to your platform lead now, because the product Google calls GA needs them to install. Machine series with mixed CPU architectures, such as E2, are out. The guide asks for c3-standard-4 or larger and GKE Dataplane V2.
GPUs are the hardest stop. "GPU device passthrough into Actor containers isn't supported," the docs say, and gVisor "can't snapshot live CUDA contexts." Asking for nvidia.com/gpu only places the Pod on a GPU node. An agent that calls a model endpoint is unaffected. An agent that runs local inference or GPU code inside its sandbox cannot use this runtime today.
High density takes manual work on existing clusters. Above roughly 800 concurrent sandboxes per node, the install guide requires higher inotify and ARP kernel limits, and the installer applies them only to clusters it creates.
gVisor or microVM: Decide Before You Size Node Pools
Use the microVM runtime when agents execute code derived from untrusted input and your security team wants a hardware virtualization boundary. gVisor is a user-space kernel that intercepts system calls before they reach the host. Its security documentation says "gVisor does not provide protection against hardware side channels" and "A sandbox is not a substitute for a secure architecture." The same page says side channels "may be exploitable by any code running on a system: native, sandboxed, or virtualized," so a microVM does not close that gap on its own. gVisor is still a strong boundary for most code, and Google's list of its users is long. Your security lead should sign off on it by name.
The microVM path costs you flexibility. It needs x86 nodes with nested virtualization or bare metal, and nested virtualization can only be enabled when a node pool is created. Skip that and your microVM Workers stay Pending. The x86 requirement also means Google's claim of up to 30% better price-performance on Arm-based Axion cannot apply to the microVM runtime. Our sandbox pricing comparison covers how much that boundary choice matters across vendors.
Why Database and MCP Connections Break on Resume
A suspended agent gets its memory and files back, and loses every live connection. Google's docs say "open network connections (such as database sessions or connections to MCP servers) aren't preserved when an agent suspends," and your agent code has to reconnect. A client object restored from the snapshot can therefore wake up holding a socket that no longer exists.
Database work is the simpler half. Rebuild the connection pool on resume and treat any open transaction as lost. MCP depends on which protocol version your servers speak. Under the 2025-11-25 specification, a server may assign a session ID, and a client that gets a 404 for that ID "MUST start a new session by sending a new InitializeRequest." AWS's AgentCore MCP contract notes that version 2026-07-28 removes the Mcp-Session-Id header and the initialize handshake and is stateless by specification, which removes much of this work. Older stateful servers, including those that use elicitation or sampling over an open session, are the ones to test first. A retried tool call after a reconnect can also repeat a write, so any tool with side effects needs an idempotency key.
Other runtimes have the same limit. E2B's persistence docs say that on pause "all the clients will be disconnected" and that after resume "you need to connect clients again." AgentCore stops the microVM after 15 minutes of inactivity by default and provisions new compute on the next call. Reconnect code you write for one will mostly carry over to the others.
Frequency is what differs. The docs say "your application suspends" the idle agent, so your orchestrator owns that decision and picks how often it pays the reconnect cost. Suspend aggressively to get the density Google advertises and you reconnect far more often than you would on a 15-minute idle timer.
What 'No Extra Charge' Still Leaves on Your Bill
You pay no fee for Substrate, and you pay for everything under it. The install guide says "Agent Substrate on GKE is offered at no extra charge" and that standard GKE pricing applies to the resources you create. Those include a 500 GiB persistent disk for the PostgreSQL database that tracks Actors and Workers, plus the snapshot bucket the installer creates.
The overview says "you pay for compute only when agents are actively processing tasks." That describes a single agent's share. The WorkerPool is, in Google's words, "pre-started, idle Workers," and those sit on Standard nodes you keep running whether or not an Actor lands on them. The savings depend on how many agents share that pool, so a fleet of 50 agents has far less to gain than one of 50,000.
Two costs never appear on the invoice. Your team owns upgrades and node pools on a cluster it may have to create for this, and the installer asks for roles including Project IAM Admin and Service Account Admin. Cost attribution is harder as well: DoiT's September 24 walkthrough warns that shared WorkerPools defeat per-actor cost tracking, though DoiT sells a product that addresses it.
How Substrate Compares With AgentCore, E2B and Modal
Choose Substrate when you already run GKE Standard at a scale that can fill a warm pool, and a managed service when you would be standing up a platform just for agents. Prices below were checked on each vendor's page on November 9, 2026.
| Isolation | Runtime price | What survives idle | Session limit | GPU inside the sandbox | |
|---|---|---|---|---|---|
| Agent Substrate on GKE | gVisor or Cloud Hypervisor microVM | No extra charge; GKE resources billed | Memory and files | None stated in GKE docs | Not supported |
| AgentCore Runtime v2 | Dedicated microVM per session | $0.1276 per vCPU-hour, $0.0169 per GB-hour | After the microVM stops, files only, with session storage | 8 hours per lifecycle; 14 days on Instances | Not on microVMs; GPU instance types on Instances |
| E2B | Firecracker microVM | $0.0504 per vCPU-hour, $0.0162 per GiB-hour | Memory and files | 24 hours continuous on Pro | Not offered |
| Modal Sandboxes | gVisor or VM | $0.0710 per vCPU-hour, $0.0240 per GiB-hour | Files, through filesystem snapshots; memory snapshots in alpha | 24 hours | gVisor runtime only |
Sources for the table: AWS pricing and session docs and Instances docs, E2B pricing and enterprise page, Modal pricing, Sandbox guide and snapshot guide. Modal lists $0.00003942 per core-second and defines a core as 2 vCPUs, so the table halves it.
Skip Substrate if you are on Autopilot, need GPU code inside the agent, or have nobody who owns Kubernetes upgrades. AWS shops should start with AgentCore, which stops billing CPU during I/O wait and is covered in our managed runtime pricing teardown. Small CPU-only fleets should price E2B first, since it also restores memory and needs no cluster. Google's own Agent Sandbox on GKE, GA since May 20 and able to suspend idle workloads with Pod Snapshots, is the lower-risk option if you want GKE without Substrate's control plane.
Google's Performance Numbers Need Your Own Test
Treat every Substrate figure as a target until you reproduce it, because neither Google post publishes hardware, workload or test conditions. The two November 5 posts do not even agree. The Cloud blog claims "more than 500 suspend and resume activations per second," while the open source blog says "thousands of agents can activate, suspend, and resume every second." The 10x density claim shifts baseline too, from "standard container runtimes" to "traditional compute" within the September post.
Snapshot size is the variable to probe. E2B publishes about four seconds per GiB of RAM to pause and about one second to resume, so a memory-heavy agent behaves differently from a small demo. Google says Substrate writes snapshots to local disk and Cloud Storage, which makes a resume on a different node the case to time. DoiT also reports that changing a container image invalidates existing snapshots, which affects every agent release you ship.
What to Do Before You Commit
This Week:
- Ask your Google account team in writing whether the September production allowlist still applies and what SLA covers it.
- Check your clusters against the hard stops: Autopilot, the Extended channel, versions below 1.37, E2 nodes and any agent that needs a GPU inside its container.
- Have one engineer list every place your agents open a database or MCP connection at startup and keep it in memory.
This Month:
- Run a suspend and resume test with a live database connection and a stateful MCP session. Pass means the first tool call after resume succeeds and no write runs twice.
- Measure p50, p95 and p99 resume times at your real memory footprint, on the same node and on a different node, against Google's 500 millisecond figure.
- Price the warm WorkerPool, PostgreSQL disk, snapshot storage and engineer hours against the same workload on AgentCore and E2B. Our runtime selection framework gives you exit criteria to score alongside it.
Before Production:
- Get your security lead to choose gVisor or microVM by name, and create node pools to match.
- Ship a new agent image during the pilot and record what happens to suspended agents.
- If portability is why you chose it, install on a non-GKE Kubernetes cluster once, and confirm which parts depend on the GKE tooling Google reserves for "eligible" customers.
The Bottom Line
Google has taken a project to the CNCF before. The CNCF accepted Istio as an incubating project in September 2022, and it graduated in July 2023. Substrate enters one level lower, weeks after Google described production use as allowlisted, so plan on a pilot this quarter and a platform decision after your own numbers come in.
Send Google the allowlist question today, and run the reconnect test before anyone budgets a cluster.
Continue Reading
- E2B vs Modal vs Daytona: Idle Time Sets Sandbox Bills
- Google Agent Runtime's $510 Meter Beats AgentCore's $846
- AWS Agents Run 14 Days. The Session Is the Only Wall.
- Mistral Studio Self-Hosted Agents Send State and Traces to Mistral
- MCP vs A2A vs OpenAPI: Which Agent Integration Standard to Use
- Agent Orchestration Platforms: Score Exit, Not Features