Running a coding agent from your phone: three patterns and their tradeoffs

The thing nobody mentions in the demo videos

There's a genre of post going around right now: someone at a pool, or on a train, or three weeks out of town, shipping code to production from their phone while an AI agent does the work. It's real, and it's genuinely a big deal. The laptop stopped being the thing you have to be sitting at.

But every one of those setups is doing the same trick — the agent isn't running on the phone. The phone is a window onto a machine somewhere else that's doing the actual work. There are three ways people wire that up, and they have very different failure modes once the novelty wears off. I've built one of them (I'll disclose which), and I've watched people fight all three, so here's the honest version.

Pattern 1 — On-device (Termux, iSH)

You install a Linux environment on the phone itself — Termux on Android, iSH on iOS — and run the agent's CLI there. No server, no bill, nothing to keep alive between sessions. For small edits and a repo you can compile on-device, it genuinely works, and it's the most "yours" of the three: nothing leaves the phone.

The wall you hit is the operating system. Mobile OSes aggressively kill background processes to save battery — Android's process killer and iOS backgrounding will end a long agent run the moment you switch apps or the screen sleeps. So the exact thing coding agents are good at now — give it a goal and let it loop for 40 minutes, checking its own work — is the thing your phone will interrupt at minute 10. On-device is great for a five-minute fix and frustrating for anything that runs unattended.

Pick it if: you want zero dependencies, you're offline a lot, and your tasks are short.

Pattern 2 — A DIY remote box (VPS or Mac mini + Tailscale + tmux)

This is the setup in most of the "from my phone" threads, and it's a good one. You rent a cheap VPS (or repurpose a Mac mini at home), put it on a Tailscale network so your phone can reach it privately, run the agent inside tmux so the session survives disconnects, and SSH in — or use Claude Code's remote control / Codex's remote — to drive it. The compute lives on a real always-on box, so the loop keeps running when your phone locks. Point a wildcard subdomain at it and the agent can even stand up its own preview URLs.

It's the most capable of the three, and if you enjoy ops it's hard to beat on control and cost. The honest catch is that you now run a server, and a server is a thing that needs tending:

• The box has to stay awake. A Mac mini that sleeps, or a laptop whose lid you close, takes the agent's session down with it — the single most common way these setups die mid-task.
• tmux doesn't survive a reboot. The VPS reboots for a kernel update and your long-running session is gone unless you wired up a systemd unit to bring it back.
• You're the one patching it. Month two is OS updates, expiring certs, and a Tailscale key that rotated. None of that is hard; all of it is on you, forever, for every box.
• A 24/7 box costs 24/7, whether or not an agent is running on it.

None of this is a dealbreaker — plenty of people happily run this stack. But "I built an app from my phone" quietly became "I also administer a Linux server from my phone," and that second job is the part the demo video skips.

Pick it if: you want maximum control, you like infra, and babysitting a box is a fair trade for owning every layer.

Pattern 3 — A hosted persistent agent

Same idea as Pattern 2 — the agent lives server-side, the phone is a control surface — except someone else runs the box. You describe what you want, an agent builds and hosts it on infrastructure you don't administer, and you check in from your phone. The session doesn't die when your phone locks because your phone was never the compute; there's no tmux to reattach, no OS to patch, no lid to keep open. Each project gets its own isolated agent instead of everything sharing one box.

The honest tradeoff runs the other way: you don't own the machine, you're trusting a host with your build environment, and it's less hackable than a box you rent yourself. If your idea of the fun part is the box, this isn't for you.

This is the pattern I build — VibeKit is a hosted persistent agent you drive from a native iOS app or the CLI, with a live domain and an optional database per project. I'm biased, obviously. I built it because I got tired of my agent's session dying every time my Mac mini decided to install an update while I was out. The design goal is narrow: the agent keeps working whether or not any machine of yours is awake. If you bring your own Anthropic or OpenAI key it runs on your key at cost, so "hosted" doesn't have to mean "marked-up tokens."

Pick it if: you want the agent to just keep running and you'd rather not be the sysadmin.

So which one?

There's no universal answer, and anyone selling you one (including me) is flattening a real tradeoff:

• Short tasks, offline, zero setup → on-device (Pattern 1).
• You want to own every layer and you enjoy ops → DIY remote box (Pattern 2). This is genuinely the best setup for a certain kind of person, and that person knows who they are.
• You want it to keep working without becoming your side-job → hosted (Pattern 3).

The mistake is thinking the choice is about where you code from. All three let you code from your phone. The choice is about who patches the box — and that answer doesn't change based on how cool the pool photo is. Decide how much server administration you actually want in your life, and the pattern falls out of that.

If you want to try the hosted version, VibeKit is on the App Store and the web dashboard, with a free tier to test it before you commit a key.