There are two ways to put an AI coding agent to work, and the difference between them isn't intelligence — it's plumbing. One runs in your terminal, on your machine, with its hands directly on your files. The other runs in a datacenter somewhere and can't touch your files at all until you build it a bridge. Everything else — speed, cost, safety, how much babysitting you do — flows from that single fact.
We spent a full day living in both this week. Here's the honest breakdown.
The local terminal agent: it already has your files
When the agent runs on your own machine, your project is just there. It reads your code, edits it in place, runs your build, looks at the result, and tries again — all in the same directory you're already working in. No upload step. No sync. No "which copy is the real one."
Where it wins
- Zero file friction. It sees your whole project the instant it starts. No repo to set up, no files to push or pull.
- It works with private and local-only things. Credentials, half-finished notes, a database that only exists on your laptop, files you'd never put in GitHub — the local agent can use all of it without any of it leaving the machine.
- Tight feedback loop. Edit, build, screenshot, fix. The round trip is seconds because nothing is crossing a network.
- It sees context you forget to mention. Config, environment, the other twelve files that matter — it's all right there.
Where it costs you
- It uses your machine and your usage. The work runs on your hardware and your account, so a big job ties up both.
- It's tied to that one machine. Close the laptop and the work stops.
- You're in the room. It moves fast, but you're the one watching it, approving the risky steps, keeping it honest.
- Bigger blast radius. An agent with direct access to your whole filesystem can do real damage if you let it run unchecked. That power is exactly why it's useful, and exactly why you supervise it.
The cloud agent: powerful, but it starts with empty hands
A cloud agent (for example, claude --cloud) runs in a clean, isolated sandbox in the cloud. That isolation is genuinely valuable — but it means the agent begins with no access to your files whatsoever. To get your project to it, and to get the result back, you need a shared drop-off point both sides can reach. In practice that means a git repository, usually a private one on GitHub: you push your project up, the cloud clones it, does the work, and pushes the result back to a branch you then pull down.
Where it wins
- It doesn't tie up your machine. Hand off the job and keep working. The heavy lifting happens elsewhere.
- It runs on cloud credit, not your local resources. For long builds, that's the whole point.
- You can fan out. Multiple cloud sessions can grind on separate jobs in parallel.
- A safer sandbox. It can't wander into the rest of your machine, because it isn't on your machine.
- Great for self-contained builds. A greenfield project that lives entirely in one repo is a clean fit.
Where it costs you
- The bridge is real work. Somebody has to create the repo, push the project, and wire up credentials so the cloud can read and write it. That's setup before any building starts.
- It needs to be connected, not just pointed. A cloud session can't reach a private repo unless your account's GitHub connection is linked and that repo is allowed. Point it at a repo it isn't authenticated to and it simply can't see it — which looks like a mysterious stall until you realize it never had the keys.
- Permissions and round-trips. Non-interactive cloud runs often can't approve their own commands, and every file has to travel up and back. Latency and friction live in that gap.
- It can't touch your private, local-only files. Anything you won't put in a repo, the cloud agent will never see. That's a feature for safety and a limit for work.
The honest verdict: they're not rivals, they're a division of labor
The question isn't "which is better." It's "does this job touch my real machine, or is it self-contained enough to hand off?"
- Reach for the local terminal agent when the work touches your actual files, private data, local services, or anything that benefits from a tight edit-run-look loop. The lack of a file bridge is the whole advantage.
- Reach for the cloud agent when the job is large, self-contained, and can live in a repository — and you'd rather it run elsewhere on cloud credit while you do something else. Just pay the bridge tax up front: a repo, and a connected GitHub so files can move both ways.
The surprising lesson is how much of the difference comes down to one unglamorous thing: who holds the files. The local agent's superpower is that it already has them. The cloud agent's cost is that it has to be handed them, and handed a way to give them back. Decide based on where your files live, and you'll pick right almost every time.