vishnukool

Agent37 also has full VM sandboxes as an option.

No we have sufficient reserve and new workspaces have limits on how many they can spawn till they add more spend.

A relay would be the right way of doing it. But for now we haven't taken on that complexity. So for cases like this just use our default sandbox and leave it on.. and you still only pay around $4.76 for a whole month..

For most cases where customers need control over that, there's other more useful levers, like their own web app where chat happens or something similar, where they can just intentionally wake it.

So as a user you have the choice of running tools/browsers etc. in the same VM. We don't currently offer a separate browser specific VM, but it really is upto the user on what they bundle into a sandbox.

Compared to any other sandbox provider I'm aware of agent37 is an order of magnitude better in price/performance ratio for any given task.

Our own scheduler. We strongly considered kubernetes, but it wasn't worth taking on that complexity. Part of the reason to not go with kubernetes was also the need to customize all these things around sandbox placement, managing live migration based on host resource utilization etc. which is all custom.

It's low for the default sandbox type, regardless of the template or custom image. What I find though is 80% of the times these are good enough.

But for the cases where you want Docker under Docker, KVM, kubernetees or android emulator etc. we added a new class that's both performant and supports these.

It's the same fore free vs paid users, around 200-300 ms if it's warm. The free users are only limited by number of hours we give per week. And often if they're a regular user it's still warm

Cold depends on the storage size. So a few seconds on average if it's not too big

We use gvisor and cloud hypervisor depending on the use case, which manages these things pretty well by default.

thank you!

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.

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.

Yes considering doing that, just haven't had the time to focus on it, among everything else, but it's in the cards.

Yes, I'll just offer you free credits meanwhile. Ping on the website chat and mention you were from hackernews.

Depends on the contract value, let's have a chat https://cal.com/vishnukool/30min

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.

Thank you, looking forward to it.

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!

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.

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.

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.

looking forward to it, DM me any feedback on the website chat as you use it :)

We do use cloudflare for networking. But Cloudflare sandboxes are even more expensive than most. It's about 30X lower cost than cloudflare sandboxes.

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.

yes :)

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

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

haha, the inevitable cycle of capitalism.

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.

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

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.