Local-first AI: why your code should never leave your box
Most AI coding tools ship your source to someone else's cloud. Local-first flips that — agents run on hardware you control, with zero telemetry. Here's why that's the only safe default.
There’s a quiet assumption baked into almost every AI coding tool you can buy: that your code is going to leave your machine. It gets indexed in a cloud. It rides along to a hosted agent. It sits in a vendor’s sandbox while a model rewrites it. You clicked “agree,” so it’s fine — right?
We don’t think it’s fine. We think local-first is the only sane default for AI that touches your source code.
What “local-first” actually means
Local-first isn’t a marketing word for “we have a desktop app.” A tool can be a desktop app and still beam your repository to a remote indexer, route your prompts through a cloud agent, and phone home with telemetry on every keystroke.
Local-first means something specific and testable:
- Your code stays on your box. The source, the git history, the knowledge vault — they live on hardware you control. Not ours.
- Agents execute where the data is. When you spawn an agent, it runs against the files on your disk, in an isolated git worktree, on your machine or your own cloud — not in a rented sandbox you can’t inspect.
- Zero telemetry. No usage beacons, no “anonymized” code snippets, no analytics SDK reading your editor. Nothing leaves the box unless you point it somewhere.
That last point is the one most tools fail. “We don’t train on your data” is not the same promise as “your data never leaves.” The first is a policy. The second is an architecture.
Why it matters more now, not less
It was easy to wave this away when AI tooling meant autocomplete. A few tokens of context, server-side, who cares.
Agents changed the stakes. An agent doesn’t see a snippet — it reads your whole tree, runs your build, touches your secrets, and writes back changes. Multiply that by a fleet of agents working in parallel, and “where does the code go” stops being a privacy footnote and becomes the central design question.
For a lot of teams it’s not even optional:
- Regulated work — health, finance, defense — where source leaving the building is a compliance violation, full stop.
- Pre-release IP — the unannounced product, the proprietary model, the algorithm that is the company.
- Client code under NDA — where you contractually cannot put someone else’s source in a third-party cloud.
- Air-gapped environments — where there is no cloud to send to, by design.
A cloud-coupled tool can’t serve any of these honestly. A local-first one serves all of them without a special enterprise SKU.
“But the cloud is convenient”
It is. And local-first doesn’t mean giving that up — it means you decide the boundary, instead of the boundary being decided for you.
You can run a local model and never touch a network. You can bring your own API keys and let agents call a hosted model for inference while the code stays put. You can fan work out across your own mesh of machines. The point isn’t to ban the cloud; it’s that your source code is not the thing being shipped to it. Inference is a service you rent. Your codebase is not.
How Tandem does it
Tandem is local-first by default. You spawn agents, they work in isolated worktrees on your hardware, and you review and merge everything from one inbox — all on a box you control. It can run fully air-gapped. There’s no telemetry to turn off, because there’s none to begin with.
That’s also why there’s no free tier: you pay for the app, not for token markup or per-seat surveillance. The business model doesn’t depend on watching you work, so it doesn’t.
Your code never leaves your box. That’s not a feature we added. It’s the foundation we started from.
Want the head-to-head detail? See how this plays out against cloud-hosted agents and cloud-coupled IDEs.