Agent37 (YC F26) Launch: Low-Cost Agent Sandboxes on gVisor and Hetzner

Agent37, a Y Combinator F26 company, launched on Hacker News with a low-cost sandbox service for running AI agents, and the discussion quickly split between people impressed by the cost engineering and people arguing that sandboxing is already a commodity with no defensible moat. The launch post reached 160 points and drew 119 comments.

The core technical claim commenters reacted to is a cost structure built on two levers: running on Hetzner and OVH instead of hyperscalers like AWS, and using gVisor rather than full virtual machines so that sandbox memory can be overcommitted instead of reserved per-VM.

What Agent37 is

Agent37 sells sandboxes for running AI agents, positioned on price. Commenters referenced a stated cost of roughly $0.05 to $0.10 per free user, persistent files that stay with the agent across sessions, auto-sleep for idle sandboxes, and pre-built agent templates including hermes, pi, and opencode.

The service is not only templates. Commenters noted that a general Ubuntu or Android sandbox is priced noticeably higher than the template-based options — still below at least one named competitor, but not by much.

The cost argument: RAM, not CPU, is the binding constraint

Multiple commenters independently confirmed the launch's framing that agent workloads are bursty on CPU and expensive on RAM. A commenter running a daily job that clones and executes freshly launched open-source projects described the pattern precisely:

Your point about bursty CPU matches what I see: install and build spike for 20–60 seconds, then the process mostly idles while the harness reads output. RAM only matters the day a project pulls in a headless browser.

Another commenter made the same observation from self-hosting small stacks on a VPS: CPU sits idle while memory is what forces the next machine to be provisioned. That is the economic case for gVisor — sharing host memory without reserving a full VM's allocation lowers the cost floor for workloads that are mostly idle.

A commenter summarized the architecture as "skipping hyperscalers like AWS for Hetzner/OVH" being "a massive lever," with gVisor memory overcommit as the technically interesting part.

The central critique: sandboxes are commoditized

The most repeated objection in the thread is that a sandbox is close to a commodity and that competing on price as a new entrant is structurally dangerous.

Sandboxes look a bit commoditized. You cannot 10x on basically what's just a VM with a few agent-friendly features in 2026. Hence competing on purely price as a new startup is a bad idea imo. As you mentioned hyperscalers have insane margins, but if this turns out to be a real market, they will lower cost, even just eat the loss if they want and take you out of business.

A second commenter made the same argument with more specificity about who the real competitors are: well-funded platforms can sell sandbox features at a loss to pull customers into higher-margin, stickier products such as databases. The suggested escape route was to move closer to the actual work customers need agents to do, rather than selling the substrate.

I work in healthcare administration and we have built our own agent sandbox infrastructure on top of firecracker microvms that solve similar use cases as Agent37. We will never sell it. It's part of our competitive advantage for doing healthcare tasks.

That comment is the sharpest version of the threat: for some buyers, sandbox infrastructure is not a purchase, it is internal competitive advantage.

The counterpoint: isolation is not the risk that matters

The most substantive technical counterargument in the thread is that the security property everyone is price-comparing is not the property that causes real incidents.

gVisor vs a full VM is a real tradeoff. Most agent failures that actually hurt are not sandbox escapes. They are the agent acting as you with a coarse OAuth grant, or reading a secret that was sitting in the environment. A cheaper box does not fix that. You still need an egress allowlist the guest cannot rewrite, credentials that never enter the guest, and a hard call budget per task. I would pay more for that broker layer than for another 2x cheaper sandbox.

A separate commenter raised the same gap from the product side: connecting an agent to Google grants it access to everything, and a sandbox protects the host but not the user's tokens. The requested feature is scoped, short-lived credentials per task.

This is the strongest signal in the thread about where differentiation might actually exist — not in cheaper isolation, but in a credential and egress broker layer that the guest cannot subvert.

Isolation tradeoffs: gVisor is not a VM

Several commenters pushed back on comparing gVisor pricing directly against VM pricing, arguing it is not apples-to-apples because gVisor is less secure than a full VM. One commenter compressed the objection to a one-liner: "sandboxes > gvisor > not a sandbox ok."

A related operational question is what happens when gVisor cannot run a workload at all. The launch reportedly notes that Docker-in-Docker is unsupported; a commenter asked whether the API fails fast in that case or whether the job simply hangs.

