Google open-sourced AX this week, Apache 2.0, and it picked up over 2,300 stars in a single day — enough to dominate every trending list I checked. The actual architecture is worth taking seriously on its own merits, separate from the headline number attached to it.
The core idea is a real, well-reasoned bet: an autonomous coding agent doesn’t behave like a normal piece of infrastructure. It’s not a stateless microservice handling quick request-response cycles, and it’s not a batch job that runs once to completion. It’s bursty and long-running — intense compute during reasoning and tool execution, then long idle stretches waiting on a model response, an external API, or a human to weigh in. AX is built specifically around that shape: agents run as actors you manage with a deliberately kubectl-shaped CLI — ax apply, ax get, ax watch, ax ssh into a running sandbox — with four core primitives (Task, Workspace, Gateway, Model) instead of forcing agent workloads into infrastructure patterns designed for something else. The standout feature is sub-second suspend and resume: ax suspend task test checkpoints a running agent and pauses it, ax resume task test picks it back up exactly where it left off, without paying to keep idle compute spinning the whole time it’s waiting on something.
It doesn’t run standalone — it sits on top of a separate project called Agent Substrate, which handles the actual sandboxed execution: a control-plane API, a node daemon for snapshotting agent state, an Envoy-based networking layer, and two different sandbox executors, one built on gVisor and one on lightweight micro-VMs. Worth flagging plainly: Substrate’s own repo explicitly marks itself “not an officially supported Google product” — a distinct, and notably lower, support tier than AX itself carries, despite AX depending on it entirely to actually run anything.
The “billions of tasks per cluster” line in AX’s own README is where the skepticism concentrated. When this hit Hacker News, that specific number drew the most pushback of anything in the thread — not the architecture, which most commenters treated as a genuinely sound way to model agent workloads, but the scale claim describing a project that had roughly 1,968 stars and 623 commits at the time anyone was actually checking. A young, actively-developing project making a “billions” claim about production scale it likely hasn’t been run at yet, by anyone outside Google’s own internal usage, is exactly the kind of number worth treating as aspirational marketing language rather than a verified benchmark — a distinction I keep coming back to on this site, most directly with Devin’s original SWE-bench framing.
None of that skepticism is really an argument against the project itself. Treating agents as stateful, suspendable actors instead of stateless services or throwaway batch jobs is a real architectural insight, and the kubectl-shaped interface is a sensible choice given how much operational muscle memory already exists around that pattern. It’s just worth separating “this models agent workloads correctly” from “this has been proven at the scale its own marketing claims” — two different questions, and only the research team behind it can currently answer the second one with anything more than a projection.
