Agent-Substrate vs. Kubernetes' Agent-Sandbox CRD: What 30x Pod Oversubscription Costs You in Scheduling Complexity

Run 500 AI coding agents on Kubernetes the straightforward way — one Sandbox pod per agent — and you'll discover the same thing every platform team discovers: those agents are idle more than 95% of the time, waiting on a human, a CI run, or the next chat message, while their pods keep billing CPU and memory around the clock. Agent-Substrate, a new open-source project out of Google Cloud, claims it can pack that same fleet onto a shared worker pool at 30x+ oversubscription — many idle "actors" sharing a handful of always-on pods instead of each pinning one. Kubernetes SIG Apps' own Sandbox CRD, the project's more established sibling, doesn't do that; it gives every agent a dedicated pod with a stable identity and persistent storage, full stop.

CNCF Ambassador Lin Sun (Solo.io) laid out the contrast on July 7, 2026, and it's a genuinely useful one for anyone building a self-hosted PaaS that will host many tenants' mostly-idle coding agents. But the 30x number is only half the story a platform team actually needs. Getting it means giving up Kubernetes' native scheduling, RBAC, and quota enforcement for every agent workload — and rebuilding your own version of all three. Here's the concrete trade, and where it leaves a self-hosted agent-hosting roadmap.

What Agent-Sandbox actually gives you​

Kubernetes SIG Apps' agent-sandbox project ships a Sandbox CRD and controller that formalizes a pattern platform teams were already hand-rolling: a StatefulSet of size 1, a headless Service, and a PersistentVolumeClaim, glued together to approximate a single stateful, addressable workload. The CRD collapses that into one resource with purpose-built lifecycle controls:

• Stable identity — every Sandbox gets a fixed hostname and network address, so agents can discover and address each other the same way every time.
• Persistent storage — a sandbox's filesystem survives restarts, so an agent's working directory doesn't vanish between invocations.
• Hibernate and resume — a Sandbox can hibernate to disk and resume on the next network connection instead of staying billed and running while idle.
• SandboxWarmPool — a pool of pre-provisioned, pre-warmed pods that eliminates cold-start latency for the next agent that needs one.

That's a real answer to the cold-start and identity problems. On GKE specifically, Sandbox provisioning now runs at roughly 300 sandboxes per second at sub-second latency, with up to 30% better price-performance on Axion processors than comparable clouds — Agent-Sandbox already solved "spin up a sandbox fast." What it didn't solve is the unit of allocation. Every Sandbox is still one pod, mapped to one agent identity. A fleet of 500 mostly-idle agents is still 500 pods, warm-pooled or not — you're just paying for the idle time faster.

What Agent-Substrate changes: Actor vs. Worker​

Agent-Substrate breaks that one-pod-per-agent coupling on purpose. It splits the unit that has identity (an Actor — the logical agent, its state, its conversation history) from the unit that actually runs code (a Worker — a long-running, gVisor- or Kata-isolated pod that Substrate keeps warm and idle, waiting to be handed work).

When an event arrives for an actor, Substrate's control plane resumes that actor on any available worker, runs it for the burst of the invocation, then suspends it again — the worker goes back into the pool for the next actor that needs it. Because most agents in a real fleet are idle at any given moment, a small number of always-on workers can service a much larger number of actors. The project's own benchmark for that multiplexing ratio is 30x+ oversubscription: 30 actors' worth of agent identity riding on the compute footprint of one.

The mechanism that makes this possible is a deliberate step outside Kubernetes' own object model. Per the project's architecture docs, Substrate does not store every actor — active or idle — as a Kubernetes object the way a Sandbox is stored. Instead it runs its own control plane with four components that have no Agent-Sandbox equivalent:

1. A gRPC control-plane API for the data plane and CLI to manage actor lifecycles.
2. A State Store — currently Redis/ValKey — tracking the live mapping of Actors to Workers, sharded via Redis hash tags to scale past 1 million concurrent actors.
3. A Scheduler that picks a ready worker for each resumption request.
4. A Workflow Engine orchestrating the multi-step suspend/resume sequence: lock acquisition, storage download, sandbox restore.

