The Real Economics of Agent Sandboxes: How a YC Startup Sells gVisor Time at $0.37/Month

On October 12, 2026, a YC F26 startup called Agent37 posted a Launch HN with a number that made the thread hit 159 points and stay alive for two days: their customers spend an average of $0.37/month per sandbox — a persistent Linux computer running an agent harness like Hermes, OpenClaw, or Claude Code. For comparison, their own comparison table (checked October 1, 2026) lists Daytona and E2B at $9.44/mo (25×), Modal at $13.56 (37×), and a DIY Hetzner CX23 at $6.49 (18×) for the same shape at the same duty cycle — with the honest caveat that the $0.37 headline assumes you delete the sandbox after its awake hours, while the DIY rows run around the clock.

Two days after Agent37's launch — and five days after AWS shipped Strands Box, its open-source, policy-governed agent sandbox — you can see the same market forming from both ends. This guide takes Agent37's economics apart, because the techniques are not proprietary magic: they are a specific, reproducible stack (gVisor + non-hyperscaler hosts + oversubscription + checkpointed idle), and every one of them has a production failure mode you should price in before you copy it or buy it.

What we verified for this piece: we downloaded the real runsc binary (release-20261005.0, published October 8, 2026) and drove its flag surface; we read every one of the 118 comments in the launch thread, including the founder's own answers on density and OOM behavior; we pulled the full Agent37 docs (a 749 KB llms-full.txt that documents the entire Sandbox API contract); and we ran the cost math with Decimal, from their published unit rates and AWS's own AgentCore Runtime rates. Nothing below is marketing copy — the founder's own launch text is quoted where it makes claims, and we flag every place where the claims get fuzzy under load.

The Structural Shift: Agents Broke the VM Assumption

The entire cloud VM pricing model assumes the customer wants the machine. Agents broke that. An agent harness spends most of its life blocked on a model API — as one daily sandbox user observed in the thread, install and build spike the CPU for 20-60 seconds, "then the process mostly idles while the harness reads output." The founder (a former Amazon senior engineer who built their internal AI chatbot) put the pattern the same way in the launch text:

"When you look at agent harnesses, they have certain patterns in the way they consume CPU and RAM. They need CPU in bursts when they're initializing or performing certain tasks, but beyond that, they're often not peaking... This is a key insight in lowering cost."

A microVM provider that charges per provisioned vCPU/RAM-hour is billing you for an idle pattern. A provider that bills metered minutes while awake, checkpoints the machine when it goes quiet, and oversubscribes host memory across tenants is billing you for the actual pattern. That is the whole arbitrage. It has three legs, and each one is a technology choice you can make yourself:

1. gVisor instead of microVMs for the default tier — an application kernel in userspace that lets sandboxes share host memory without each reserving a full VM's worth, and boots fast because there is no guest kernel to boot.
2. Non-hyperscaler hosts — the founder: "I worked at Amazon before and they have 80-90% margins on VMs. So it was an obvious choice once I looked at the prices to go one layer down to vendors like Hetzner and OVH. This alone was probably one of the biggest cost levers."
3. RAM-shaped host purchases — "RAM is typically the bottleneck when it comes to cost and not the CPU. This is specifically true for agent harness workloads, so when buying servers, we optimize for packing more RAM into a given host."

The fourth leg is the one that makes the business model survivable: idle checkpointing. Their auto-sleep contract is publicly documented — after 900 seconds (default) of no data flow, the platform checkpoints the sandbox and releases CPU and RAM; billing drops to disk-only. That is the mechanism that turns an always-on $4.76/month shape into a $0.37/month shape at 7% duty cycle.

Architectural Blueprint

Here is the stack implied by the launch text, the docs, and the founder's comment replies, next to what a microVM provider runs:

