You guys are operating in a very competitive space. This stuff is fun to build, so a lot of engineers will end up building it. Not to discourage you, but I suspect it will be difficult to capture much value selling this offering as its going to be race to the bottom against very well funded alternatives that can sell these features at a loss in order to get you to use their databases and other offerings that are higher margin and stickier.
As you guys learn more about how to take this sort of technology to market, you may consider trying to get closer to the actual work that people actually need these agents to do. What can you do better because you have this technology? For example, 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.
Thank you !
And agreed, it's an extremely competitive space. In our YC batch alone there's probably 5+ companies doing something similar. Interestingly enough though atleast for now we're all rapidly growing, so that's promising.
But eventually I see us all moving in slightly different spaces as we specialize.
Great to hear you are growing! Take this as you might grains of salt.
The promise of really cheap AI sounds amazing and is amazing. People will happily accept and engage with "free stuff"; but, I presume you are not starting a business to give away free stuff. Unless you have some model that let's you capture value some other way. e.g. Meta just gave everyone a small computer for free with Muse. Or have some sustainable price advantage on the underlying compute e.g. you are nvidia and make it yourself at scale.
I think you deserve to be compensated for your work! It's hard to make a sustainable business when selling something that costs $5 a month to developers (just seeing your calculator). There aren't that many of us, and AWS/GCP/Azure/Cloudflare have our credit cards already. If it were me, I'd be trying to figure out how to charge more and sell the value of the work you are enabling your customers to accomplish, not the cost of the underlying electrons.
I've been looking at offloading local work from my MacBook Pro (M1 Pro / 32 GB) specifically because I've been working with a lot of Android apps and emulation is killing me on top of everything else that I'm running.
Got a bunch of Daytona credits which are close to useless given their restrictions until you hit tier 3.
You seem like you're actually slightly cheaper than https://boat.dev/ but with less storage? That's the closest to your pricing unless I'm mistaken. Any other insight as to differences between you two?
Also I'll add you to a list I've been maintaining of sandbox providers, congrats on the launch!
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. Without any hardware innovation, it's tough for me to see this working. If you are going with a customization angle, again, no moat and plenty of competitors
There's a talk from Travis Kalanick recently on a podcast about this. It talks about the advantages of a startup vs an incumbent. My read is if a startup competes on price, the incumbent has no choice but to first let them gain a bunch of market share. It's too expensive for the incumbents to compete on price because a no-name startup is doing it. So they'd have to let you get relevant enough for it to make sense to compete on that axis.
I view it as a wedge to gain market share and later compete on something else.
This isn't commoditized because an incumbent has the market share, it's commoditized because there are dozens of providers in a crowded market. So what is likely going to happen is there will be a race to the bottom in terms of price.
PS - This is why I loathe advice from prominent software co operators. It's not one size fits all. Uber's strategy is going to be very different than Tesla's strategy which is going to be very different from Amazon's strategy.
unless the startup has gobs of free money how can they do this against an incumbent? note: nobody has gobs of free money anymore, except the incumbents. Startups competing on price is typically not a winning strategy, unless they have some technical advantage that shifts the price curve; subsidizing a move on it doesn't work.
Carving out market share and aiming for an acquisition exit is a valid win condition.
It also serves the consumers in the long run as it eventually will force competition and price reductions; effectively busting up price leadership dynamics.
This is really impressive work on the infrastructure side.
Skipping hyperscalers like AWS for Hetzner/OVH is definitely a massive lever, but your choice of gVisor for memory overcommit is where this gets technically interesting. A few questions on the implementation:
• Memory & Density: Since gVisor allows you to share memory without reserving a full VM's allocation, how are you handling noisy neighbors if multiple sandboxes spike in RAM usage simultaneously? Are you using specific cgroups configurations or out-of-memory (OOM) killer tuning to prevent one sandbox from crashing the host?
• Storage Persistence: You mentioned that files stay with the agent across sessions. How are you handling the storage layer efficiently at $0.05–$0.10/user? Are you using localized NVMe storage with networked backups, or something like ceph/block storage?
• Cold Starts: When a sandbox wakes up from auto-sleep, what is the exact latency for the user?
Congrats on the launch and the pivot from a simple wrapper to a real infrastructure play!
The host isolation everyone is comparing on price is not the hard problem.
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.
The broker point is the part I keep coming back to as well. Short-lived credentials help, but an agent can do a lot in five minutes if the scope is still broad, so the interesting boundary is really per-action rather than per-session. A broker that can say this task may read mail but not send it, or may create a draft but not charge a card, feels much closer to how you would delegate to a person. The tradeoff is friction: once every unusual call needs approval, you lose a lot of the hands-off benefit that made the sandbox cheap to run in the first place. I would be curious where people are landing on audit logs here: is a clear record of what the broker allowed after the fact enough for most work, or do you want approval before anything irreversible?
This matches what I ended up doing with my own agent setups. The agent never gets a key that can move money out. I fund a separate wallet, the agent gets delegated spending that I can revoke, and withdrawing is just not something it is able to do. Same idea with an API key I use for automation at work: it can edit and reject drafts, but publishing comes back as a 403 and stays a human click. The thing I worried about was never the agent breaking out of a box. It was the agent doing something allowed but dumb with a grant that was too broad.
How do you see this fitting with AWS’s Strands Box from last week? Box isn’t hosted compute. It’s an open-source sandbox plus a policy engine that checks shell, Python, egress, and MCP calls, and swaps credential placeholders for real secrets at the gateway. That’s the broker layer ekorondy and talkarimli are asking about.
Two questions: Could a policy layer like Box run inside your gVisor sandboxes, or would it need your full-VM tier? And on price, have you compared against AgentCore Runtime? It bills CPU only while active, which targets the same bursty pattern you’re optimizing for.
> 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.
I am actively working on exactly this. Once its ready, will post here on HN.
Looks like you are running tools/browser in the same VM. How safe is this? Do you see contention for ports/resources? How does it compare to offerings from other sandboxing providers?
That's fair, capabilities wise we have to limit certain things on what gvisor based sandboxes can do in terms of things like networking, and other capabilities to compensate for this class if sandbox.
However over 80% of the use cases I'm seeing simply doesn't need much beyond that.
Are you using Kubernetes to orchestrate sandboxes, or have you built your own scheduler? I'm curious how you handle sandbox placement, resource allocation, and lifecycle management at this cost level.
Nice. But apparently the only option offered is paying via CC. In France my bank charges egregious fees for paying in anything other than Euros, while Paypal does the conversion for free. Will you offer Paypal at some point?
I run a daily job that clones and runs a freshly launched open-source project in a sandbox, so a few notes from the consumer side of this market.
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.
The things that actually cost me time were not CPU or RAM, though. 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.
Two questions: can a sandbox’s egress allowlist be changed while it is running, and when gVisor does not support a workload (you mention Docker-in-Docker), does the API fail fast or does the job just hang?
Congrats on the launch!. Looks awesome. One small gripe I have is that the user success stores seems obviously like claude has written them. I cancelled my claude sub for codex, partly because i cannot understand claude's style at all - not that there is anything is wrong with it, its effing incomprehensible.
Compare the two yourself and judge(latter is written in gpt-6 luna).
> One client is one API call. It comes back as an always-on Hermes agent that holds that client’s data, that client’s identity, and a hard ceiling on what it can spend. It answers on an OpenAI-compatible endpoint from the moment it boots, so integrating it was a base URL, the same as pointing at any model API.
> Boon provisions an agent for a client with one API call. Each agent has its own client data and identity, along with a spending limit. It exposes an OpenAI-compatible endpoint, so Boon can connect to it by configuring a base URL.
Short-lived tokens only limit how long a credential works, but better than nothing. i.e. They don't stop an unwanted action while it's still valid.
A practical pattern is an outside broker: the guest never sees the real credential and can't pick the destination, only a path from an allowlist.
Shameless plug for my project, I maintain one of these brokers: Plimsoll's broker sits outside the sandbox, injects the upstream credential itself, matches method + exact path (no query strings, no traversal, no encoding tricks), and enforces (some limitations that I am want to improve) a total call budget plus per-route caps. So a task can be granted "GET /items/* plus at most one job submission" even when the underlying key is coarser.
This is cool; pricing is certainly appealing. At the same time, there are a ton of sandboxing providers.
> When you look at agent harnesses, ... CPU/RAM utilization we could lower the cost.
How does it work today? Is the harness (assuming it means the agentic loop) located in a separate VM and each loop-run invokes a separate sandboxing VM?
That's right each harness runs in it's own sandbox. Really the harness itself is just a docker template with some pre-installed harness (say openclaw, hermes, claude code, opencode, pi, grok etc) that runs.
Think of it as open router for Agent harnesses. So in our default templates we also run this and expose the APIs. So that makes using any harness easy as they all speak a single OpenAI responses API schema.
Tangentially, I've been investigating the last few days on how to setup a separate Linux box as an agent "playground". I got a mac mini to use as my own personal driver and now my Linux box is free, so I want to have a local setup where I keep my personal machine a bit stricter while giving near free-reign for agents on the Linux machine.
It is like a locally-hosted version of these commercial projects. But I'm doing it ad-hoc. This seems like a space that should be filled by open source. What are the options that exist now? I have pro plans for both Codex and Claude Code and enough credits to run a couple instances of each. I want to control them from the mac mini over a tailnet. What options exists now?
I've been working on this open source project for a few months, but just put up a product website today, actually: https://yaac.dev/
You can run the agents either sandboxed (in kubernetes via kind) or containerless ("free reign", perhaps) on the Linux box, and host them on your tailnet. The desktop app gives you either a chat or terminal interface, and you can access them via the browser (e.g. on mobile), too.
One limitation is that it assumes you're working with a github repo, and each agent session gets its own clone to work with. Feel free to shoot me an email (link in github) with any questions or specific needs and I'd be happy to try to help you.
I currently have a few VMs in a Proxmox cluster that serve as sandboxes, talking to various inference machines, all self-hosted (so I don't have to worry about having "enough credits" either).
Agent Substrate from google if you wanna go hardcore, although it adds quite a bit of complexity and management that you probably don't want if it's just a personal setup - https://github.com/agent-substrate/substrate
Docker with tailnet is probably good enough for your usecase.
I did some investigation into podman since I'm on Fedora and my limited understanding is that it is a bit more lightweight and less tied to the commercial Docker offering. My conclusion was that even that was a bit more than is actually needed. Both Opus 5.5 and Sol 6.1 suggested just to set up a single `agents` user on the box that both use and put things like shared dev credentials into a ~/.config/agents subfolder.
But there are many tiny details to the whole setup. Like, making sure services start at boot instead of login. And adding isolation to dev resources (I mostly use Postgres and Redis) to avoid agents stepping on each other. There's also things like setting up GitHub Apps so that attribution works well. And then there are the "remote control" features of Claude vs. a persistent tmux I can ssh into. I've could go on, but I think most people will get the point.
I'm actually surprised I don't see more discussion about this from devs.
A self-hosted cloud offering is very close to what I was thinking of from a commercial offer. It is also the least documented, which makes sense. I'm guessing what I am trying to do is the niche case and most devs will either want to run on their local machine and/or a cloud. Therefore a commercial offering is obviously going to want to support local while providing a low-friction on-ramp to their commercial cloud product.
I recommend "byre" from that list, because I built it. You can inject credentials you want into it, but it can't touch the host. I run all my coding harnesses inside it. At the end of the day, it's a flexible and reusable way of spinning up Docker containers designed for agents.
Thank you for the resource, this kind of aggregation is very useful.
On a quick skim you have categories: Local, vendor-managed, Hybrid. I am looking for something in-between local and vendor-managed. In a sense, I want the separate box to be the sandbox, rather than have a sandbox on my local machine isolated using a container or VM. That is a bit different of a setup with its own constraints that things like VMs or containers don't directly address.
The RAM-over-CPU point matches what I've seen self-hosting small stacks on a VPS: CPU sits idle and memory is what forces the next box.
Two questions. With gVisor sharing host memory, what happens when several browser-heavy sandboxes spike at once on the same host: OOM-kill, throttle, or migrate? And at $0.05 to $0.10 per free user, what's the rough sandbox density per host?
If a host reaches critical memory, then it will start restarting memory heavy sandboxes, but it's own us to relieve pressure on such hosts by moving the new ones and sleep awake one's off of it.
So 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 and it's quite managable.
I have been using your service for a few months… super easy to set up and use. I signed up after my bank would not let me process a payment to Hetzner :)
My use case was to play around with hermes. I was using it for a while but I didn’t like how it ended up (the whole set up became overran with files and was a mess, my fault).
I still haven’t 100% figured out how I may want to use the service again, but I thought it was super easy to set up.
My only feedback is that some connectors for google’s integration were kind of privacy nightmare the last time I checked.
Google’s API for using AI has abominable UI and set up.
It would be nice to be able to bridge the gap of simplifying Google’s AI/Service integration while not having to hand over access to every Google service I use.
For connectors we do offer managed MCPs like Composio, BraveSearch, and even an LLM gateway (which routes to openrouter). So what we have is simply a pass through for now and we're not looking to do more there. Since most of our early customers were just launching personal agents like Hermes, OpenClaw, Claude Code and wanted an easy white label setup.
Although now it's expanded to just sandbox usecases.
Congrats on the launch. Question from someone running agents locally: how do you handle filesystem state between runs? Most of my agent work isn't compute heavy, it's the setup and teardown cycle that eats the time. Also curious about cold start on the cheapest tier. That number decides a lot for anyone chaining many short runs.
It depends on how frequently your sandbox is awake. We do provision large disks so that warn boot time is directly from NvME disk and if it's warm, the coldstart is under a second.
But if it's rarely used then it's slower when it has to come from cold object storage.
But it seems that the low prices are only for pre-defined agent templates like hermes/pi/opencode.The ubuntu/android sandbox is still relatively high (lower than boat, but not much).
Nice, you caught my eyeballs at the right time. I'm going to sign up for it. Cursor / GrokBot already gives me this, but I'm looking to recreate this setup as a backup so that I don't get locked in. This feels like the right direction. Move all this stuff off my desktop and then run everything from my phone.
Pretty cool, trying it out. What LLM is it using in the free tier? I was surprised that it worked without supplying an API key. The model doesn't seem to know either: "This run is labeled agent37/default. That’s the configured model name I can see; it doesn’t reveal which underlying model/provider it maps to.".
We use OpenAI Luna for the agent37/default model for that.
Yeah in addition to sandbox we also have managed MCPs and our own LLM gateway to make building hosting agent harnesses easier. Most of our customers host hermes, opencode, claude code etc. and needed an easier setup so we ended up offering our own LLM gateway for it, ready to use with the sandbox
> I still can’t retrieve the page from the link: the public-web reader is out of quota, and my direct fetch isn’t available in this session.
I wanted the QM agent to read my website but it says I'm out of quota. Seems a bit odd to have a quota on that. Plan usage explains that there is a quota on searches, which makes sense, but it does not mention that there is one on fetching URLs directly.
edit: Tried again but with Hermes agent and it worked. It was my first time using QM so maybe it's a capability I had to configure.
So the QM agent is a bit different than a typical harness. It sometimes for tasks that it needs to do more research, launches a separate sandbox per user where it does all the hard tasks.
And so for that it needs workspace credits so that it can spawn new sandboxes for such tasks. Especially if you just started with the free agent.
Cron jobs were a big problem, especially if you want agents that must auto-sleep to save on costs. Since you cannot put the cron jobs within the sandbox container anymore, we eventually created our own cron API to wake up the sandbox and execute the cron
I've seen people set up crons to run every 15 minutes and accidentally spend a ton because the agent runs every time, even when there's nothing to do. Do you have a way to run a cheap check first and only wake the agent when something actually needs its attention?
I used agent37 for a protoype a few weeks ago and it was amazing, awesome work. cold start time was ever so slightly annoying but nevertheless, cost is attractive
We have a few different types of sandboxes now. The default one's are optimized for cost so the cold start times are higher. But we're also launching performance and full VM which has better metrics on the other factors.
When I saw 2 vCPU and 4GB, and then below that "4 GB persistent disk" I was like ooohhh it's the disk, not the memory. But it IS actually 4GB memory + 4GB disk.
This is amazing! We are using Box (now Boat dev) and yours is the first offering that looked even more economical. Will be exploring. Cheers and all the best
Similar to Sprites in capability, so if you can use sprites you can use agent37. We're also about 94% lower cost than them.
Fly certainly has great branding since they've been around for a while now. So they have a distribution advantage. But I think at some point they will also need to own some niche rather than just being a generic sandbox company, given how competitive the space is.
I'd be curious to see stats on overlap among startups by batch historically. My impression is that this has always been a thing. Based on where the market/technology horizon currently is, there are some buckets that are very "startup shaped". Founders who are iterating on ideas using similar criteria will often end up in the same proximity, especially in an accelerator environment. But it would be extremely interesting to see if this has become more prevalent over time, or at least since the explosion in the AI market.
hahaha, I suppose it is becoming a bit like hunger games, haha.
I was genuinely surprised to see how much overlap there was in the batch across startups.
Bruh, that's lack of understanding and insight as well as naivety. It is not a race to the bottom. LLM is the winner-takes-all market. Competitors are pricing against each other to come out on top.
Once there is a winner, there will be a price correction.
In your case, positioning yourself as a cheap provider is inherently a bad idea.
> Once there is a winner, there will be a price correction.
Only if there is some form of lock in or the others go out of business. Both of those are low probability.
I'd put a friendly wager on the (lack of) increase of token costs in the next 2 years.
It is the first one that everyone in the space is hoping for. When I say "winner takes it all," I am talking from a company's perspective. It is going to be cola vs. Pepsi. Either company chooses cola or Pepsi as their vendor and not both. I believe there will be a duopoly in the models.
I answered this in detail in another comment above, but really the basics are skip the hyperscalers and place the pods more efficiently based on available resources.
Yes, the main factors are exactly the one's i've listed above. For example by skipping the hyperscalers where you get your bare metal you get the biggest bang for buck in cost. AWS has 80-90% margins, so you gotta rent the bare metal directly.
The second big lever is being able to place the pods on hosts with enough CPU/RAM capacity as they awake. Agentic workflows are spiky which means not everyone is going to use all of the cores and RAM all the time, which allows you to play with the placement, and then there's some minor optimizations you can do as you dive deeper.
haha, it's been on list for a while, but none of our customers have asked for it so far. But it's easy to build a custom Docker image with that harness and start using it.
agreed, ttl alone is weak. but brokers get hard with google oauth. scopes are coarse and the agent acts as the user. how does plimsoll handle refresh tokens?
Interesting, I looked into this. So The t4g.nano is 2 vCPU but only 0.5 GB RAM, so there's that trade off.
And from what I can tell as you bump more RAM, agent37 is around 5x cheaper: our 2 vCPU / 4 GB box is $4.94/mo (2/4/6 GB disk), vs AWS t4g.medium (the actual 2 vCPU / 4 GB Graviton box) at ~$24.50/mo
Yeah, this seems like a niche where multiple startups are coming in. But if I remember correctly, we're about 3X cheaper than boat. We did a detailed comparison of all sandbox companies and where we stand across vendors here
Congrats on the launch! Very exciting!
You guys are operating in a very competitive space. This stuff is fun to build, so a lot of engineers will end up building it. Not to discourage you, but I suspect it will be difficult to capture much value selling this offering as its going to be race to the bottom against very well funded alternatives that can sell these features at a loss in order to get you to use their databases and other offerings that are higher margin and stickier.
As you guys learn more about how to take this sort of technology to market, you may consider trying to get closer to the actual work that people actually need these agents to do. What can you do better because you have this technology? For example, 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.
Food for thought! Good luck!
Thank you ! And agreed, it's an extremely competitive space. In our YC batch alone there's probably 5+ companies doing something similar. Interestingly enough though atleast for now we're all rapidly growing, so that's promising.
But eventually I see us all moving in slightly different spaces as we specialize.
Great to hear you are growing! Take this as you might grains of salt.
The promise of really cheap AI sounds amazing and is amazing. People will happily accept and engage with "free stuff"; but, I presume you are not starting a business to give away free stuff. Unless you have some model that let's you capture value some other way. e.g. Meta just gave everyone a small computer for free with Muse. Or have some sustainable price advantage on the underlying compute e.g. you are nvidia and make it yourself at scale.
I think you deserve to be compensated for your work! It's hard to make a sustainable business when selling something that costs $5 a month to developers (just seeing your calculator). There aren't that many of us, and AWS/GCP/Azure/Cloudflare have our credit cards already. If it were me, I'd be trying to figure out how to charge more and sell the value of the work you are enabling your customers to accomplish, not the cost of the underlying electrons.
Keep it up!
thank you, yeah we still have a lot to figure out.
That has to be one of the most positive ways of delivering feedback I've seen. Well done
I've been looking at offloading local work from my MacBook Pro (M1 Pro / 32 GB) specifically because I've been working with a lot of Android apps and emulation is killing me on top of everything else that I'm running.
Got a bunch of Daytona credits which are close to useless given their restrictions until you hit tier 3.
You seem like you're actually slightly cheaper than https://boat.dev/ but with less storage? That's the closest to your pricing unless I'm mistaken. Any other insight as to differences between you two?
Also I'll add you to a list I've been maintaining of sandbox providers, congrats on the launch!
https://engine.build/lab/agent-sandboxes
Boat is a great company too! As far as pricing goes our default sandboxes are about 2.8X cheaper than boat.
We did some detailed pricing analysis here https://www.agent37.com/pricing#sources
For storage you can request more storage if your use case needs it. And yes would appreciate it if you can include us.
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. Without any hardware innovation, it's tough for me to see this working. If you are going with a customization angle, again, no moat and plenty of competitors
There's a talk from Travis Kalanick recently on a podcast about this. It talks about the advantages of a startup vs an incumbent. My read is if a startup competes on price, the incumbent has no choice but to first let them gain a bunch of market share. It's too expensive for the incumbents to compete on price because a no-name startup is doing it. So they'd have to let you get relevant enough for it to make sense to compete on that axis.
I view it as a wedge to gain market share and later compete on something else.
This isn't commoditized because an incumbent has the market share, it's commoditized because there are dozens of providers in a crowded market. So what is likely going to happen is there will be a race to the bottom in terms of price.
PS - This is why I loathe advice from prominent software co operators. It's not one size fits all. Uber's strategy is going to be very different than Tesla's strategy which is going to be very different from Amazon's strategy.
unless the startup has gobs of free money how can they do this against an incumbent? note: nobody has gobs of free money anymore, except the incumbents. Startups competing on price is typically not a winning strategy, unless they have some technical advantage that shifts the price curve; subsidizing a move on it doesn't work.
It's the latter for us. We have healthy margins even at this price point. So we don't actually need a lot of money to do this against incumbents.
.. Don't you think it suspicious/sounds too good to be true? A newly created product space with insane margins, and easy to compete in?
Easy to compete+huge margins -> lots of competitors who compete on price -> commotidization -> lower margins -> not good
haha, the inevitable cycle of capitalism.
Carving out market share and aiming for an acquisition exit is a valid win condition.
It also serves the consumers in the long run as it eventually will force competition and price reductions; effectively busting up price leadership dynamics.
> but if this turns out to be a real market, they will lower cost
Can you show 1 case of this happening?
This is really impressive work on the infrastructure side. Skipping hyperscalers like AWS for Hetzner/OVH is definitely a massive lever, but your choice of gVisor for memory overcommit is where this gets technically interesting. A few questions on the implementation: • Memory & Density: Since gVisor allows you to share memory without reserving a full VM's allocation, how are you handling noisy neighbors if multiple sandboxes spike in RAM usage simultaneously? Are you using specific cgroups configurations or out-of-memory (OOM) killer tuning to prevent one sandbox from crashing the host? • Storage Persistence: You mentioned that files stay with the agent across sessions. How are you handling the storage layer efficiently at $0.05–$0.10/user? Are you using localized NVMe storage with networked backups, or something like ceph/block storage? • Cold Starts: When a sandbox wakes up from auto-sleep, what is the exact latency for the user? Congrats on the launch and the pivot from a simple wrapper to a real infrastructure play!
You can do a loooooot more with regular cloud providers. I think this platform just targets the niche of people who want to simply run containers.
The host isolation everyone is comparing on price is not the hard problem.
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.
The broker point is the part I keep coming back to as well. Short-lived credentials help, but an agent can do a lot in five minutes if the scope is still broad, so the interesting boundary is really per-action rather than per-session. A broker that can say this task may read mail but not send it, or may create a draft but not charge a card, feels much closer to how you would delegate to a person. The tradeoff is friction: once every unusual call needs approval, you lose a lot of the hands-off benefit that made the sandbox cheap to run in the first place. I would be curious where people are landing on audit logs here: is a clear record of what the broker allowed after the fact enough for most work, or do you want approval before anything irreversible?
This matches what I ended up doing with my own agent setups. The agent never gets a key that can move money out. I fund a separate wallet, the agent gets delegated spending that I can revoke, and withdrawing is just not something it is able to do. Same idea with an API key I use for automation at work: it can edit and reject drafts, but publishing comes back as a 403 and stays a human click. The thing I worried about was never the agent breaking out of a box. It was the agent doing something allowed but dumb with a grant that was too broad.
How do you see this fitting with AWS’s Strands Box from last week? Box isn’t hosted compute. It’s an open-source sandbox plus a policy engine that checks shell, Python, egress, and MCP calls, and swaps credential placeholders for real secrets at the gateway. That’s the broker layer ekorondy and talkarimli are asking about.
Two questions: Could a policy layer like Box run inside your gVisor sandboxes, or would it need your full-VM tier? And on price, have you compared against AgentCore Runtime? It bills CPU only while active, which targets the same bursty pattern you’re optimizing for.
> 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.
I am actively working on exactly this. Once its ready, will post here on HN.
Looks like you are running tools/browser in the same VM. How safe is this? Do you see contention for ports/resources? How does it compare to offerings from other sandboxing providers?
gVisor is... less secure than VMs; but the front page price-compares against VMs, so not apples-to-apples
That's fair, capabilities wise we have to limit certain things on what gvisor based sandboxes can do in terms of things like networking, and other capabilities to compensate for this class if sandbox. However over 80% of the use cases I'm seeing simply doesn't need much beyond that.
Are you using Kubernetes to orchestrate sandboxes, or have you built your own scheduler? I'm curious how you handle sandbox placement, resource allocation, and lifecycle management at this cost level.
Nice. But apparently the only option offered is paying via CC. In France my bank charges egregious fees for paying in anything other than Euros, while Paypal does the conversion for free. Will you offer Paypal at some point?
Yes, I'll just offer you free credits meanwhile. Ping on the website chat and mention you were from hackernews.
Thanks! Will do!
I run a daily job that clones and runs a freshly launched open-source project in a sandbox, so a few notes from the consumer side of this market.
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.
The things that actually cost me time were not CPU or RAM, though. 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.
Two questions: can a sandbox’s egress allowlist be changed while it is running, and when gVisor does not support a workload (you mention Docker-in-Docker), does the API fail fast or does the job just hang?
Do you have trouble with agentic burst traffic? Customers monopolizing resources and others getting 429 all the time?
Congrats on the launch!. Looks awesome. One small gripe I have is that the user success stores seems obviously like claude has written them. I cancelled my claude sub for codex, partly because i cannot understand claude's style at all - not that there is anything is wrong with it, its effing incomprehensible.
Compare the two yourself and judge(latter is written in gpt-6 luna).
> One client is one API call. It comes back as an always-on Hermes agent that holds that client’s data, that client’s identity, and a hard ceiling on what it can spend. It answers on an OpenAI-compatible endpoint from the moment it boots, so integrating it was a base URL, the same as pointing at any model API.
> Boon provisions an agent for a client with one API call. Each agent has its own client data and identity, along with a spending limit. It exposes an OpenAI-compatible endpoint, so Boon can connect to it by configuring a base URL.
Thank you! Omg you're right, I absolutely hate Claude's writing. I get so annoyed even with it's responses as I'm coding.
That's interesting though about Luna. I didn't realize GPT models are so much better at writing. I'll be taking another pass at these!
congrats on the launch.
i think the sandbox part is getting commoditized, like others said. the harder part is what the agent can touch inside it.
you connect google, the agent gets access to everything. sandbox protects the host. it does not protect your tokens.
scoped, short lived credentials per task. that i would pay more for. is it on your roadmap?
Short-lived tokens only limit how long a credential works, but better than nothing. i.e. They don't stop an unwanted action while it's still valid.
A practical pattern is an outside broker: the guest never sees the real credential and can't pick the destination, only a path from an allowlist.
Shameless plug for my project, I maintain one of these brokers: Plimsoll's broker sits outside the sandbox, injects the upstream credential itself, matches method + exact path (no query strings, no traversal, no encoding tricks), and enforces (some limitations that I am want to improve) a total call budget plus per-route caps. So a task can be granted "GET /items/* plus at most one job submission" even when the underlying key is coarser.
Worth a look if you're thinking about narrower credentials for services whose keys are still coarse: https://github.com/plimsollmark/plimsoll (docs/capability-grants.md, and the broker walkthrough at https://plimsollmark.github.io/plimsoll/trainers/brokering.h...).
This is cool; pricing is certainly appealing. At the same time, there are a ton of sandboxing providers.
> When you look at agent harnesses, ... CPU/RAM utilization we could lower the cost.
How does it work today? Is the harness (assuming it means the agentic loop) located in a separate VM and each loop-run invokes a separate sandboxing VM?
That's right each harness runs in it's own sandbox. Really the harness itself is just a docker template with some pre-installed harness (say openclaw, hermes, claude code, opencode, pi, grok etc) that runs.
For convenience and cross-harness unified API we also built open source Gateway API - https://github.com/agent37-platform/gateway
Think of it as open router for Agent harnesses. So in our default templates we also run this and expose the APIs. So that makes using any harness easy as they all speak a single OpenAI responses API schema.
Tangentially, I've been investigating the last few days on how to setup a separate Linux box as an agent "playground". I got a mac mini to use as my own personal driver and now my Linux box is free, so I want to have a local setup where I keep my personal machine a bit stricter while giving near free-reign for agents on the Linux machine.
It is like a locally-hosted version of these commercial projects. But I'm doing it ad-hoc. This seems like a space that should be filled by open source. What are the options that exist now? I have pro plans for both Codex and Claude Code and enough credits to run a couple instances of each. I want to control them from the mac mini over a tailnet. What options exists now?
I've been working on this open source project for a few months, but just put up a product website today, actually: https://yaac.dev/
You can run the agents either sandboxed (in kubernetes via kind) or containerless ("free reign", perhaps) on the Linux box, and host them on your tailnet. The desktop app gives you either a chat or terminal interface, and you can access them via the browser (e.g. on mobile), too.
One limitation is that it assumes you're working with a github repo, and each agent session gets its own clone to work with. Feel free to shoot me an email (link in github) with any questions or specific needs and I'd be happy to try to help you.
I currently have a few VMs in a Proxmox cluster that serve as sandboxes, talking to various inference machines, all self-hosted (so I don't have to worry about having "enough credits" either).
Agent Substrate from google if you wanna go hardcore, although it adds quite a bit of complexity and management that you probably don't want if it's just a personal setup - https://github.com/agent-substrate/substrate
Docker with tailnet is probably good enough for your usecase.
I did some investigation into podman since I'm on Fedora and my limited understanding is that it is a bit more lightweight and less tied to the commercial Docker offering. My conclusion was that even that was a bit more than is actually needed. Both Opus 5.5 and Sol 6.1 suggested just to set up a single `agents` user on the box that both use and put things like shared dev credentials into a ~/.config/agents subfolder.
But there are many tiny details to the whole setup. Like, making sure services start at boot instead of login. And adding isolation to dev resources (I mostly use Postgres and Redis) to avoid agents stepping on each other. There's also things like setting up GitHub Apps so that attribution works well. And then there are the "remote control" features of Claude vs. a persistent tmux I can ssh into. I've could go on, but I think most people will get the point.
I'm actually surprised I don't see more discussion about this from devs.
Use smolvm, support for tailscale in each VM.
https://github.com/smol-machines/smolvm
A self-hosted cloud offering is very close to what I was thinking of from a commercial offer. It is also the least documented, which makes sense. I'm guessing what I am trying to do is the niche case and most devs will either want to run on their local machine and/or a cloud. Therefore a commercial offering is obviously going to want to support local while providing a low-friction on-ramp to their commercial cloud product.
https://pleasedonotescape.com/
I recommend "byre" from that list, because I built it. You can inject credentials you want into it, but it can't touch the host. I run all my coding harnesses inside it. At the end of the day, it's a flexible and reusable way of spinning up Docker containers designed for agents.
Thank you for the resource, this kind of aggregation is very useful.
On a quick skim you have categories: Local, vendor-managed, Hybrid. I am looking for something in-between local and vendor-managed. In a sense, I want the separate box to be the sandbox, rather than have a sandbox on my local machine isolated using a container or VM. That is a bit different of a setup with its own constraints that things like VMs or containers don't directly address.
The RAM-over-CPU point matches what I've seen self-hosting small stacks on a VPS: CPU sits idle and memory is what forces the next box.
Two questions. With gVisor sharing host memory, what happens when several browser-heavy sandboxes spike at once on the same host: OOM-kill, throttle, or migrate? And at $0.05 to $0.10 per free user, what's the rough sandbox density per host?
Thx,
Z
If a host reaches critical memory, then it will start restarting memory heavy sandboxes, but it's own us to relieve pressure on such hosts by moving the new ones and sleep awake one's off of it.
So 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 and it's quite managable.
I have been using your service for a few months… super easy to set up and use. I signed up after my bank would not let me process a payment to Hetzner :)
My use case was to play around with hermes. I was using it for a while but I didn’t like how it ended up (the whole set up became overran with files and was a mess, my fault).
I still haven’t 100% figured out how I may want to use the service again, but I thought it was super easy to set up.
My only feedback is that some connectors for google’s integration were kind of privacy nightmare the last time I checked.
Google’s API for using AI has abominable UI and set up.
It would be nice to be able to bridge the gap of simplifying Google’s AI/Service integration while not having to hand over access to every Google service I use.
Thank you, that's so great to hear !
For connectors we do offer managed MCPs like Composio, BraveSearch, and even an LLM gateway (which routes to openrouter). So what we have is simply a pass through for now and we're not looking to do more there. Since most of our early customers were just launching personal agents like Hermes, OpenClaw, Claude Code and wanted an easy white label setup.
Although now it's expanded to just sandbox usecases.
Congrats on the launch. Question from someone running agents locally: how do you handle filesystem state between runs? Most of my agent work isn't compute heavy, it's the setup and teardown cycle that eats the time. Also curious about cold start on the cheapest tier. That number decides a lot for anyone chaining many short runs.
It depends on how frequently your sandbox is awake. We do provision large disks so that warn boot time is directly from NvME disk and if it's warm, the coldstart is under a second.
But if it's rarely used then it's slower when it has to come from cold object storage.
Is this using cloudflare behind the scene? how does it compare with https://agents.cloudflare.com/
We do use cloudflare for networking. But Cloudflare sandboxes are even more expensive than most. It's about 30X lower cost than cloudflare sandboxes.
Congrats on the launch.
But it seems that the low prices are only for pre-defined agent templates like hermes/pi/opencode.The ubuntu/android sandbox is still relatively high (lower than boat, but not much).
Congrats on launch! gVisor for memory sharing + Hetzner is clever for cost. How's cold boot time for free tier users?
any chance this is open source/core? See you have soc2 in progress, which is good.
Yes considering doing that, just haven't had the time to focus on it, among everything else, but it's in the cards.
Nice, you caught my eyeballs at the right time. I'm going to sign up for it. Cursor / GrokBot already gives me this, but I'm looking to recreate this setup as a backup so that I don't get locked in. This feels like the right direction. Move all this stuff off my desktop and then run everything from my phone.
looking forward to it, DM me any feedback on the website chat as you use it :)
How are you isolating filesystem state between concurrent sandbox instances without incurring heavy snapshot/restore I/O penalties?
Pretty cool, trying it out. What LLM is it using in the free tier? I was surprised that it worked without supplying an API key. The model doesn't seem to know either: "This run is labeled agent37/default. That’s the configured model name I can see; it doesn’t reveal which underlying model/provider it maps to.".
We use OpenAI Luna for the agent37/default model for that.
Yeah in addition to sandbox we also have managed MCPs and our own LLM gateway to make building hosting agent harnesses easier. Most of our customers host hermes, opencode, claude code etc. and needed an easier setup so we ended up offering our own LLM gateway for it, ready to use with the sandbox
Also, curious if this is intended or a bug:
> I still can’t retrieve the page from the link: the public-web reader is out of quota, and my direct fetch isn’t available in this session.
I wanted the QM agent to read my website but it says I'm out of quota. Seems a bit odd to have a quota on that. Plan usage explains that there is a quota on searches, which makes sense, but it does not mention that there is one on fetching URLs directly.
edit: Tried again but with Hermes agent and it worked. It was my first time using QM so maybe it's a capability I had to configure.
So the QM agent is a bit different than a typical harness. It sometimes for tasks that it needs to do more research, launches a separate sandbox per user where it does all the hard tasks.
And so for that it needs workspace credits so that it can spawn new sandboxes for such tasks. Especially if you just started with the free agent.
How do cronjobs work? IE: If I ask an agent to setup a cronjob to check on my email once a day, how does the sandbox behave?
Does it have a layer that intercepts Cronjob creation, and setups up a reminder on the supervisor to wake the VM to run the agent job?
Great question!
Cron jobs were a big problem, especially if you want agents that must auto-sleep to save on costs. Since you cannot put the cron jobs within the sandbox container anymore, we eventually created our own cron API to wake up the sandbox and execute the cron
https://www.agent37.com/docs/agents-api/crons#crons
I've seen people set up crons to run every 15 minutes and accidentally spend a ton because the agent runs every time, even when there's nothing to do. Do you have a way to run a cheap check first and only wake the agent when something actually needs its attention?
I used agent37 for a protoype a few weeks ago and it was amazing, awesome work. cold start time was ever so slightly annoying but nevertheless, cost is attractive
Thank you! That's great to hear :)
We have a few different types of sandboxes now. The default one's are optimized for cost so the cold start times are higher. But we're also launching performance and full VM which has better metrics on the other factors.
When I saw 2 vCPU and 4GB, and then below that "4 GB persistent disk" I was like ooohhh it's the disk, not the memory. But it IS actually 4GB memory + 4GB disk.
yes :)
This is amazing! We are using Box (now Boat dev) and yours is the first offering that looked even more economical. Will be exploring. Cheers and all the best
Thank you, looking forward to it.
I think fly.io sprites is the closest price wise, would love to see it on the comparison list
I have yet to use sandboxes though have some experimentation planned for a new gig I'm starting in a week.
How would you compare what you do to fly.io's Sprites (which is currently atop my To Try list)?
Similar to Sprites in capability, so if you can use sprites you can use agent37. We're also about 94% lower cost than them.
Fly certainly has great branding since they've been around for a while now. So they have a distribution advantage. But I think at some point they will also need to own some niche rather than just being a generic sandbox company, given how competitive the space is.
I had ran into another yc startup from the same batch doing the same thing recently. I think it was called maritime.
YC batch are becoming more like hunger games.
I know a few companies where this is just a feature like digitalocean it is just a feature.
I'd be curious to see stats on overlap among startups by batch historically. My impression is that this has always been a thing. Based on where the market/technology horizon currently is, there are some buckets that are very "startup shaped". Founders who are iterating on ideas using similar criteria will often end up in the same proximity, especially in an accelerator environment. But it would be extremely interesting to see if this has become more prevalent over time, or at least since the explosion in the AI market.
It is also funny to see folks and friends of the startup commenting and trying to boost this post which is against the guidelines, but thats ok.
hahaha, I suppose it is becoming a bit like hunger games, haha. I was genuinely surprised to see how much overlap there was in the batch across startups.
Yeah its a race to the bottom as ai can vibe code any infra now
hahaha, I think it's the same thing as what's happening with LLMs and token cost.
Bruh, that's lack of understanding and insight as well as naivety. It is not a race to the bottom. LLM is the winner-takes-all market. Competitors are pricing against each other to come out on top.
Once there is a winner, there will be a price correction.
In your case, positioning yourself as a cheap provider is inherently a bad idea.
> In your case, positioning yourself as a cheap provider is inherently a bad idea.
Why is that a bad idea? When the providers have the same features, wouldn't the customers choose the cheaper alternative?
> Once there is a winner, there will be a price correction.
Only if there is some form of lock in or the others go out of business. Both of those are low probability. I'd put a friendly wager on the (lack of) increase of token costs in the next 2 years.
It is the first one that everyone in the space is hoping for. When I say "winner takes it all," I am talking from a company's perspective. It is going to be cola vs. Pepsi. Either company chooses cola or Pepsi as their vendor and not both. I believe there will be a duopoly in the models.
This hasn't happened in the sandbox space though. For example Modal was early to it, and yet you see Daytona, E2b and many others doing quite well.
The switching cost is not trivial unlike LLMs
feels like there could be a sandbox router (like openrouter) company soon.
how are you doing cheaper than alternatives pricing? i assume some sort of snapshotting and sleep, wake on network thing?
I answered this in detail in another comment above, but really the basics are skip the hyperscalers and place the pods more efficiently based on available resources.
Congrats on the launch! Can you speak on how you are able to keep the cost really low?
Yes, the main factors are exactly the one's i've listed above. For example by skipping the hyperscalers where you get your bare metal you get the biggest bang for buck in cost. AWS has 80-90% margins, so you gotta rent the bare metal directly.
The second big lever is being able to place the pods on hosts with enough CPU/RAM capacity as they awake. Agentic workflows are spiky which means not everyone is going to use all of the cores and RAM all the time, which allows you to play with the placement, and then there's some minor optimizations you can do as you dive deeper.
Was DeepSeek Harness (DSH) intentionally omitted from the listed harnesses for any technical reason?
haha, it's been on list for a while, but none of our customers have asked for it so far. But it's easy to build a custom Docker image with that harness and start using it.
Thanks for confirming there's no technical reason for the omission!
agreed, ttl alone is weak. but brokers get hard with google oauth. scopes are coarse and the agent acts as the user. how does plimsoll handle refresh tokens?
Congrats on the launch. What's your turn around time to sign a BAA?
Depends on the contract value, let's have a chat https://cal.com/vishnukool/30min
Just use EC2 t4g.nano
Interesting, I looked into this. So The t4g.nano is 2 vCPU but only 0.5 GB RAM, so there's that trade off.
And from what I can tell as you bump more RAM, agent37 is around 5x cheaper: our 2 vCPU / 4 GB box is $4.94/mo (2/4/6 GB disk), vs AWS t4g.medium (the actual 2 vCPU / 4 GB Graviton box) at ~$24.50/mo
Use digitalocean's microvms, they are cheaper.
Interesting. will give it a try !
This is freaking great. Thank you for posting!
glad to hear it, thank you!
Hi, Vishnu, congrats on the launch.
There is another even cheaper sandbox which is in YC (boat.dev)
How do you compare to them and how are you cheaper then they are?
Thank you!
Yeah, this seems like a niche where multiple startups are coming in. But if I remember correctly, we're about 3X cheaper than boat. We did a detailed comparison of all sandbox companies and where we stand across vendors here
https://www.agent37.com/pricing#sources
Funny I just asked that too but in my quick check boat was slightly more expensive albeit with more storage space.
What about Maritime.sh (which is also in YC)? I swear everybody in SF is building the same stuff. Lol