A few angles to this. One is that coding just went through a massive change over the past year, that is not yet fully settled. Remember when everyone insisted on using IDEs and seeing the code with a chat sidebar? It's hard to argue you'll still be reading code a year from now. And even today, most people are still developing locally, which we're betting will shift to the cloud over the next few years.

I imagine other players will build cloud support in their own apps, but even now there's a lot of distraction for them. Everyone is trying to still support local execution, which looks really different from cloud. A lot of the labs are taking their coding-focused teams and throwing non-coding on their plates as well (the same app for non-engineers slinging google sheets).

We think getting the cloud experience right for software engineers (as well as companies, with their own hosting/development needs) is going to be really hard, and the problem needs a team fully focused on that. We also think that companies are rightly nervous about putting all their eggs in one basket -- their long term development environment should be harness and model agnostic.

RE OpenCode + self-hosted/local models: definitely. There's nothing holding us back from supporting these since we're just linux machines. But we wanted to start with the most popular harnesses first and go from there.

It's definitely possible to build something like this yourself, but there are a lot of little things we've done that we think add up to a much better UX:

- A dedicated app where you can scroll through your thread/chat history and start a new thread/fork/VM just by typing a new message, along with access to persistent terminals organized by thread/machine. Push notifications as well when your threads are done. Sort of doable via termux/tmux/ssh/etc.

- It takes a little while to get git worktrees set up well to have multiple threads running in parallel. You have to make sure each worktree starts your app on a different port, for example. But some folks are able to get it in a good place through some manual setup work.

- We started hitting resource limits running 5 full copies of our app on 1 laptop (so each agent can test its work separately), but again, if you have a beefy enough machine this might not be a problem.

- We auto-handle port forwarding for you on desktop (and on mobile soon too). Again, you can finagle something like this with tailscale, but it's a pain in the butt to manually track which thread maps to which port on the same machine. We have some magic where if you select a thread in the desktop app, we automatically remap localhost:3000 (or any other port running there) to that thread's machine, so you can just reload your browser locally to test.

These are a few examples. From building this ourselves, we're pretty convinced that you need some sort of UI to do remote development in a super clean way that feels like localhost. But if you're willing to put in the work, you can probably get relatively close yourself!

It’s home server as a service.

Awman looks great - just installed on Windows and it built the image. I'm trying to figure out how to launch an agent...

FWIW, I'm working on Nemesis8: https://github.com/DeepBlueDynamics/nemesis8 if you want to team up. I'm kordless at gmail or kord at deepbluedynamics

Exactly my thoughts when I built all this: https://deepbluedynamics.com

I do provide cloud support for somethings like embeddings and crawling, but you can run it local if you want. The only thing closed source is the memory system, but it still runs local if you want it.

Lol ++. Although my local host for agent/codex stuff is a raspberry pi I connect to on LAN from my gaming/powerful desktop for sandboxing. However my use case seems to be the exact problem they are trying to solve! Might have to take a look into it at some point.

I'm building something like this that you can run in your own cloud!

https://flexenv.com/

It's nowhere near advanced as boxes.dev but it's built on the premise of running on any cloud. Indeed I have it running on two different bare metal server providers and I'm about to add a third (Azure) as I'm using my day job as my first customer.

Can I grab your contact details and schedule a demo?

Thanks a ton for the feedback. Yeah, this is something we'll try to solve in the long term. One of the things that makes this work really smoothly for setup and speed is the ability to have a template box that you can instantly snapshot and fork (disk and RAM) to spin up new machines. There aren't many sandbox providers that do that well for running a full app and development environment, but I'm sure there will be more over time. And the per-second pricing means that you only pay when your agent is running.

You could use VPS, but spinning up and down boxes on inactivity takes a long time, and making changes to the template for new machines is less trivial there. If you're only paying for 1 VPS box, then you lose the "multiple independent machines" benefit, and I imagine things start to get more expensive even in the VPS world when you have 10 of them running at the same time (one per thread).

Works well for very well defined task. If you have a really big feature like a front end migration, you can use /plan, and /goal which i think is in most harnesses. You can also use other tools that allow your agent to interact with other terminals(I use an ADE called orca) that has an orca skill where an agent can spin up different sessions(different from subtasks because they share the context and you can chose the harness/model unlike sub agents). Can also read from the terminal, use your browser or computer and task screenshots and after prepare a report or something.

To add to what @nab said, the longest ("overnight") runs are usually after going back and forth to build out a big multi-phase plan doc -- especially when each phase has an extensive manual test plan (agent runs the app in a browser, clicks through the workflow, watches logs, confirms behavior, etc).

These can go for many hours from all the manual testing and debugging. Quality really depends on how much you spec things out beforehand, and how you define the test plan / "success" gates. If the agent can't even run the app to test it then things can definitely go off the rails!

Usually coding where the closed loop evaluation takes time.

E.g code debugging

I think they are just bullshitting.

In codex, is you use /goal it can go for a while. I've never seen overnight but > 1 hr is common

"build me a 10 million dollar MRR saas, make no mistakes"

It's just one hour of runtime. But we put the machines to sleep very quickly once the agent finishes its work, and then wake when you interact in the UI (e.g. terminal, filesystem, send the agent a followup). We're running on firecracker microVMs so can sleep/wake very quickly, which keeps things nice and responsive.

Re: web searches -- we're running a full linux kernel and the agent runs on the machine itself, so we can't sleep mid run. But conceptually, moving the agent off-box and sleeping during web searches etc would be interesting, but in our experience coding agents are running enough stuff on the machine itself (rg, bash, playwright, etc) that there wouldn't be much savings.

Sorry about that. We should have made that more clear in the post but unfortunately HN doesn't let us edit it anymore. We're just 2 people right now and wanted to ship early. We want to support other platforms over the long term. We are cloud, but there is a local component for porting your local environment for the fast onboarding, so it requires some care. Are you on Windows?

It's even weirder that their long post doesn't mention it's Mac only.

Right now the way you'd do this is you'd select the "Main box" or template VM in the UI, pull up a terminal tab, and authenticate whatever MCPs you care about. These are stored however the MCP is storing them (likely filesystem) on the VM. When you're done, you can "snapshot" the template VM and all future forks/new threads will start from that snapshot of filesystem + RAM.

We recommend you auth with only development credentials (or use something like 2 factor confirmation if you have more sensitive things you want to confirm before the agent accesses), but it's still early for us and we're continuing to refine this as we go. For companies, we're down to brainstorm how they'd like this to ideally work for them. And over the long term we'll support hosting this in your own cloud.

Curious if you have a take on how you'd like this to work from a UX standpoint.