Nice, love the idea of having containers that can work on either local or remote. We may end up reaching out once we start thinking about that.
And thanks re: pricing model. It's a start, and we still have a lot of optimizations to go there to make this as cheap as possible, but we think it's a good base to build upon to make agents as efficient as possible compute-wise.
We're currently running Firecracker VMs in E2B, which separate kernel level isolation. Over the long term, we're open to making it cloud/provider agnostic if you don't like that and want to run in your own cloud.
Right now, since these are just linux machines, agents only have access to what you give them. For most development workflows, this means you're putting development environment variables and keys there.
We're also considering having some sort of key storage construct that allows you to require human confirmation for access to certain other keys, but curious if you have any thoughts on what the ideal UX is.
You can of course just build your ideal solution on the template box (perhaps 2 factor authentication via AWS secrets manager to get access to certain keys that require human confirmation), and update your skills. Then all future threads/forks will have access to that setup.
Oof, I don't think we paid super close attention to the country list when shipping our app. We'll fix this for you, but it might be a few days for things to make it out of review.
Really appreciate you trying it out. It's still pretty early so things are still rough around the edges, but we'll be keeping an eye out on our logs for bugs, and feel free to reach out to feedback at boxes.dev if you notice any issues.
Nice -- yeah I definitely think it's possible to get configuration figured out for worktrees, but does require a some setup. Glad you all are in a good place on that front.
RE: setup required to make a project ready for VM deployment, not sure how complex your app is, but we've found that coding agents do a pretty good job at finding your dependencies locally, installing them on the remote, and ensuring your app runs on the remote end. If you have a few minutes, try out our auto-setup. Most people haven't had to lift a finger to get their apps running in VMs.
The fun thing is that in some way it's a bit inaccurate. We auto port-forward ports from the remote machines to your localhost, so you can still just go to localhost:3000 or whatever, and it goes to whatever machine you have selected in the desktop app. We'll give you a browser in the mobile app too soon to hit "localhost" on mobile.
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!
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?
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).
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.
This. Very few people are doing this right now (probably because it sucks having 5 copies of your app running in parallel on your laptop), but in the past few months models have gotten really good at testing your running app live. If you have an environment where you can run your full app and models can get it at via playwright and chromium, they can click around, take actions, and actually verify that their code works.
With boxes.dev I've starting pushing agents harder to run the full app and test their work end to end, and send me screenshots as proof. This takes time, sometimes up to 30-40 minutes, but is much more likely to be bug free at the end of the day.
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.
This link implies that the NYT is backtracking about a piece apparently "blaming encryption." The NYT article referenced did not at all focus on encryption, and it didn't go so far as to definitively blame encryption.
The only paragraph discussing encryption is buried in the middle of the article.
"""
The attackers are believed to have communicated using encryption technology, according to European officials
"""
The lede did not mention encryption at all: "The attackers in Friday’s terrorist assault in Paris communicated at some point beforehand with known members of the Islamic State in Syria, officials on both sides of the Atlantic say."
What makes you think he was thrown under the bus? I figured they chose him because he's widely respected within the MIT community.
edit: http://xkcd.com/386/
