For most of the cloud computing era, the dominant mental model for compute has been disposability. Spin up a virtual machine, run a task, tear it down, pay only for what you used. Serverless functions pushed this further still, reducing execution windows to milliseconds and treating any persistent state as something to be offloaded to a database or object store. The model worked because the workloads it was designed for — request-response web traffic, batch data pipelines, scheduled jobs — mapped naturally onto that transient, stateless shape.
AI agents break that model entirely. A coding agent working through a complex feature branch does not complete in milliseconds. According to the team behind machine0, a Y Combinator S26 startup, these kinds of workloads routinely run for six to eight hours. Agent-orchestrated training runs and reinforcement learning loops can stretch across multiple days. The infrastructure assumptions baked into cloud platforms over the last decade — that compute is fungible, stateless, and ephemeral — do not hold when the software running on that compute is autonomously reasoning, accumulating context, and iterating over long horizons.
What machine0 Is Building
machine0 is a CLI-first platform that gives AI agents access to persistent cloud virtual machines billed by the minute. The core interaction is intentionally simple: a single command — machine0 new mybox — provisions a persistent cloud VM that the agent can drive directly. That machine stays alive between tasks. It accumulates state. It does not evaporate when the agent pauses or the network hiccups. This is a direct architectural response to the stateless, ephemeral nature of most existing cloud compute options, which were never designed with multi-hour agent workloads in mind.
The platform's pricing starts at around $0.013 per hour at the low end, scaling up to configurations with up to 60 virtual CPUs, 240 GB of RAM, and access to high-end GPU hardware including H100s and H200s. The claimed uptime target for VMs is 99.99% at the VM level, which is the kind of reliability guarantee that matters when a workload is expected to run for days without interruption. The specific SLA mechanics and how they handle interruptions at that tier are not fully detailed in available information.
The Shift From Ephemeral to Always-On Agent Compute
The distinction machine0 is drawing is more than a marketing angle — it reflects a genuine infrastructure gap that has become more visible as AI agents mature. Early agent experiments were often short-lived: a single prompt chain, a quick tool call, a one-shot code generation. The infrastructure needs of those experiments could be met by existing serverless or container platforms without much friction.
But the agents being deployed in production environments today are increasingly long-horizon. They are being asked to autonomously manage complex software projects, run multi-step research loops, and drive iterative machine learning experiments where each step depends on the accumulated output of all previous steps. These workflows need a stable execution environment — a place where files persist, processes stay running, and the agent can return to a known state after a pause. A fresh container spun up per-request cannot provide that. A serverless function with a hard timeout definitely cannot.
machine0's framing is that agent workloads are undergoing a structural transition: from ephemeral to always-on. The VM they provision is not a compute slot you borrow for a few seconds. It is, conceptually, a persistent workspace that belongs to the agent for the duration of its work — more analogous to a developer's laptop than to a Lambda function.
CLI and MCP as the Agent Interface
One of the more interesting technical decisions machine0 has made is in how agents interact with the platform. Rather than building a web console or an API-first abstraction, the primary interface is a CLI. Agents can drive the VM directly through the command line, and the platform also supports the Model Context Protocol (MCP) as an integration path.
MCP, which has been gaining traction as a standardised way for AI systems to interact with tools and services, allows agents built on compatible frameworks to treat the machine0 infrastructure as a first-class tool in their environment. This is a pragmatic choice: the developers most likely to be building sophisticated long-horizon agents are already working in CLI-heavy environments, and MCP support means the infrastructure can be wired into existing agent orchestration systems without requiring bespoke integration work.
The CLI-first approach also reflects a broader philosophy about who the customer is. machine0 is not primarily selling to web teams or DevOps engineers managing fleets of application servers. The target user is an agent — or, more precisely, the developer or system that is orchestrating the agent. That distinction shapes everything from the pricing model to the provisioning interface.
GPU Access and the Training Use Case
The inclusion of H100 and H200 GPUs in the machine0 lineup is significant because it signals that the platform is targeting more than just CPU-bound coding agents. GPU access opens the door to a class of workloads that are becoming increasingly central to how AI is developed and refined: agent-orchestrated training runs and reinforcement learning experiments.
When an agent is managing a training run — adjusting hyperparameters, monitoring loss curves, deciding when to checkpoint or restart — it needs the training infrastructure to remain live and accessible across the duration of that experiment. Spinning up a new GPU instance for each iteration defeats the purpose. The persistent VM model machine0 is proposing is better suited to this pattern: the GPU is allocated once, the training environment is configured once, and the agent can work against it continuously until the job is done.
The specific details of how GPU scheduling and preemption are handled — particularly for longer multi-day runs where hardware availability can fluctuate — are not fully detailed in available material, but this is a known challenge for any platform offering long-horizon GPU compute.
Why This Matters for the Broader AI Infrastructure Stack
machine0's launch on Hacker News as a YC S26 company places it in a broader conversation about what AI infrastructure should look like as agents move from demos to production systems. The current generation of cloud platforms was designed around human-driven workflows: a developer pushes code, a CI system runs tests, an application serves requests. The timing, duration, and statefulness assumptions embedded in those platforms reflect human work patterns.
AI agents do not follow human work patterns. They can run continuously for days. They generate and consume large amounts of intermediate state. They benefit from hardware environments that are stable and pre-warmed rather than freshly provisioned on each invocation. Recognising this, machine0 is making a bet that the infrastructure layer for agent compute will need to be purpose-built — that retrofitting serverless platforms or Kubernetes clusters is ultimately the wrong abstraction for workloads that are more like long-running processes than short-lived functions.
Whether machine0's specific approach — persistent VMs billed by the minute, driven through a CLI — proves to be the right model will depend on how agent workloads continue to evolve and how the broader ecosystem of agent frameworks and orchestration tools develops. But the underlying observation, that the shift from ephemeral to always-on compute is a genuine infrastructure transition, seems well-grounded in where the technology is heading.