MICROVM PROVIDER (per-VM reservation)   AGENT37-STYLE HOST (gVisor oversubscription)

  Host 64 GB RAM                          Host 256 GB RAM (RAM-optimized purchase)

  +----------------+  +----------------+
  | microVM        |  | microVM        |
  | 2 vCPU / 4 GB  |  | 2 vCPU / 4 GB  |
  | RAM RESERVED   |  | RAM RESERVED   |
  | guest kernel   |  | guest kernel   |
  | guest RAM      |  | guest RAM      |
  +----------------+  +----------------+
                                          +------------------------------------------------------+
                                          | runsc sandbox    runsc sandbox    runsc sandbox x N  |
                                          | Sentry = userspace kernel; memory is host-mapped     |
                                          | each sandbox = an ordinary host process group        |
                                          | bursty CPU served from host-wide spare cycles        |
                                          | RAM = shared host pool + per-sandbox cgroup cap      |
                                          +------------------------------------------------------+

 16 VMs max; RAM idle inside a guest      gVisor: no per-VM RAM reservation; idle RSS is
 is wasted. Every VM pays its own         reclaimable; N is limited by honest resident set.
 kernel boot + page tables.               Full-VM tier (Cloud Hypervisor) for DinD/Android.

 Scheduler: VM placement                  Custom scheduler: bin-pack by resident RSS,
 Billing: provisioned shape,              live-migrate sandboxes under host memory pressure.
          always-on                       Billing: metered awake-minutes + checkpointed sleep
                                          at disk rate ($0.00012 per GB-hour).

Two properties of gVisor carry the economics, and both are worth understanding precisely. First, a gVisor sandbox is a normal host process group, not a VM: the Sentry (an application kernel written in Go) implements the Linux syscall interface in userspace, and the guest's memory is host memory managed by the host kernel — there is no per-VM balloon of reserved RAM. Second, gVisor ships checkpoint/restore as a first-class operation: the sandbox state (kernel + memory + open files) is written to a statefile, the processes stop, and restore resumes execution — with flags to skip committed zero pages, use O_DIRECT, and restore memory in the background while the app starts running.

The Agent37 API surface sits on top of that:

  customer backend                Agent37 control plane                 host
  ---------------                ----------------------                 ----
  POST /v1/instances  ---------->  custom scheduler  -----place---->  runsc create (template image)
    {template, resources}           (placement, live                      | sandbox boots as process
                                   migration under                       v
                                   memory pressure)            idle 900s, no traffic
  GET  /v1/instances/{id}  <----  status: running|sleeping|stopped      checkpoint --image-path=...
  POST .../instances/{id}/exec    run any sh -c command        <----  statefile to disk; CPU+RAM freed
  any request to sandbox URL  ------------------------------wake---->  restore: 5-15s warm
  POST .../instances/{id}/start  ------------------------------------>  or ~2min cold rebuild
  DELETE /v1/instances/{id}     billing settles, disk deleted

The important operational detail hiding in that diagram: a warm restore is 5-15 seconds, but a restore that cannot resume (host changed, or the sandbox was evicted to cold storage) rebuilds the machine fresh in about two minutes — in-memory state is gone, only disk survives. Their docs say it in one sentence worth pinning to a wall: "treat anything that must outlive a sleep as a file."

The Cost Math, Verified

Agent37's published unit rates are $0.80 per vCPU, $0.70 per GB RAM, and $0.09 per GB disk per 730-hour month, metered by the minute. We re-derived every number below from those rates with exact Decimal arithmetic — no mental math. The one variable that changes everything is what happens to the disk when the sandbox is idle, so each row states its retention assumption:

Three observations the table doesn't say out loud. First, the $0.37 headline is a transient number — it assumes you delete the sandbox after its awake hours; an agent whose disk persists across the month (the realistic case for a personal assistant) pays $0.69, and a true always-on agent pays $4.76. Second, the comparison against AgentCore Runtime is not like-for-like: AgentCore bills $0.0895/vCPU-hr with metered active CPU in an AWS region with AWS's compliance surface, so you are paying for a regulated environment, IAM integration, and no ops. Third — and this is the line most providers don't publish — the founder's own comment reply admits where the free tier's cost actually comes from: "the 5-10 cents price is not achieved because of sandbox density, it's because we limit the number of awake hours a free user gets per week. Right now it's about 10 hrs/wk." The oversubscription is real, but the advertised economics are duty-cycle economics first.

