Why your AI coding agents should run on your own machines
AI coding agents are getting genuinely useful, and the natural next question is *where should they run?* A lot of tools answer that by pulling your repository up into their cloud, spinning up a sandbox on their infrastructure, and running the agent there. It's convenient. It's also the wrong trade for most developers, and it quietly gives up the two things that matter most: control of your code and control of your costs.
There's a better default: run AI coding agents on your own machines, and use a thin coordinator to fly them. That's the model dev-mux is built around.
The problem with "send us your repo"
When an agent runs in someone else's cloud, three things happen whether you think about them or not:
- Your source code is copied onto their servers. Now there's a second place your
code lives — one you don't control, can't audit, and have to trust.
- Your secrets and model keys travel too. Agents need environment access. In a
hosted sandbox, that access lives on the host's infrastructure.
- **You pay their margin on compute *and* inference.** The host runs the workload and
often brokers the model calls, so their bill has your execution baked in.
For a solo developer or a small team, that's a lot of trust and a lot of markup for convenience you could have without either.
The alternative: agents on your machines, coordinated by a thin hub
dev-mux is mission control for your AI coding agents. The agents run where your code already is — on your own machines (a laptop, a workstation, a cloud VM you own, a Raspberry Pi, whatever you've got). A small per-tenant coordinator VM — the hub — maintains persistent terminal sessions to those machines and gives you one pane of glass over the whole fleet, live in a web cockpit.
The hub is a relay, not a host. It coordinates terminal sessions; it does not run your workloads and it does not custody your code or secrets at rest. Your code never leaves your machines.
The zero-code moat — and why it's honest
This is the structural heart of dev-mux, so it's worth being precise about it.
- Agents run on your compute. Execution happens on machines you own.
- Inference runs on your API keys. Model calls are yours, billed to you, at your
provider's price — no middleman markup.
- Your code is never stored on our servers. The hub persists no repositories and
no transcripts.
Here's the honest boundary, because over-claiming would be worse than the truth: live terminal content *transits* the hub's memory while you're connected (that's how a relay works), and an optional screenshot feature can capture images that include code if you turn it on. That's transit and opt-in capture — not a copy of your codebase sitting at rest on our infrastructure. We say "never stored," not "never touches," and we mean exactly that.
Why this is a moat, not a slogan
The trust story and the price are the *same fact* stated twice. Because dev-mux pays for neither your execution nor your inference, our cost to serve you is one small coordinator VM. There's no hosted-compute markup to pass along, and there's no pile of customer code on our servers to leak or subpoena. Zero of your code on our servers is both the security model and the margin model — which is why it's durable rather than a tagline.
What you actually get
- Fleet, not a single session. One console over every agent, repo, and machine you
run — not one-repo-at-a-time.
- Sessions that come right back. dev-mux gives you tmux-backed sessions with
automatic reconnect: close the lid on the train, reopen at your desk, and your work is where you left it.
- Your surfaces. A live web cockpit today, with a phone app and HUD glasses coming.
Your entire dev environment, anywhere.
The takeaway
If you're going to lean on AI coding agents, the safest and cheapest place for them to run is the place your code already lives: your own machines. dev-mux lets you keep them there and still fly the whole fleet from one console — with none of your code stored on our servers.
---
*Want the honest, mechanism-level details on connectivity and durability? See the companion post on durable AI agent sessions.*