Nice, this looks exactly like what I've been looking for. I tried Fly.io Sprites and it _almost_ got me there, but I got annoyed logging into my CC every new feature. Unfortunately I wound up going all in on Cursor Cloud Agents, which overall has been decent.
Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
11–20 of 87 posts
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#12How does this handle MCP credentials - both for stdio servers that read tokens from local config, and for HTTP ones where harness holds an OAuth token? Either way those secrets end up in your cloud? Curious what the security model is
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.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#13I might use this if it supported any old cloud or VPS, and was at most $10/mo. The fact that you have decided that this platform should only live in your own custom cloud is unappealing to me. Or, open source it and let us run it on our own VPS and keep your expensive cloud for those who want to pay. As it stands would never consider it.
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).
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#14What are “box-hours”? Regular hours just running in boxes? Do I get charged the same when 1)the agent is doing some external thing say web search that takes a while, and 2) when the agent isnt running(say waiting for my input)?
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.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#15I might use this if it supported any old cloud or VPS, and was at most $10/mo. The fact that you have decided that this platform should only live in your own custom cloud is unappealing to me. Or, open source it and let us run it on our own VPS and keep your expensive cloud for those who want to pay. As it stands would never consider it.
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 m…
Pretty sure you could accomplish this in a large physical server or even a huge resource VM (that has KVM passthrough) with some sort of microvm technology? Then that would obviate the need for "multiple cloud instance per coding thread", it would just be a microvm on the large server.
Then again, I'm just the guy running his mouth, and you guys are the ones actually doing the work :)
BTW, looks very polished and thought-through, I may have to still give it a try!
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#16Maybe I’m naive but the longest single workflow I ran was maybe 15 minutes. How do you steer agents to run “overnight”? And what is the quality of such execution?
In codex, is you use /goal it can go for a while. I've never seen overnight but > 1 hr is common
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#17> ditch localhost; run Claude Code and Codex in the cloud
Why would I want this and not the other way around?
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#18Maybe I’m naive but the longest single workflow I ran was maybe 15 minutes. How do you steer agents to run “overnight”? And what is the quality of such execution?
I think they are just bullshitting.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#19This looks very clean, great job!
If your CTO didn't spend the past year making an orchestration tool and a baby is he even qualified?
I have a vibe-coded orchestrator that I use to manage my claude and codex sessions across multiple machines, can also spin up sprites from fly.
https://github.com/tinkerer/propanes
warning: it is probably totally unsuitable for anyone else to use except for me
The main idea is a widget that you embed in your apps that lets you select elements, paste screenshots, and prompt what to change. This workflow is very productive for me. I would encourage everyone to add element selection to their orchestrators prompt composers. If you watch the looms on the readme note that my CLAUDE.MD calls me a Meat Computer and reminds me to hydrate.
I have a native tauri version that lets you select UI elements through the macos accessibility api too.
The session service uses tmux so you can open a native terminal via ssh and tmux attach. I add a ton of features that are in varying degrees of half-baked: the "brainstorm" mode allows you to do microphone transcription while interacting with the DOM and it will suggest tickets automatically. I've also been working on "bd2sdd" which is supposed to take your strings of user inputs and transform it into a spec, presumably because I also desired regressions. There are Wiggums (which aren't relevant anymore with /goal) and "FAFO swarms" (fan-out, aggregate, filter, optimze) which I use to reverse engineer other pieces of software, PowWow for codex and claude to work together.
I stole the structured views and remote session control from my friend's Agent Portal project txcl.io which is more fully-baked and narrower scope than propanes.
The ticketing system / tmux / structured views has been slowly evolving into multi-agent chat with a primary "Chief of Staff." It integrated pretty nicely into Slack.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#20Interesting. Given that OpenAI and Anthropic are steadily moving down the stack (e.g. remote execution, Codex desktop, Claude Code integrations), how do you think about defensibility? Do you expect the labs to eventually offer a cloud-native ADE themselves, and if so, what advantage do you think an independent platform retains? Also, do you see Boxes supporting OpenCode and self-hosted/local models in the future? If…
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 othe…
I have gotten into the habit of keeping the Codex app open on my laptop, and using the ChatGPT app on my phone as a remote. Maybe hosting is the way to go!