Agent37 runs AI agent sandboxes for an average of $0.37 per month per customer. That is roughly 10% of what most sandbox providers charge. The YC F26 company launched on Hacker News with a claim that their infrastructure cost for free-tier users averages $0.05 to $0.10 per month. The pricing is not a loss leader. It reflects architectural choices that expose the true cost structure of agent execution environments.
The plumbing matters because agent workloads have predictable resource patterns. They spike CPU during initialization and tool calls, then idle. They need RAM for browser automation and computer-use tasks, then release it. Most sandbox providers provision for peak load and bill accordingly. Agent37 provisions for average load and shares resources across tenants.
Resource Allocation Strategy
Agent37's cost reduction comes from three infrastructure decisions:
Workload-aware CPU and RAM management
Agent harnesses consume CPU in bursts during initialization, tool execution, and LLM calls. Between tasks, they idle. RAM usage spikes during browser automation or computer-use tasks, then drops. Agent37 does not reserve full VM resources for each sandbox. Instead, they share host memory across sandboxes and allocate CPU dynamically.
Bare-metal hosts instead of hyperscaler VMs
The team skips AWS, GCP, and Azure in favor of Hetzner and OVH. Hyperscaler VMs carry 80-90% margins. Bare-metal providers charge closer to hardware cost. This single decision accounts for the largest cost reduction.
gVisor for isolation and fast boot
gVisor provides container-level isolation with kernel syscall interception. It allows memory sharing across sandboxes without reserving a full VM per tenant. Boot times are fast enough to spin up sandboxes on demand rather than keeping them warm.
Isolation Primitives and Trade-offs
gVisor sits between full VMs and raw containers. It intercepts syscalls in userspace, providing a security boundary without the overhead of hardware virtualization. For agent sandboxes, this means:
- Faster cold starts than VMs (sub-second vs. seconds)
- Lower memory overhead (shared kernel, no guest OS)
- Weaker isolation than hardware virtualization (syscall interception vs. CPU ring separation)
The trade-off is acceptable for agent workloads. Most agents do not require hardware-level isolation. They need process isolation, filesystem boundaries, and network controls. gVisor provides those without the cost of nested virtualization.
| Isolation Method | Cold Start | Memory Overhead | Security Boundary | Cost per Sandbox |
|---|---|---|---|---|
| Full VM | 5-15s | 512MB-1GB | Hardware ring separation | $5-20/month |
| gVisor | <1s | 50-100MB | Syscall interception | $0.37/month |
| Raw containers | <1s | 10-50MB | Kernel namespaces | $0.10/month (shared risk) |
Metering and Billing Model
Agent37 does not bill for reserved capacity. They bill for actual usage. This requires accurate metering of CPU time, memory allocation, and network egress. The challenge is granular accounting without adding overhead.
Most sandbox providers use time-based billing (per hour or per minute of uptime). Agent37 likely uses resource-based billing (CPU-seconds, memory-GB-seconds). This aligns cost with actual consumption and allows them to oversubscribe hosts safely.
The $0.37 average suggests most customers run lightweight agents with intermittent activity. A typical workload might be:
- 10 minutes of active CPU time per day
- 200MB average memory footprint
- Minimal network egress
At bare-metal pricing, this costs pennies per month. The billing system must handle micro-transactions and aggregate usage across thousands of sandboxes.
Noisy Neighbor Mitigation
Shared infrastructure at this price point creates noisy neighbor risk. One agent running a CPU-intensive task can starve others. Agent37 must enforce resource limits without killing legitimate workloads.
Likely mitigations:
- CPU quotas per sandbox (cgroups v2)
- Memory limits with OOM kill protection
- Network rate limiting per tenant
- I/O throttling for disk-heavy agents
The gVisor layer helps here. It provides per-sandbox resource accounting and can enforce limits at the syscall level. If an agent tries to fork-bomb or allocate excessive memory, gVisor can block it before it affects other tenants.
Deployment Shape
Agent37's architecture likely looks like this:
┌─────────────────────────────────────────┐
│ Control Plane (API, billing, metrics) │
└─────────────────┬───────────────────────┘
│
┌─────────┴─────────┐
│ │
┌───────▼────────┐ ┌───────▼────────┐
│ Bare-metal │ │ Bare-metal │
│ Host (OVH) │ │ Host (Hetzner)│
│ │ │ │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ gVisor │ │ │ │ gVisor │ │
│ │ Sandbox 1 │ │ │ │ Sandbox N │ │
│ └────────────┘ │ │ └────────────┘ │
│ ┌────────────┐ │ │ ┌────────────┐ │
│ │ gVisor │ │ │ │ gVisor │ │
│ │ Sandbox 2 │ │ │ │ Sandbox N+1│ │
│ └────────────┘ │ │ └────────────┘ │
└────────────────┘ └────────────────┘
The control plane handles API requests, sandbox provisioning, and billing. It schedules sandboxes onto bare-metal hosts based on available capacity. Each host runs dozens or hundreds of gVisor sandboxes, sharing CPU and memory dynamically.
Observability and Failure Modes
At $0.37 per month, observability must be cheap. Agent37 cannot afford to run a full Prometheus stack per sandbox. They likely aggregate metrics at the host level and expose per-sandbox stats on demand.
Key metrics:
- CPU utilization per sandbox (cgroups)
- Memory usage and OOM events
- Network egress (billing)
- Syscall latency (gVisor overhead)
Failure modes to watch:
Host oversubscription
If too many sandboxes become active simultaneously, the host runs out of CPU or memory. Mitigation: admission control based on real-time host metrics.
gVisor syscall overhead
Some workloads (heavy file I/O, frequent syscalls) pay a 10-20% performance penalty in gVisor. Mitigation: profile agent workloads and move heavy I/O tasks to native containers.
Billing accuracy
Micro-transactions require precise metering. If usage tracking drifts, customers get overcharged or the provider loses money. Mitigation: periodic reconciliation against host-level metrics.
Cold start latency
If sandboxes are spun down aggressively to save cost, cold starts add latency to agent execution. Mitigation: keep recently active sandboxes warm for a few minutes.
What This Pricing Model Reveals
Agent37's economics expose the markup in traditional sandbox providers. A $5/month sandbox from a hyperscaler costs the provider $0.50 in infrastructure. The rest is margin, support, and sales overhead.
For agent workloads, this markup is unnecessary. Agents do not need 99.99% uptime. They do not need dedicated VMs. They do not need enterprise support. They need cheap, isolated execution environments that spin up fast and bill for actual usage.
The $0.37 price point is sustainable because:
- Bare-metal hosts cost 10x less than hyperscaler VMs
- gVisor allows safe oversubscription without full VM overhead
- Agent workloads have low average utilization (high idle time)
- Billing aligns with actual resource consumption
Technical Verdict
Use Agent37's approach when:
- You run agent workloads with predictable burst patterns
- Cost per sandbox matters more than single-tenant isolation
- You can tolerate gVisor's syscall overhead (10-20% for I/O-heavy tasks)
- Your agents do not require hardware-level security boundaries
- You need to support a free tier without burning cash
Avoid this approach when:
- You need hardware virtualization for compliance or security
- Your agents run CPU-intensive tasks continuously (no idle time to exploit)
- You require sub-millisecond syscall latency
- You need guaranteed resources (no oversubscription)
- You are running on a hyperscaler and cannot move to bare-metal
The real lesson is not the specific price point. It is the cost structure. Agent workloads are bursty, low-utilization, and tolerant of shared infrastructure. Provisioning them like traditional VMs wastes 90% of the budget. Agent37 proves you can run agent sandboxes for pennies if you match the infrastructure to the workload.
Top comments (0)