Operational questions the launch raised

Commenters asked a consistent set of infrastructure questions that any buyer evaluating this class of service should ask:

Noisy neighbors. With gVisor sharing host memory, what happens when several browser-heavy sandboxes spike simultaneously on the same host — OOM-kill, throttling, or migration? Are there specific cgroup configurations or OOM-killer tuning settings involved?
Sandbox density. What is the rough number of sandboxes per host at $0.05–$0.10 per free user?
Cold starts. What is the exact wake latency when a sandbox resumes from auto-sleep? One commenter noted this number "decides a lot for anyone chaining many short runs."
Storage layer. How is persistent per-agent storage implemented at that price point — local NVMe with networked backups, or something like Ceph or block storage?
Filesystem isolation between concurrent instances. How is state separated without incurring heavy snapshot and restore I/O penalties?
Burst traffic. Do customers monopolizing resources cause other tenants to see 429 responses?
Orchestration. Is placement handled by Kubernetes or a custom scheduler, and how are resource allocation and lifecycle managed at this cost level?

What actually costs users time: network policy and environment hygiene

One of the most useful comments came from someone running untrusted code in sandboxes daily, who argued that CPU and RAM are not the real friction points:

First, network policy. I run untrusted code with an egress allowlist, and most launched projects assume open internet, so the useful knob is per-sandbox allowlist editing with a proxy for package registries, not more memory. Second, environment hygiene. The sandbox needs a clean env with no inherited secrets, and a persistent sandbox that does not pick up changed env vars or allowlist entries without a restart bit me more than once. Third, a wall-clock timebox per run, because a stuck npm install behind a proxy fails silently rather than loudly.

The concrete product questions that follow are whether an egress allowlist can be edited on a running sandbox, and whether unsupported workloads fail loudly.

Product surface and integration friction

Commenters raised several smaller but concrete issues:

Template pricing gap. The lowest prices appear to apply to predefined agent templates, while general Ubuntu and Android sandboxes cost meaningfully more.
Google connectors. A user who had been on the service for a few months said setup was easy but flagged that some Google integration connectors were "kind of privacy nightmare" — the request was to simplify Google's AI and service integration without handing over access to every Google service.
Payment options. A commenter in France noted the only payment option appeared to be credit card, and asked whether PayPal would be added, because their bank charges high fees for non-euro transactions.
Marketing copy. One commenter criticized the user success stories as obviously AI-written, quoting two passages that say the same thing in nearly identical structure.

Competitive landscape named in the thread

Commenters positioned Agent37 against several alternatives: boat.dev (described as the closest on pricing, with Agent37 slightly cheaper but offering less storage), Daytona (whose credits one commenter called close to useless until tier 3), Cloudflare's agents offering, and a community-maintained list of sandbox providers at engine.build/lab/agent-sandboxes. One commenter also asked how the service compares to running agents locally on a dedicated Linux box over a tailnet, noting that a locally hosted equivalent of these commercial products is an obvious open-source gap.

The forward-looking bet: agent runtimes will fragment

One commenter argued the market will not be a single category but a set of runtime tiers that an agent selects at execution time, ideally from one provider:

The agent doesn't need a full blown Linux environment all the time - often times all it needs is maybe some custom tool/script written in python/js. Having said that, providing a VM like QuickJS for running simple code could be enough (thus also cheaper).

The same commenter predicted CPU and RAM scarcity in datacenters within months, analogous to GPU scarcity, on the theory that agents will generate most internet traffic at roughly ten times current volume — and that running small scripts in an OS-free VM will move from a nice-to-have to essential.

Bottom line

Agent37's launch argument is that agent sandboxes are mostly idle on CPU and constrained on RAM, so gVisor memory overcommit plus non-hyperscaler hosting produces a materially lower price. The thread's counterargument is that this is a race to the bottom against better-funded platforms that can subsidize sandboxes, and that the durable value sits one layer up — in egress allowlists the guest cannot rewrite, credentials that never enter the guest, and hard per-task call budgets. The unanswered operational questions (noisy-neighbor behavior under memory pressure, cold-start latency, per-host density, and live allowlist editing) are the ones a prospective buyer should get answered before committing.