ReplayAutonomous app testing for teams who ship at AI-speed
Promoted
box
Simple computers for agent w/ full VMs
384 followers
Simple computers for agent w/ full VMs
384 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.
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
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.
The ESA-to-cheap-VMs origin is a fun one. The number I keep circling is the $0.036/hr — is that flat always-on, or does a box idle between agent turns bill differently? I run a bursty API on Fly and the thing that makes the economics work there is machines auto-stopping to near-zero between requests. An agent box is the opposite shape though: long-lived, holding state, mostly waiting on a model call. At 1000 concurrent that idle-but-alive time is most of the bill. Do you lean on suspend/resume for that, or is the bet that flat-and-cheap beats clever-and-metered for this workload?
1752vc Pitch Deck Analyzer
Full VMs instead of a locked-down sandbox feels like the right call for agents that actually need to do things. A lot of agent failures come from environments too restricted to be useful. The tension you're managing is the interesting part: a real computer per agent is powerful, but it's also the thing that keeps security folks up at night. How do you keep a confused or rogue agent contained without clipping the wings that make box worth using?