machine0's CLI-First Agent Compute: How Persistent VMs and Minute-Level Billing Change Agent Deployment Economics

machine0 (YC S26) ships a CLI that provisions persistent VMs for agent workloads. Instead of serverless functions or container orchestration, agents get dedicated compute they control directly: machine0 new mybox spins up a VM with static IP, HTTPS endpoint, and minute-level billing starting at $0.013/hr. The platform targets long-horizon agent tasks where ephemeral compute creates state management friction and per-request pricing becomes expensive.

The architecture choice matters because it shifts orchestration boundaries. Agents drive their own infrastructure via CLI commands or Model Context Protocol (MCP) servers, rather than being scheduled by Kubernetes or triggered by API gateways. This creates different failure modes, cost profiles, and security surfaces.

CLI-Driven Provisioning vs. API Orchestration

Most agent platforms abstract infrastructure behind APIs. You POST to an endpoint, the platform schedules a container, runs your code, and tears it down. machine0 inverts this: the agent itself runs CLI commands to provision, suspend, snapshot, and resume VMs.

Tool boundary implications:

Every operation is a CLI command with --json output, making it trivial to wrap in agent tool definitions
Agents can snapshot their own state mid-task, suspend billing, and resume later without re-provisioning
No orchestrator sits between the agent and the VM, which reduces latency but removes centralized policy enforcement

The MCP server integration means agents using Claude Code or Codex can drive VM lifecycle programmatically. You inject MCP servers, credentials, and environment variables via profiles, and the agent sees them as available tools.

State management trade-offs:

Approach	State Persistence	Billing Model	Agent Control	Failure Recovery
Serverless (Lambda, Cloud Run)	Ephemeral, external storage required	Per-request or per-100ms	None, platform-scheduled	Automatic retry, no state
Container orchestration (K8s)	Pod-level, requires PVCs	Per-second, minimum pod size	Limited, via API	Restart policies, health checks
Persistent VMs (machine0)	VM-level, survives restarts	Per-minute, suspend to stop	Full, via CLI or MCP	Agent-driven snapshots, manual recovery

Minute-Level Billing and Long-Horizon Economics

Serverless pricing optimizes for short bursts. AWS Lambda charges per 1ms increment after the first request. Google Cloud Run bills per 100ms. If your agent task runs for 45 minutes analyzing documents, you pay for 45 minutes of compute at sub-second granularity, but you also pay for cold starts, network egress, and any external state storage.

machine0 bills per minute with no cold starts. A 2 vCPU / 4 GB VM costs $0.052/hr ($0.00087/min). Run it for 45 minutes: $0.039. Suspend it when idle: billing stops, state persists. Resume it later: no re-provisioning, no warm-up.

When this matters:

Document processing pipelines that run for hours but have idle periods
Browser automation tasks that need consistent session state across multiple interactions
Model fine-tuning or inference workloads that benefit from dedicated GPUs (H100s at $0.836/hr base)

When it doesn’t:

Sub-minute tasks where serverless cold start amortizes quickly
Workloads that need automatic horizontal scaling based on queue depth
Tasks where you want the platform to handle retries and dead-letter queues

99.99% Uptime SLA and Agent-Controlled Failure Modes

machine0 guarantees 99.99% VM-level uptime. That’s 4.38 minutes of downtime per month. For comparison, AWS EC2 guarantees 99.99% for a region (not per-instance), and GCP Compute Engine offers 99.99% for instances with live migration enabled.

The catch: agents control their own recovery. If a VM goes down, the agent must detect it and decide whether to resume from a snapshot, restart the task, or fail gracefully. There’s no built-in retry logic or circuit breaker.

Failure scenarios:

VM crash during long task: Agent loses in-memory state unless it snapshots periodically. No automatic checkpoint-restart like AWS Batch or Kubernetes Jobs.
Network partition: Static IP remains reachable, but if the agent’s control plane (the machine running the agent orchestrator) loses connectivity, it can’t issue CLI commands to recover.
Agent logic error: If the agent suspends a VM mid-task and forgets to resume it, the task stalls indefinitely. No timeout enforcement.