Redis reads and writes here run sub-millisecond, which is the point — going through the full Kubernetes API server and scheduler for every wake event would add latency no request-scoped agent invocation can absorb. Substrate trades Kubernetes' generality for a purpose-built, high-QPS path.

The bill: what 30x density actually costs you​

That trade is the part a "just use the denser one" take skips, and it's the part a self-hosted PaaS team has to price in before committing an agent-hosting roadmap to it.

You stand up four new stateful components, versus zero for Agent-Sandbox. A Sandbox deployment adds one controller on top of primitives (StatefulSet, PVC, Service) your cluster already runs and already knows how to back up, monitor, and page on. Agent-Substrate adds a control-plane API, a Redis/ValKey cluster you now operate and keep highly available, a custom scheduler, and a workflow engine — four new failure domains with their own on-call story, on top of Kubernetes, not instead of it.

Actors are invisible to the Kubernetes control plane that already enforces your multi-tenancy. This is the cost that matters most for a PaaS hosting other people's agents. A Sandbox is a real Kubernetes object: kubectl describe shows it, a namespace-scoped RBAC Role gates who can touch it, a ResourceQuota caps how much of it a tenant can create, an admission webhook can reject one that violates policy, and every mutation lands in the standard Kubernetes audit log.

None of that machinery sees an Actor. It lives in Substrate's Redis State Store, addressed and scheduled entirely outside the Kubernetes API server. Every one of those controls — who can invoke which actor, how many concurrent actors a tenant gets, what gets audited — has to be reimplemented inside Substrate's own control plane, because the objects Kubernetes' policy layer would have governed were deliberately taken out of its view to hit that QPS target.

You inherit new tuning knobs with real cost/latency trade-offs of their own. Substrate's "Disk-Only Resume Policy," for instance, lets you skip restoring an actor's RAM state and resume from disk only — cheaper, but only correct for actors that can tolerate a cold-ish start. That's not a bug; it's an honest trade-off. But it's one more decision a platform team now owns that simply didn't exist when the unit of allocation was a full pod that never went away.

None of this makes Agent-Substrate a bad bet — 1M+ actors on a sharded Redis store is a legitimately different scale class than anything a per-pod model reaches. It means the 30x number isn't free: it's 30x density purchased with your team owning a second, non-Kubernetes-native control plane and rebuilding the RBAC/quota/audit surface that came for free with the CRD.

Where this leaves a self-hosted PaaS's roadmap​

For a platform hosting a handful of tenants' agents, or agents that run infrequently enough that idle-pod cost is noise, Sandbox is the right starting point and probably the ending point too: it's a Kubernetes-native CRD, it plugs into RBAC and quotas you already run, and SandboxWarmPool already kills the cold-start problem that would otherwise be the main argument for something fancier.

The calculus changes once idle-agent density becomes the actual line item — once you're hosting hundreds or thousands of tenants' coding agents that spend most of their lives waiting, and the always-on-pod tax shows up as real infrastructure spend rather than a rounding error. That's the point at which Agent-Substrate's shared-pool model is worth the second control plane, because the thing it buys you (30x fewer always-on pods) now outweighs the thing it costs you (a Redis-backed scheduling and policy layer you own end to end).

Lin Sun's actual argument is the more durable lesson here, and it's easy to miss if you read this as "which CRD should I pick": sandboxing and fleet efficiency are two different problems. Agent-Sandbox solves isolation, identity, and lifecycle for a single agent. Agent-Substrate solves density and scheduling for a fleet. A production agent-hosting platform — self-hosted or not — eventually needs both, and picking one CRD in isolation just tells you which problem you've deferred solving.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If you're weighing how to host a fleet of tenant-facing AI agents on infrastructure you control, that's exactly the kind of roadmap decision Bex is built around. Star the repo on GitHub or deploy your first app today.

Sources​

• Why sandboxing your agent is not enough — CNCF blog, Lin Sun, July 7, 2026.
• Why Sandboxing Your Agent Is Not Enough — Solo.io.
• kubernetes-sigs/agent-sandbox — GitHub.
• Running Agents on Kubernetes with Agent Sandbox — Kubernetes blog.
• Agent Sandbox documentation.
• Bringing you Agent Sandbox on GKE and Agent Substrate — Google Cloud blog.
• agent-substrate/substrate — GitHub.
• Agent Substrate architecture docs.