What actually happens to your code when you send it to a cloud LLM

Short answer: when a coding agent calls a cloud model, the file contents it decided were relevant leave your machine over TLS, land in the provider's inference infrastructure, get tokenised, generate a response, and then sit in some logging or abuse-monitoring store for a retention window defined by that provider's terms. Major API providers state that business and API traffic is not used to train their models by default, and most offer a zero-retention arrangement for customers who ask and qualify. The consumer chat products are a different contract from the developer APIs, and the coding agents you install sit on the API side.

The part developers usually get wrong is not the provider's policy. It is the scope of what got sent. You think you shared one function. The agent shared that function, three files it grepped on the way there, your directory tree, the top of a .env it read while looking for config, and the last forty turns of conversation replayed on every subsequent call. The privacy question that actually matters is what your agent selected, not what the provider promised.

The path a single request takes

A coding agent is a loop. It reads, it calls a model, the model asks for a tool call, the agent runs it locally, the result goes back up. Each step is an HTTPS POST with a JSON body. That body contains a system prompt, your messages, tool definitions, and the accumulated transcript so far. Nothing about it is exotic. You could reproduce it with curl.

Two consequences fall out of that shape. First, the transcript is resent every turn, so a file you pasted once travels over the wire on every call for the rest of the session. Second, the tool results are part of the transcript, which means the output of every command the agent ran is now model input. If it ran a test suite that printed a connection string in a stack trace, that string is in the payload.

On the provider side the request hits inference and, separately, a logging path. Retention windows for that logging path are documented per provider and per plan, and they exist for abuse monitoring and support. Some providers offer a contractual zero-retention mode. If you need one, read the current terms for your specific account tier rather than a blog post, including this one, because these documents change and the version you read a year ago is not the version you agreed to.

What a no-training promise does and does not cover

A no-training commitment is narrow and worth understanding precisely. It says your inputs will not be used as gradient signal for a future model. It does not say your inputs are never written to disk, never reviewed by a human under an abuse investigation, never held by a subprocessor, and never subject to legal process. Those are separate questions with separate answers, and providers publish them separately: subprocessor lists, retention pages, trust centres, security whitepapers.

The distinction that catches people out is product surface. The same company can run a consumer chat app whose terms allow training on conversations by default and a developer API whose terms do not. Coding agents authenticated through a consumer subscription rather than an API key are worth checking carefully, because the plan you signed up for determines the terms, not the tool you are running.

The things your agent sends that you never chose to send

• Files pulled in by search. The agent greps for a symbol, finds it in four places, reads all four, and now all four are in context whether or not they were relevant.
• Command output. Test failures, build logs, git log, env dumps, anything a shell tool printed becomes part of the next request body.
• The directory listing. File and folder names alone can describe an unreleased product, a client name, or an acquisition codename.
• Secrets that happen to live in files the agent read. Most agents have some ignore handling, and none of it is a guarantee. A key hardcoded in a test fixture will not be flagged by a .gitignore rule.
• The full conversation, repeatedly. Once something enters the transcript it is transmitted again on every following turn until you clear or compact the session.
• Retries. A failed call that gets retried sends the same payload a second and third time, which matters if you are counting egress events rather than tokens.

None of that is misbehaviour by the agent. Reading widely is how it produces useful answers. But the mental model of deliberately sharing a snippet is wrong, and the correct model is that your working directory is being sampled by a process whose selection logic you cannot see from inside the CLI.

How to verify rather than trust

• Read the terms for the exact plan and product you are on, not the company's general privacy page. Note the retention window and whether zero retention is available to you.
• Check the subprocessor list. If the model is served through a cloud marketplace, the hosting party may differ from the model vendor.
• Inspect your own traffic. Point the agent at a local proxy with a trusted certificate and read the request bodies. This is the only step that tells you the truth about your own repo instead of someone's policy about repos in general.
• Decide per repo, not globally. A public side project and a codebase under an NDA do not need the same answer.
• Run the sensitive work against a model on your own hardware. Local models are worse than frontier models at hard reasoning, and for renaming, docstrings, boilerplate, and small refactors the gap is often small enough to not matter.
• Track what actually left. Retrospective proof is more useful than a policy you hope was honoured.

Where Probe0 fits

I built Probe0 because I wanted the third and sixth items on that list to be one install instead of a weekend project. It is a proxy that runs on your machine. There is no Probe0 server, so nothing about your traffic reaches me. Setup is the local proxy plus a certificate installed once, after which every coding agent CLI on the machine routes through it: Claude Code, Codex, Cursor, with no per-tool configuration.

Two of the modules are directly about this problem. Local Routing sends work to a model already running in Ollama or LM Studio, and if the answer comes back weak it retries on the cloud, so you get local-first handling without a session that dies on the hard questions. Recording keeps a full ledger of every request: model, tokens, real cost, latency, and which process made the call. That ledger is what turns a suspicion into a fact when you want to know whether a particular repo's traffic went where you assumed.

The caching modules matter here for a smaller reason. Exact Cache lives on local disk and never touches the network, and Semantic Cache uses a local vector index with a strict similarity floor. It refuses to match anything carrying tool calls, because a wrong hit in the middle of an agent run corrupts the run. A cache hit is a request that never left the machine at all, which is a privacy improvement that also happens to be free.

Honest limits: macOS only, private beta, and this is a single-developer tool rather than a team gateway. If you need a shared deployment with policy enforcement across an org, a hosted or self-hosted gateway is the right shape and Probe0 is not. Provider coverage is what coding agents actually call rather than a broad catalogue. Sign-in is Google or GitHub, and the account system is new.

The provider's policy governs what happens after the request arrives. Only you can govern what goes into it.

If you take one thing from this: spend an hour reading your own agent's outbound request bodies on a repo you care about. It is the least glamorous thing on the list and it will change how you configure the tool more than any terms of service ever will.