An agent that returns tomorrow needs more than a process that ran successfully today. It needs its files, a place to execute tools and a dependable way for the application to reach it. Multiply that arrangement across customers and the infrastructure becomes a product decision of its own.
Agent 37 offers persistent sandboxes behind an API, with preconfigured agent harnesses and a usage-based compute model. Its current cloud page describes creating an environment for each customer, returning to it across sessions and retaining its files until the environment is deleted. That makes the unit of deployment a continuing workspace rather than one disposable function call. [1]
The founder and the infrastructure question
Founder Vishnu Krishnaprasad previously worked as a senior software engineer at Amazon and an engineering manager at Quantcast, according to the public YC profile. Agent 37 is in YC's Fall 2026 batch. [2]
In the public Hacker News launch, Krishnaprasad describes optimizing infrastructure around the CPU and memory patterns of agent workloads. An agent can spend much of a session waiting for models or tools, with shorter bursts of heavier execution. The economic question is how well the provider's resource model fits that workload. [3]
Persistence and billing are separate decisions
The current cloud page lists compute charges while a sandbox is running and disk charges until it is deleted. Model tokens, search and integrations can be separate charges from the same balance, while customers may bring their own model keys. A cheap stopped workspace and a low-cost continuously active agent are therefore different cases. [1]
The pricing calculator makes one important assumption explicit: its default $0.37 example uses 57 aggregate active hours and assumes the sandbox is deleted afterward. Retaining a 4 GB disk for a full month costs $0.36 for storage alone. Compute and retained storage must therefore be modeled separately, alongside model and tool usage. The comparison also excludes some fees and most competitors’ storage costs; a percentage saving is meaningful only for a matched workload and bill. [4]
What the Hacker News discussion adds
The founder's launch explains the use of gVisor, resource sharing and direct hosting suppliers. It also states that the standard sandbox does not support some workloads, including Docker-in-Docker and Android emulation, and describes a separate full-VM option. We would verify current availability for a proposed deployment rather than infer that every environment supports every workflow. [3]
The discussion also asks whether providers are being compared on equivalent resources and what an agent is permitted to do inside its environment. A buyer can use those questions to separate the infrastructure bill from the application permissions and operating controls it still needs to manage. [3]
A persistent assistant for each customer
The official cloud page supports a scenario in which an application creates one sandbox per customer and messages it repeatedly. Files and configuration persist between interactions. That can be useful when an assistant works with a continuing set of documents or tools and a fresh environment would require repeated setup. [1]
The operating question is lifecycle management. We would test customer deletion, workspace recovery and what happens when a balance is exhausted. The application still needs to assign identity and access correctly, and to distinguish a paused agent from one that has completed its work. Persistence is valuable only when its ownership is unambiguous.
Coding sessions and a white-label service
The current website lists several supported harnesses and custom templates, as well as embedded terminals, desktops and file access. One documented scenario is moving coding sessions into managed environments so developers can return to the same files and installed tools. A second is providing hosted agents under an application's own brand. [1]
These scenarios put different demands on the service. A coding session may need specific system capabilities; a customer-facing agent needs predictable provisioning, recovery and spending controls. We would ask for a demonstration of each required path instead of assuming that a successful chat response validates the entire environment. Neither scenario, by itself, demonstrates that the application built on top will perform its business task correctly.
Where Agent 37 fits on SOTA2
| Product & task | Position | Comparison scope |
|---|---|---|
| Agent 37 Cloud APIExecute Code in SandboxesAgent | #4 | 12 companies · 14 candidates 10 ranked products |
What we would look for in a pilot
Start with a workload trace from the product you intend to run: bursty execution, browser work, idle periods and a longer session that crosses a stop/resume boundary. Measure startup, task completion, memory pressure and recovery. Compare total charges with your actual baseline, including storage and model/tool usage, rather than copying a headline percentage.
For the COO or engineering lead, require a clear account of customer separation, network access, backups and revocation. Have the team demonstrate what happens when an agent loses access to an integration or reaches its budget. A sandbox boundary and the permissions granted to the agent answer different questions; both matter to a service used by real customers.
For the CFO, model a representative customer month and a busier-than-expected month. Confirm which meters keep running when an environment sleeps, which capabilities require another environment type and how support is priced. The result should be a cost model the application can sustain as customers use more of the product.
The SOTA2 view
Agent 37 is relevant to teams that want persistent agent workspaces without building the hosting operation themselves. Its strongest evaluation angle is the connection between persistence, workload-specific infrastructure and the complete monthly bill. The public launch makes the tradeoffs more legible; a buyer should carry those tradeoffs into a test on its own agent, rather than treating low advertised compute cost as the whole decision.