How to keep proprietary code off cloud LLM servers entirely

The direct answer: run the model locally (Ollama or LM Studio), or route requests through a proxy that lives on your machine and only sends text out when you've explicitly allowed it. Anything that requires a hosted gateway between your editor and the model means your code crosses a network boundary you don't control, even if the vendor promises not to log it. If the requirement is genuinely zero exposure, the proxy has to be the thing sitting on your laptop, not a server somewhere with your API key in it.

This matters more for coding agents than for chat. A chat session is a few sentences. An agent working through your codebase is pasting whole files, diffs, stack traces, and sometimes entire directory trees into every request. If you work under an NDA, in fintech, in health data, or just don't want a third party holding a running transcript of your unreleased product, the volume of code in flight is the actual risk, not the occasional prompt.

Why 'the vendor doesn't train on my data' isn't the same as 'my code never left'

Anthropic, OpenAI, and most serious providers now offer no-training commitments for API traffic. That's a real and useful guarantee, and it solves one specific problem: your code won't end up baked into a future model's weights. It does not solve a different problem, which is that the request still transited a network, still sat in a provider's logs for some retention window, still passed through whatever infrastructure sits between you and their inference cluster, and still exists as a data processing event you'd have to disclose under most contractual or regulatory data-handling clauses. If the requirement is 'this code cannot leave the machine,' a no-training clause doesn't get you there. Only not sending it does.

The three real architectures

There are basically three ways people solve this, and they trade off differently.

• Local inference only, no cloud fallback: Ollama or LM Studio running an open-weight model on your machine, agent pointed straight at the local endpoint. Complete privacy, but you're capped at whatever a 14B-70B model running on consumer hardware can do, and for anything requiring real reasoning depth on a large context, that gap shows up fast — a local model missing a subtle bug or refactor that a frontier model would have caught.
• Hosted gateway with a no-training agreement: LiteLLM Proxy, Portkey, OpenRouter, or similar sitting between your CLI and the provider APIs. Great for teams needing centralized key management, budgets, and observability across many developers. Your code still transits their infrastructure on every call, even when self-hosted, because most of these are designed to run as a shared network service, not a single-developer local process.
• Local proxy with selective local-first routing: a process on your own machine that intercepts every coding-agent call, tries local inference or a cache first, and only reaches the cloud when a task genuinely needs it — with you deciding what's allowed to leave.

The third option is the one that actually answers the search-intent question here: keep code off cloud servers entirely, for the requests that can be handled locally, while still letting you use a frontier model when the task demands it. It's a routing decision, not a blanket ban, because a blanket ban on cloud models makes agentic coding noticeably worse at anything nontrivial.

What actually has to happen on your machine

A working local-first setup needs four things, and it's worth being specific because vague promises ('privacy-first,' 'secure by design') are exactly what to be suspicious of in this space:

• A single interception point in front of every CLI you use, not one integration per tool. If Claude Code goes through a proxy but Cursor doesn't, you've solved a third of the problem.
• A real decision at request time: is a local model already running and likely good enough, or does this need the cloud. Quality has to be checked, not assumed — a local model producing a wrong or incomplete answer and silently shipping it is worse than just using the cloud model.
• Caching that never crosses the network for a repeat request. An exact-match cache on local disk means the second identical call costs nothing and touches nothing outside the machine.
• A visible boundary you can audit — a ledger of what actually got sent out, to what provider, and why — because 'we don't send your code anywhere' is a claim you should be able to verify, not just trust.

Where the local-only approach breaks

I'll say the quiet part: pure local inference is not a free win. A 14B or 32B model on a MacBook is going to lose to Claude or GPT on multi-file reasoning, on long-context understanding of an unfamiliar codebase, and on anything that requires genuinely reading and holding a lot of context at once. If your threat model is 'nothing about this repo can ever leave this laptop, full stop,' local-only is the correct and only answer, and you should accept the quality tradeoff as the cost of that guarantee. If your threat model is 'minimize what leaves, but I still need frontier-quality output for the hard 20% of tasks,' a router that defaults local and escalates to cloud only when needed is the more honest fit for how the work actually happens.

A no-training agreement tells you what happens to your data after it arrives. It says nothing about whether it should have been sent at all.

Where Probe0 fits

I built Probe0 for exactly the local-first case above. It's a proxy that runs on your Mac — there's no Probe0 server, nothing of yours passes through infrastructure I operate. Install a local certificate once and every coding agent CLI on the machine (Claude Code, Codex, Cursor) routes through it automatically, no per-tool config.

The Local Routing module sends work to a model already running in Ollama or LM Studio first, and retries on the cloud automatically if the local answer looks weak, so you're not stuck accepting a worse result just to stay local. The Exact Cache lives on local disk and never touches the network on a hit. The Semantic Cache also runs locally against a vector index with a strict similarity floor, and it deliberately refuses to match anything carrying tool calls, because a near-miss on a tool-calling turn can quietly corrupt an agent run — better to pay for a fresh call than get a wrong cache hit. Recording keeps a full local ledger of every request, so 'what actually left the machine and where did it go' is a question you can answer, not a claim you have to take on faith.

It's honest about its limits: macOS only, private beta right now, and it's built for a single developer's machine, not a team gateway with shared keys and per-seat budgets — if you need that, a hosted proxy like LiteLLM or Portkey is the better fit, and I'd rather say that plainly than pretend Probe0 does everything.

If the actual requirement is 'nothing about our source leaves this laptop unless I explicitly allow it,' that's an architecture decision, not a settings toggle in whatever cloud gateway you're already using. It has to run locally, intercept before the request leaves, and give you a way to check what happened after the fact.