Launched this week
box
Simple computers for agent w/ full VMs
379 followers
Simple computers for agent w/ full VMs
379 followers
Box offers the simplest, cheapest cloud computers for agents, thought for builders of agentic platforms & software factories. Run 'box new' in your terminal, in 2s get a beefy ubuntu VM, with admin rights, a desktop, ssh access. At $0.036/hr it is 10x less expensive than the likes of E2B, Daytona, Modal, so you can run more agents, or run them longer. Run up to 1000 concurrent boxes fully self-served, or ask us for more, with same-day support from the founders.
box
Hello Product Hunt,
2 years ago, I worked at the European Space Agency, scaling their black holes & binary stars research efforts.
At that time, GPT 4o already helped us find many optimizations that made the code more scalable. But to test them, our agents needed a cluster of cloud compute, which we had to wait 2 months to get. AI may work fast but compute provisioning is slowing it down.
After leaving, I spent 10 months building cloud coding agents, which needed cloud computers too, so I tried many self-serve options for "computers for agents" and "AI sandboxes".
But there was no fit, they were optimized for bursty, short-lived scenarios on containers rather than full computers where anything just works...
... all while being super expensive, high multiples of what the same compute is worth in the average datacenter in Europe.
So 2 months ago, we built and launched box on X, our on-demand computers for agents, super cost-efficient and powerful.
Now our computers for agents have already run for 10 years in just 2 months, growing steadily every week.
Today, they already power many agentic platforms, software factories, cybersecurity audits platforms, with real customers in production.
Try box and let us know how it goes :) https://box.ascii.dev
bunny.net
@anic_dev congrats on the launch!
box
@marek_nalikowski thank you Marek!
Feather
@anic_dev Congrats on the launch. You guys built a great product. Happy user here!!
box
@pbteja1998 thanks Bhanu!
box
@thys_beesman we hit such low price because we designed the whole system for cost efficiency, using no dependencies and minimizing the operational costs. we have our own snapshotting system (beautiful tech built in-house), allowing you to easily stop/resume/fork your machine.
box
@thys_beesman Compute in European datacenters is just that cheap, its just hard to build around, we still make v good margins.
This looks really nice for spinning up cheap VMs quickly. One thing that would be a huge help: a built-in way to snapshot a box's state and resume it later, since agent workflows often need to pause and pick up where they left off rather than start from a fresh ubuntu every time.
box
@hediyedilli it is totally already built in!
Cool to see pricing finally getting competitive for agent VMs. One thing that would really help builders like me: a built-in snapshot or image registry so I can prebake a box with my project's tooling and spin up ready-to-go environments instead of installing dependencies every time. Would save a ton of time and make the 2s boot claim even more useful.
box
@mnevvertumazji you already can! see the templates section of docs.ascii.dev
"box new → beefy Ubuntu VM in 2s with admin rights" is a great DX. The thing I'd want to see front and center for agent VMs is teardown and isolation — an agent with admin rights and ssh is one bad loop away from doing real damage or leaking creds across boxes. How ephemeral is each one, and what stops an agent in box A from reaching box B? That's the part that decides whether I'd let something autonomous loose in it. Following.
Full VMs with admin + ssh instead of ephemeral containers is the right tradeoff for agents that install system deps or spawn nested processes — that is exactly where container sandboxes fall over. Two things I would verify before running many concurrent: what is the isolation boundary between boxes on the same host (separate kernels/hypervisor vs shared), and can I lock down egress per box or do agents get open outbound by default? Also, does box state persist across runs or is every "box new" a clean image?
The safety half of Brandon's question never got answered, and it is the more interesting half.
Snapshot and fork is recovery, not prevention. Restoring the machine undoes what the agent did to the machine. It does not undo what already left it. A pushed commit, a sent email, a dropped table on a managed database, a paid API call, none of those roll back when you restore the box.
Isolation bounds the blast radius to the VM. It does not bound it to the world, because the thing that makes an agent useful is the credentials you put inside the box with it.
So which is it today: is egress the customer's problem to govern above box, or is there something at the boundary? That answer changes who box is safe to hand to.