box

Simple computers for agent w/ full VMs

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product Hunt

Using box to offload large tasks from strawberry.computer phone prototype - works pretty well for me!

$0.036/hr for a full VM with admin rights is a wild undercut of E2B/Daytona - what's actually different on the infra side that gets you there, bare metal instead of nested virtualization, oversubscribed hosts, or just thinner margins for now? asking because a price that much lower than everyone else usually means either a real efficiency win or something that gets quietly walked back once you're past the free/intro tier.

box new giving you a real ubuntu box in 2s is the part i like. the thing i actually want this for is handing an agent a throwaway machine so it can go wild without touching my real setup. does the vm tear itself down after, or do i manage cleanup myself?

The 2s-to-VM claim caught my eye — that's the number that matters for agent workloads. Question: can you snapshot a warm VM and fork it? The pattern I keep hitting is N agents that all need the same base environment (deps installed, repo cloned) — cold-booting each one wastes most of the cost advantage. If 'box new --from-snapshot' exists, that's the killer feature. Congrats on the launch.

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?

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?

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.

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?

Brandon's "procurement cycles don't care how fast your model iterates" line hit hard — that's WinBidIQ's whole world, just for federal contracts instead of compute. Skipping procurement is the pitch here, but does any customer ever need a security review anyway before spinning up VMs with admin rights?

ran box new and had an ubuntu vm up in a couple seconds, which genuinely surprised me. the price point makes it easy to justify spinning up extra agents without watching the meter.

honestly the pricing is what caught my eye, super competitive. one thing that would help me though is a built in way to snapshot a box and fork it, like a template system, so i can spin up a preconfigured env instead of setting up every vm from scratch each time. would save a ton of time

Congrats on the launch @anic_dev

I’ll give box a spin! btw the branding is goated 📦

the pricing alone makes me want to try this out, but one thing that would help a lot is built-in snapshot support so we can pause a box mid task and resume it later without burning compute. would make longer agent workflows way more practical

Interesting. I just implemented this use case and landed on E2B. I'm running a platform that does agent evaluations of dev tools and the agents need sandbox environments to build in to validate the dev tool. How do you differ from E2B? I just built this feature a couple days ago so its quite new!

Full VM per agent is smart approach. Isolation at that level removes a lot of headaches with shared state. Whats the cold start time like when spinning up a new box?

The admin-rights VM detail matters. A lot of agent workflows fail in the messy middle between “clean sandbox” and “real developer machine”: credentials, GUI state, build artifacts, package caches, long-running processes. Cheap is useful, but realistic state is what makes debugging and delegation practical.

"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.

I’ve been using box for a few weeks now. By far the best provider and it’s not even close. Great prices, super fast and the founder proactively reached out when they saw I had an issue. My preferred sandbox provider! 📦📦