Complete Runnable Setup: gVisor Node Pool on Cheap Hosts

Everything above is reproducible with vanilla Kubernetes. Below is a complete, production-shaped configuration for the same pattern: gVisor sandboxed pods on RAM-optimized nodes, with the flags a sandbox host actually needs. We verified every flag against the runsc binary we downloaded (release-20261005.0) — the --help surface, the flags dump, and the platforms list are from the real binary, not from a blog post.

Step 1 — install gVisor on each node (Ubuntu/Debian, x86_64):

ARCH="x86_64"
RELEASE="release-20261005.0"
curl -sL -o gvisor.tar.bz2 \
  "https://github.com/google/gvisor/releases/download/${RELEASE}/gvisor-${ARCH}.tar.bz2"
tar -xjf gvisor.tar.bz2
sudo mv runsc /usr/local/bin/runsc
sudo mv containerd-shim-runsc-v1 /usr/local/bin/
sudo mv gvisor-bin /usr/local/bin/
sudo chmod a+rx /usr/local/bin/runsc /usr/local/bin/containerd-shim-runsc-v1
sudo chmod a+rx /usr/local/bin/gvisor-bin /usr/local/bin/gvisor-bin/*

# Verify what you installed (our actual output, 2026-10-14):
#   $ runsc --version
#   runsc version release-20261005.0
#   spec: 1.2.1
#   $ runsc help platforms
#   kvm
#   ptrace
#   slimvm
#   systrap

Step 2 — register runsc with containerd. The pattern gVisor's own containerd configuration guide prescribes is two files: a runsc.toml that carries the runsc flags, and a config.toml runtime entry pointing at it via ConfigPath. On bare-metal hosts use platform = "kvm" for the best syscall performance; inside a cloud VM (or on hosts without nested virt) use systrap, which the platform guide recommends and the binary confirms as the default:

# File 1: /etc/containerd/runsc.toml — flags passed to runsc.
sudo tee /etc/containerd/runsc.toml >/dev/null <<'EOF'
[runsc_config]
  # Bare metal: kvm. Inside a cloud VM: systrap (the binary's default).
  platform = "systrap"
  # gVisor's own netstack, isolated from the host network.
  network = "sandbox"
  # Wrap the root mount in a RAM-backed overlay: fast writes, no disk wear
  # for churn-y build output. (runsc flags: -overlay2=root:memory)
  overlay2 = "root:memory"
  # Best-effort fix of non-optimal host kernel settings.
  host-settings = "adjust"
  # Log sentry hangs instead of panicking the node (the binary's default).
  watchdog-action = "log"
EOF

# File 2: /etc/containerd/config.toml — register the runtime handler.
sudo tee /etc/containerd/config.toml >/dev/null <<'EOF'
version = 2

[plugins."io.containerd.runtime.v1.linux"]
  shim_debug = true

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  runtime_type = "io.containerd.runc.v2"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc.options]
  TypeUrl = "io.containerd.runsc.v1.options"
  ConfigPath = "/etc/containerd/runsc.toml"
EOF

sudo systemctl restart containerd

Step 3 — the RuntimeClass and a sandboxed agent pod. GKE users can skip all of the above and use GKE Sandbox node pools, which pre-integrate gVisor:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: coding-agent
  labels:
    app: coding-agent
spec:
  runtimeClassName: gvisor
  automountServiceAccountToken: false
  containers:
  - name: harness
    image: my-registry/agent-harness:1.4.0
    resources:
      requests: {cpu: "500m", memory: "1Gi"}
      limits:
        cpu: "2"
        memory: "4Gi"
        # gVisor + cgroup memory limit: the sandbox OOM-fails INSIDE the sandbox,
        # not the host — this is the noisy-neighbor control that matters.
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: false
      capabilities:
        drop: ["ALL"]
    env:
    - name: MODEL_API_KEY
      valueFrom:
        secretKeyRef: {name: agent-model-key, key: key}

Step 4 — the piece providers sell as a product: idle checkpointing. If you are running this yourself, the equivalent is a CronJob or controller that checkpoints sandboxes with no traffic (runsc checkpoint stops the container by default — that is exactly what you want for idle eviction) and restores on demand. The flags below are from the real binary's checkpoint/restore subcommand help:

# Idle eviction: freeze a quiet sandbox to disk, free its RAM.
runsc checkpoint \
  --image-path=/var/lib/sandbox-state/agent-042 \
  --compression=none \
  --exclude-committed-zero-pages \
  --direct \
  agent-042
#   --compression=none           fastest; enables the optimizations below
#   --exclude-committed-zero-pages  skip zero-filled pages (big for LLM/browser RAM)
#   --direct                     O_DIRECT on the pages file, bypasses page cache

# Wake on demand: restore execution where it left off.
runsc create agent-042
runsc restore \
  --image-path=/var/lib/sandbox-state/agent-042 \
  --background \
  agent-042
#   --background: kernel state loads first; app memory restores asynchronously;
#   a page fault on a not-yet-restored page prioritizes loading it immediately.

Day-2 Warnings: What Breaks, in What Order

This is the section the pricing page does not have. Every technique above has a documented failure mode, and the founder's own answers in the thread give us two of them straight from production:

1. Memory pressure restarts your sandbox. Asked what happens when several browser-heavy sandboxes spike at once, the answer was: "If a host reaches critical memory, then it will start restarting memory heavy sandboxes, but it's [on] us to relieve pressure on such hosts by moving the new ones and sleep awake ones off of it." That is an honest answer, and it is also the single most important line in the thread for anyone running real workloads: under host memory pressure, a memory-heavy sandbox is a restart candidate. In-memory state is the casualty. If your agent holds conversation state in RAM across a spike window, you lose it. Mitigation: treat every sandbox as stateless-plus-disk, exactly as their own docs instruct — anything that must outlive a sleep (or a pressure restart) goes to a file.

2. gVisor is not a VM, and the security boundary is different. A commenter in the thread put the industry-standard concern perfectly: "gVisor is... less secure than VMs; but the front page price-compares against VMs, so not apples-to-apples." gVisor's own production guide is explicit that it protects against most Linux kernel CVEs and container escapes by interposing a userspace kernel — a strong boundary, but a different threat model from hardware virtualization: the host kernel is still shared, and side-channel and resource-exhaustion classes remain host-level concerns. The founder acknowledged the capability gap: no Docker-in-Docker, no Android emulators, limited networking in the default tier (which is why Agent37 also sells a full-VM tier on Cloud Hypervisor at 2.5× the default compute rate — the docs confirm the default gVisor type "cannot run a Docker daemon").

3. The 80-90% margin claim is the founder's experience, not a verifiable industry figure. Treat it as directional: hyperscaler gross margins on raw VMs are famously high, and the price gap between a Hetzner box and an equivalent EC2 instance is plain to anyone who has priced both. But the moment your workload needs a compliance stamp, an AWS region, or a managed Postgres next door, the price comparison collapses in the other direction. The right question is never "who is cheapest per vCPU" — it is "what duty cycle and what threat model does my agent actually have."

4. Cold starts are the hidden tax of checkpoint-everything. Their own docs split this honestly: warm restore is 5-15 seconds; a cold rebuild (statefile unusable, host changed, long-idle eviction to cold storage) is ~2 minutes with in-memory state gone. If your product chains many short agent runs, the wake path dominates your latency budget, and a "cheapest tier" default is the wrong tier for it. The founder's own tiering concedes this — performance tiers with dedicated cores exist at 4× the rate because shared-host bursty CPU is real.

5. The broker layer is the moat, not the box. The most forward-looking comment in the thread came from a healthcare engineer running the same stack on Firecracker: agents fail in production not by escaping sandboxes but "by acting as you with a coarse OAuth grant, or reading a secret that was sitting in the environment." That is exactly the gap Strands Box (AWS, Apache-2.0, launched October 7) targets with default-deny Dogwood policies on shell/file/network/MCP actions and credentials injected at the gateway — never inside the guest. A cheaper box does not fix a credential model that hands the agent your OAuth grant; the policy layer does. Agent37's managed-services design points the same direction (per-instance budget caps in integer micros, a revocable starter token distinct from the workspace key, spend metered at the gateway) — but their default sandbox is a general-purpose Linux box whose egress and environment hygiene are the customer's job, and that is precisely the layer Strands Box exists to standardize.

6. Free tier economics are duty-cycle economics. $0.05-0.10/user/month is achievable only with a hard awake-hours cap (10 h/week at launch) plus oversubscription plus checkpoint-eviction. Copy the mechanism, not the headline number: cap awake hours, checkpoint aggressively, monitor honest resident set, and the same math works at any scale.

Who Should Skip This Architecture

Straight talk, per our review standard:

• Skip gVisor sandboxes if your workload is I/O- or network-heavy. gVisor's own performance guide says it plainly: structural costs (extra layers per syscall, the Go Sentry) land hardest on I/O- and network-bound workloads; CPU-bound code barely notices. A proxy, a database, or a high-throughput scraper belongs on runc or a real VM.
• Skip oversubscription if you have hard SLAs on p99. Every oversubscribed host is a promise made with someone else's bursts. If your agent product has a latency SLO, you need dedicated cores (Agent37 sells exactly this at 4×) or your own hosts.
• Skip the cheap-host arbitrage if you need enterprise compliance. Hetzner and OVH are excellent at what they do; SOC 2 reports, HIPAA, or region-pinned data residency are not part of the arbitrage. Your auditors will end that experiment in one meeting.
• Skip hosted agent sandboxes entirely if you have one agent and a spare machine. The entire stack above runs on a single Linux box with runsc installed. The providers are selling operations, not software — and the open-source layer (gVisor, Cloud Hypervisor, Strands Box for policy) is all Apache-2.0-adjacent and free.

What to Monitor Once It Runs

If you run this pattern yourself, these are the canaries, in the order they die:

And one hands-on footnote from preparing this guide: we tried to boot the real runsc sandbox on this research host and it could not — creating container: cannot set up cgroup for root: configuring cgroup: open /sys/fs/cgroup/cgroup.subtree_control: permission denied, with the rootless path equally blocked (fork/exec /proc/self/exe: permission denied). That is the host's AppArmor restriction on unprivileged user namespaces (Ubuntu 24.04, kernel.apparmor_restrict_unprivileged_userns=1), not a gVisor defect — and it is worth knowing because it is exactly the kind of host-level policy surprise that greets anyone who tries to run sandbox workloads on a locked-down corporate Linux image. Flag surface, subcommands, and platform list above are all from the real binary; container boot was not exercisable on this host.

The Takeaway

The $0.37 sandbox is not a trick — it is a coherent stack: gVisor for shared host memory and fast boot, RAM-first bin-packing on non-hyperscaler hosts, metered awake-minutes with checkpointed sleep, and a duty-cycle cap where the product can absorb it. Every piece is open source, every piece is reproducible on a single box, and every piece has a documented failure mode: pressure restarts, cold rebuilds, an I/O tax, and a security boundary that is different from a VM rather than uniformly weaker. The market is now racing on two fronts — Agent37 on price, AWS's Strands Box on policy — and the buyers who win are the ones who ask the boring questions: what is my duty cycle, what is my threat model, and what happens to my agent's state at 3 AM when the host is full.