"Local-first" is on every AI coding tool's landing page now, and it means almost nothing until you ask the only question that matters: where does your code actually go? The honest answer is rarely "nowhere" — it's nowhere new. Here is how to tell the difference, and how to check it yourself instead of taking it on faith.
TL;DR — what "local-first" really buys you
A local-first AI coding tool runs on your machine and keeps your prompts, code, and history off any new third-party server. It does not mean your code never goes to a model — the moment you call a hosted model, your prompt reaches that model's provider, and no tool can change that. What local-first changes is whether a second party (the tool's own vendor) is added to the data path. The useful, checkable claim is narrow: "introduces no new data flows and no new vendor." Anything broader is usually marketing, and usually disprovable.
What does "local-first" actually mean for an AI coding tool?
The phrase gets stretched to cover three architectures that have very different security properties. Sorting a tool into the right bucket is the whole job.
- Local-only companion. Runs inside your editor, reads files already on disk, and adds no server to the request path. Your model calls go where they always did — straight to your own provider account. The companion never sees the traffic.
- Vendor relay / proxy. Routes your model calls through the vendor's own servers — for caching, routing, analytics, or policy enforcement. This can be a reasonable design, but it puts the vendor in the path: your prompts transit their infrastructure. "Local-first" is the wrong label for it.
- Hosted agent. The heavy lifting happens in the vendor's cloud; your editor is a thin client. Your code is uploaded by design. Plenty of capable tools work this way — but it is the opposite of local-first, regardless of the badge on the page.
Open-source tools like Aider run as local-only companions you can read end to end. Editor-integrated assistants such as Cursor or GitHub Copilot sit further along the spectrum depending on the feature and the plan — both vendors' own privacy documentation describes optional or default server-side components, so check the settings for your specific plan. The point is not which tool is "best" — it is that the label tells you nothing; the request path tells you everything.
Where does your code actually go?
Map any tool against this table before you trust its privacy page. The rows are the only questions a security reviewer actually asks.
| Question | Local-only companion | Vendor relay | Hosted agent |
|---|---|---|---|
| Do prompts reach the model provider? | Yes (your own account) | Yes (via vendor) | Yes (via vendor) |
| Is the tool's vendor added to the path? | No | Yes | Yes |
| Is code uploaded to the vendor? | No | Transits, may be logged | Yes, by design |
| Does it work offline? | Mostly | No | No |
| New data flow to assess in review? | None | Yes | Yes |
If you only have a minute: the watchdog and rotation extension we ship, Power Claude, sits in the first column — start the 7-day free trial, no credit card, and inspect the network yourself.
What threat model is realistic on a developer machine?
Security copy loves to imply a tool defends you against everything. Be specific instead, because the realistic threats on a single-developer workstation are narrow:
- A second vendor in the path. This is the one local-first genuinely addresses. Fewer parties holding your prompts means fewer breach surfaces, fewer subpoena targets, and a shorter security questionnaire. A tool that never collects something cannot leak it.
- Network exposure of local services. Many tools run a local helper process — a proxy, a language server, a dashboard backend. The question that matters is what interface it binds to. A process bound to the loopback interface (
127.0.0.1) accepts no connection from the network; a process bound to all interfaces (0.0.0.0) is reachable by anything that can route to your machine. The first is the correct default; the second is a finding. - Credentials at rest. Here is the honest part the brochures skip: most AI coding tools, including the official first-party clients, store their access tokens as plaintext on disk with owner-only (
0600) permissions. That is the de-facto norm, not a scandal — on a single-user machine, a process running as you can already read anything you can, so encrypting with a key that same process can also read buys little. OS-keychain-backed storage is the real upgrade, and it is still rare on Linux. Knowing this lets you ask the right question instead of the scary-sounding one.
What local-first does not protect against is malware already running as your user, or your own agreement with the model provider once your prompt arrives. Pretending otherwise is the overstatement that gets privacy pages dunked on. The smallest attack surface is the one that was never built — but only inside the threat model it actually covers.
How do you verify a local-first claim?
A privacy claim is only worth anything if it is falsifiable. Three checks, none of which require trusting the vendor:
- Watch the network. Run the tool behind a local proxy or packet inspector. You should see your own model-provider traffic and, at most, a small periodic license or update check. A stream carrying your prompts or files to the vendor's host is the thing you are looking for; its absence is the claim, confirmed.
- Read the local state. Find where the tool writes its data — usually a dotfolder in your home directory. If the dashboard, history, and analytics all reconstruct from those local files, there is no server-side copy. Delete the folder; if the history is gone for good, it was never uploaded.
- Pull the plug. Disconnect from the network and use the tool. Local-first features keep working from local state. A tool that needed to upload your data to function will fall over immediately, and that tells you where its data actually lives.
Run these once, on any tool, and you will never read a privacy page the same way again. The claims that survive all three are the ones worth anything.
A local-first case study: how the rotation proxy stays on your box
To make the checks concrete, here is one tool audited against them — the VS Code extension we publish. Power Claude rotates between your own Claude accounts when one hits a limit and watches for stalled sessions, all from inside the editor.
- Its rotation proxy is configured to bind to
127.0.0.1only, making it reachable solely by the editor on your machine — not by anything on the network. - There is no Neural-LLM server in the request path. Your prompts go from Claude Code to your own Claude account, exactly as before; the proxy only selects which account.
- Account tokens are stored locally with owner-only file permissions and are not transmitted to Neural-LLM.
- Egress to your Claude account uses certificate-verified HTTPS, with no verification-disabling shortcuts in the code.
- The one outbound call to Neural-LLM is a cached license check. It carries a hashed key, a machine ID, and a timestamp — no prompt text, no code, no credentials. You can verify the payload with the network check above.
Every one of those is checkable with the three steps above. That is the standard to hold any tool to, ours included — see the full data-path walkthrough for the line-by-line version.
Frequently asked questions
Does "local-first" mean my code never leaves my machine?
No. If you use a hosted model, your prompt and any code in it reach that model's provider — that is unavoidable for any tool calling a hosted model. Local-first means the *tool's own vendor* is not added to that path. The accurate claim is "no new data flow," not "nothing ever leaves."Is it a problem that my AI tool stores its token in plaintext?
Usually not, and it is the norm — most clients, including first-party ones, store access tokens as plaintext with owner-only file permissions. On a single-user machine, a process running as you can already read your files, so same-machine encryption with a locally readable key adds little. The meaningful upgrade is OS-keychain-backed storage, which is still uncommon, especially on Linux.How can I tell if an AI coding tool is uploading my code?
Run it behind a packet inspector or local proxy and watch the outbound connections. You should see your model-provider traffic and maybe a small license or telemetry check. Any stream sending file contents or prompts to the vendor's servers is the signal. Disconnecting from the network and seeing which features still work is a fast second check.Does a local-first tool make my project compliant with SOC 2 or PCI?
No. A tool is not a certification, and a local-first design does not change your existing obligations. If the tool adds no new data flow, your compliance posture is unchanged from before you installed it — which is a real, checkable statement, but not a compliance badge.What should I look for in a local helper process an AI tool runs?
Check what network interface it binds to. Bound to `127.0.0.1` (loopback), it is reachable only from your own machine — the correct default. Bound to `0.0.0.0` or a LAN address, it is reachable from the network and worth questioning. `lsof -i` or `ss -tlnp` will show you the bind address in seconds.References
- Anthropic — Claude Code documentation
- OWASP Top 10 — application security risks
- Visual Studio Code — extension security and the extension host model
- Where your code goes when you run Power Claude
Start local, and verify it
The takeaway is the same whatever tool you run: hold the privacy page to the three checks, and trust only what survives them. If you want a rotation-and-resilience extension that is built to be audited rather than taken on trust, the local-only architecture is the place to start. When you are ready, the 14-day Premium Trial at neural-llm.com/pricing is $0 today and locks founder pricing — or install free and the no-card 7-day trial starts the moment you open the extension.
*Power Claude by Neural-LLM — independent, unaffiliated with Anthropic PBC. "Claude" is a trademark of Anthropic.*