Mitigation patterns:

Wrap CLI calls in idempotent scripts with retry logic
Use external state stores (S3, Postgres) for checkpoints, not just VM snapshots
Implement heartbeat monitoring outside the VM to detect silent failures

Security Boundaries When Agents Control Infrastructure

Giving agents CLI access to provision VMs creates privilege escalation risks. If an agent’s prompt injection vulnerability allows arbitrary command execution, the attacker can spin up GPU instances, snapshot sensitive data, or pivot to other VMs via static IPs.

Attack surface:

Credential leakage: CLI credentials must be scoped. If an agent stores machine0 API keys in environment variables, a compromised agent can provision unlimited resources.
Snapshot exfiltration: Agents can snapshot VMs and export disk images. If the VM contains secrets or training data, this becomes a data exfiltration vector.
Lateral movement: Static IPs and HTTPS endpoints (<vm>.mac0.io) are publicly routable. If one VM is compromised, it can scan and attack others in the same account.

Hardening strategies:

Use short-lived tokens with VM-specific scopes, not account-wide API keys
Audit snapshot creation and enforce retention policies
Segment VMs by network policies (machine0 doesn’t document VPC or firewall controls, so assume flat networking)
Monitor CLI command logs for anomalous provisioning patterns (e.g., sudden GPU VM creation)

Deployment Shape: NixOS Reproducibility vs. Ubuntu Flexibility

machine0 offers two base images: NixOS with flakes for deterministic builds, and Ubuntu with Docker, Node, Python, Claude Code, and Codex pre-installed.

NixOS path:

Declare your environment in a flake, get bit-for-bit reproducible builds
One-command rollbacks if an agent breaks the environment
Steeper learning curve, but eliminates configuration drift

Ubuntu path:

Familiar tooling, faster onboarding
Use Ansible for provisioning, but you own drift management
Pre-installed agent runtimes (Claude Code, Codex) reduce setup friction

Code snippet: Provisioning a VM with injected MCP server

# Create a profile with MCP server and credentials
machine0 profile create agent-profile \
  --mcp-server https://mcp.example.com \
  --env-var OPENAI_API_KEY=sk-... \
  --env-var TASK_QUEUE_URL=https://queue.example.com

# Provision a VM using the profile
machine0 new agent-worker \
  --size xl \
  --image nixos \
  --profile agent-profile \
  --region us-east

# Agent can now run tasks with MCP tools available
machine0 ssh agent-worker -- claude-code run task.md

Observability Gaps

machine0 doesn’t document built-in logging, metrics, or tracing. You get CLI output and SSH access. For production agent workloads, you’ll need to instrument:

Structured logging: Ship logs to Loki, Elasticsearch, or CloudWatch
Metrics: Export VM-level metrics (CPU, memory, disk) and agent-specific metrics (task duration, tool call latency)
Distributed tracing: If agents chain tasks across multiple VMs, use OpenTelemetry to track request flow

Without these, debugging a failed 6-hour agent task becomes archaeology.

Technical Verdict

Use machine0 when:

Your agent tasks run for minutes to hours and benefit from persistent state
You need dedicated GPU compute for inference or fine-tuning without cold starts
You want agents to self-manage infrastructure via CLI or MCP
You’re comfortable building your own retry logic, monitoring, and security controls

Avoid it when:

Your tasks are sub-minute and serverless cold starts are acceptable
You need automatic horizontal scaling based on queue depth
You require built-in observability, circuit breakers, or dead-letter queues
You can’t afford the operational overhead of agent-driven infrastructure management

The platform fills a gap between serverless (too ephemeral) and Kubernetes (too much orchestration overhead) for long-horizon agent workloads. The economics work if your tasks have predictable runtimes and you can amortize the per-minute cost. The security model assumes you’ll build guardrails around agent CLI access, because the platform doesn’t enforce them by default.

Agentic AI, minus the noise.