Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud (boxes.dev)
We’re two engineers who previously built Gem (co-founder/CTO and first hire), and we spent the last year coding almost exclusively using Codex and Claude Code. It’s been a huge change to how we code, and it’s been exhilarating seeing the models keep getting better – but we eventually realized that developing on localhost was holding us back:
- Git worktrees are clunky to set up and use for parallelizing work - It’s 2026, but somehow everyone is still walking around with laptops cracked open or SSHing into mac minis in their garage so their agents don’t stop working. - Mobile is treated like an afterthought even though coding is just texting now We started hitting resource constraints when multiple parallel agents test their own work by running the full app locally. - We tried different products, but couldn’t find any that solved all of our pain points – so we pivoted and decided to just build the ADE we wanted for ourselves.
Boxes.dev is a desktop and mobile app that lets you run Claude Code, Codex (using your subscription!), and the full dev environment for whatever you’re building, all on remote compute. It’s similar to Conductor or the Codex desktop app, except everything is in the cloud.
We use coding agents to scan your local dev setup and port it to the cloud. Then every Claude Code/Codex thread starts from a snapshot of the full setup, with its own filesystem and compute. No more git worktrees, no more cracked-open laptops, and your coding agents can actually test their work end-to-end because they can run your full app in isolation.
We’ve mirrored the Claude Code and Codex UX to feel natural to power users, and also have a fully-featured mobile app (no handoffs or remote control), plus scheduled automations and a Slack integration.
We’re obviously biased, but we’ve been building boxes.dev with boxes.dev for months and it’s honestly been a gamechanger. It’s hard to go back once you realize how much localhost has been limiting you; based on early feedback from beta testers, we’re increasingly sure that cloud is the future of agentic coding.
We’d love for you to experience it yourselves! Would appreciate any feedback – and happy to answer any questions on this thread.
43 comments
[ 3.2 ms ] story [ 67.4 ms ] threadAlso, do you see Boxes supporting OpenCode and self-hosted/local models in the future? If the rented machines have enough RAM and GPU access, it seems like there could be an interesting path toward a model-agnostic platform rather than being tied to the frontier labs.
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.
Right now, we use:
- Kimi K2.5 for easy fixes, asking about the code, various agentic commands (e.g., summarizing Loom videos for Slack messages)
- Opus 4.8, Sonnet, or Kimi for planning (we find GPT-5.5 to have too terse outputs for plans)
- Kimi K2.5, Composer 2.5, GPT-5.4 mini, etc. for faster implementation (i.e. we don't have to wait around for the slower tokens-per-second generation on Sonnet, etc.)
If we had to only use Opus, Sonnet, and Haiku, I'd definitely be looking to switch harnesses
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.
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).
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?
I’ve been working on an [OSS TUI](https://github.com/prettysmartdev/awman) for managing agent execution and workflows in containers (local or remotely) and would love to collaborate if you’re interested.
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
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.
Why would I want this and not the other way around?
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.
- slow and outdated vms
- horrible/no way to standardize environments for my team
- no way to bring our own compute to help resolve these issues ^
I am building a self-hosted tool (OpenClaw-like) to solve the same problem (running agents 24/7 and access from monile), which I think is the main alterative approach to cloud tools. I'm glad that other people have recognized the problem.
We currently use worktrees btw. We have a port allocation system that sends ports to the agent automatically, which suffices for smoke testing web projects in parallel but requires some configuration. We've also found that asking agents to find a free port works as well. There's no way to get security-relevant isolation without a containerized system, but everything else can be worked around, and IMO more easily than the setup required to make a project ready for VM/container development.
- I run hermes on the box and it has some scheduled cron jobs.
- I gave it an account on a custom Git forge. It cannot commit without my direct permission, though it can blow the setup up in other ways lol.
- I interact by assigning it issues and talking through Discord.
edit: and if anyone knows of an existing service that has these properties, I'd love to know about it.
Last time I tried to let AI build such extension, it told me that VSCode did not expose extension API to monitor AI chat.
I think when you say “ditch localhost” you’re telling me to ditch my fast, instant-response laptop which I own and can peg the CPU of 24/7 for $0, in favour of a tiny cloud VM that I rent forever.
Your infra to run agents and builds for me is compared in my mind to a shell script an agent wrote a year ago and I reviewed once, that fires up my dev server and a local psql (5-10mb ram) on a dynamically allocated port hashed off the name of my current worktree, which it does so it doesn’t clash with other parallel work.
When the internet slows or dies I rarely notice.
As a cost conscious person who likes it when letters appear as I type, I think I might not be your ICP.
Am I being an asshole? Maybe. Am I going out of my way to tell you what goes on in the minds of people like me when we see offerings like this? Also maybe.
1) full isolation (filesystem + compute per thread) 2) agents having a working dev environment that runs our app 3) being able to close our laptops and check in from mobile
The combo of these meant we could fire and forget lot of parallel threads like "root cause and fix this bug: add logging, run app, get a repro, write fix, validate live" or "build this feature, test new workflows live, send screenshots" -- and then come back later to review & iterate.
You can get to a reasonable level of this with locally with git worktrees and the right project setup, but in the cloud you can really fly.