YC F26 Newcomer Agent37: Low-Cost Agent Sandboxes That Get Agents Running

In the YC F26 batch, a project called Agent37 quietly made its debut. It targets a pain point that is rapidly expanding but has yet to be adequately solved: how to let AI Agents run in a safe, isolated, and cost-controlled environment.

Why Agent Sandboxes Suddenly Became a Must-Have

Over the past year, AI Agents have moved from demos to production. Whether it's automatically writing code, operating a browser, or calling multiple tools to complete complex tasks, an Agent needs an "execution space." But running an Agent directly on a local machine or a bare cloud server carries obvious risks: the Agent might accidentally delete files, leak keys, make unexpected network requests, or even fall into an infinite loop and burn through a huge amount of compute.

Sandboxes exist precisely to solve these problems. They provide an isolated runtime environment, restrict resource access, and cleanly destroy themselves after a task ends. The problem is that existing solutions are either too heavy—full virtual machines start slowly and have high overhead; or too expensive—hourly-billed managed sandboxes quickly spiral out of control in cost under high-frequency Agent calls. Agent37's entry point is to provide sandboxes designed specifically for Agents at a lower cost.

A sandbox is essentially a restricted execution environment that, through operating-system-level isolation mechanisms, separates a process's file system, network, and process space from the host machine or other sandboxes. Common implementations include containers based on Linux namespaces and cgroups (such as Docker), microVMs based on virtualization technologies like KVM (such as Firecracker and gVisor), and language-level WASM runtimes. Isolation strength is usually positively correlated with startup overhead: containers share the host kernel, start quickly, but offer weaker isolation; microVMs have independent kernels, offer strong isolation, but cold starts typically take hundreds of milliseconds. For Agent scenarios, sandboxes additionally need capabilities such as file system snapshots, network egress control, and session lifecycle management, which makes them different from traditional container orchestration aimed at long-running services.

What Agent37 Does

Agent37 appeared in the Launch HN section of Hacker News with a very clear positioning: low-cost Agent sandboxes. From the project description, it is not a general-purpose cloud computing platform, but rather optimized around the runtime characteristics of Agents—fast startup, on-demand isolation, and controllable cost.

This approach responds to a structural contradiction in current Agent infrastructure. Traditional cloud sandboxes (such as containers or microVMs) often assume users are long-running services, whereas Agent workloads are short-lived, bursty, and high-frequency. An Agent task may last only a few seconds to a few minutes, yet requires a complete isolation boundary. If you沿用 billing and scheduling models designed for long-running services, costs will be severely amplified. Agent37 chose to build its product in this gap, attempting to make "spinning up a sandbox for every Agent task" economically viable.

Cold start refers to the time required for a sandbox to go from being requested to being able to execute a task. For Agents, this is especially critical because many tasks themselves only run for a few seconds. If startup takes several seconds or even longer, overall efficiency is severely diluted. Common industry strategies to reduce cold start latency include warm pools (pre-created standby sandboxes that are quickly allocated), snapshot restore (instantly restoring runtime state from a memory or file system snapshot), and lightweight isolation layers (skipping a full kernel boot). Cold start optimization often involves trade-offs with isolation strength: the more aggressive the reuse and snapshot strategies, the more carefully you need to evaluate risks of cross-tenant information leakage and escape.

Possible Trade-offs Behind Low Cost

Any promise of "low cost" needs scrutiny of how it is achieved. The cost of a sandbox mainly comes from compute resources, storage, and network isolation. Lowering cost usually means more aggressive resource sharing, shorter cold-start optimization, or a simpler isolation model.

For developers, several key questions need attention: Is the isolation strength sufficient to withstand malicious or runaway Agent behavior? Is startup latency low enough for high-frequency calls? And when an Agent needs to access external tools or data, are the sandbox's network policies flexible and controllable? These details determine whether Agent37 is genuinely usable infrastructure or just a proof of concept. Currently, public information is limited, and actual performance remains to be verified by more user feedback.

The cost amplification effect brought by short-lived, high-frequency workloads stems from a mismatch between traditional billing models and actual resource usage. Hourly-billed cloud sandboxes assume instances live for a long time, whereas Agent tasks may last only a few seconds, resulting in a large amount of billed time sitting idle; even with per-second billing, the scheduling and image-pulling overhead from frequent creation and destruction accumulates. Solutions include billing by actual CPU/memory consumption, supporting sub-second lifecycles, and doing task merging and resource oversubscription at the scheduling layer. For developers, understanding billing granularity and resource metering methods is more useful for judging real cost than simply looking at unit price.

Impact on the Agent Ecosystem

If low-cost sandboxes like Agent37 prove viable, they could change how Agent applications are deployed. Developers will be more willing to let Agents perform high-risk exploratory tasks, because the cost of failure is lowered by both the sandbox and the low cost. Multi-Agent collaboration scenarios will also benefit—each sub-Agent has an independent sandbox without interfering with others, and the orchestration layer can schedule in parallel more boldly.

This aligns with the broader recent trend in Agent infrastructure: shifting from "letting Agents run" to "letting Agents run safely, cheaply, and at scale." YC's bet on Agent37 in this direction shows that market demand for Agent runtimes is moving from the edge to the core.

Signals Worth Watching

Whether Agent37 can establish itself depends on whether it can find a balance among cost, isolation, and ease of use. For developers, what's worth watching is its actual pricing, startup speed, and whether it offers out-of-the-box integrations with mainstream Agent frameworks. If a sandbox product has high integration cost, no matter how cheap it is, it will be hard to adopt widely.

Competition in Agent infrastructure has only just begun. Low-cost sandboxes are one piece of the puzzle, and Agent37 has chosen to enter from this piece. At least in terms of direction, it is clear.