A privacy claim you can grep

Every coding assistant has a privacy page. Most of them describe a policy: what the vendor stores, for how long, who may read it, whether it is used for training. A policy can be perfectly sincere and you still cannot check it. You were not in the room.

The argument for local inference is not that policies are lies. It is that a policy is the wrong kind of object. This post is an opinion about what the right kind looks like, using twinny’s own source as the example, and about where the argument stops working.

Policy and architecture

“We do not retain your prompts” is a statement about behaviour on a machine you do not own. It can change with a terms update, an acquisition or a bug, and the only evidence you will ever have is the statement itself.

“The prompt went to localhost” is a statement about a socket on a machine you do own. It can be checked with a packet capture, a firewall rule, or by unplugging the network cable and seeing what still works. With a local server, everything in twinny still works, including the workspace index and its reranker.

That is the whole case. Privacy by architecture is not stronger because the people behind it are nicer. It is stronger because it does not depend on them.

What the extension can reach

twinny’s documentation says the extension has no account, no telemetry and no server of its own, and that it makes no requests to twinny.dev or anywhere else on its own. That is a claim about code, so it can be read rather than believed.

Search src/extension for fetch( and there are four call sites:

• Three are in src/extension/inference/adapters/: the streaming POST that carries a completion, the embeddings POST, and the GET that lists a server’s models. The URL in each is built from the provider you configured.
• One is in src/extension/review/service.ts, and it goes to api.github.com. It runs when you ask for a pull request review, and sends the repository owner, its name, the pull number and your token, if you set one.

Chat goes through a client library that is handed the provider’s base URL, or the vendor’s API when the provider is a hosted one. Devices use a DHT and a direct encrypted stream between two of your own machines; the DHT learns that a key is reachable at an address and never carries the traffic. Connecting to a team gateway talks to the gateway URL you typed.

The only mentions of twinny.dev in the extension and its shared code are two constants holding links to the website. Links get opened by a person. They are not requests the extension makes.

The parts that could have needed a download were built so they do not. The reranker behind @workspace is an ONNX file that ships inside the extension, next to its tokenizer, and runs in worker threads in the extension host. There is no first-run fetch of a model from somewhere.

None of this needs to be taken on trust, which is the point. The extension is MIT licensed and the repository is public. An afternoon with grep is a better audit than any paragraph on a website, including this one.

Where it stops being true

Local inference is not a property of the extension. It is a property of your configuration, and twinny lets you configure your way out of it.

Add a hosted provider and everything in the request goes to that vendor: the prompt, the attached files, the @workspace results, the review diffs. The documentation is blunt about this: do not use a hosted provider for code you may not share. A hosted embeddings provider means the chunks of your repository are sent to be embedded. The extension still sends nothing to anyone else, but “anyone else” is now a short list rather than an empty one, and you are back to reading a policy.

The mixed setup the docs describe, a small local model for completion and a bigger hosted one for chat, is a reasonable trade. It is still a trade. Completion sees the code around your cursor on every pause; chat sees what you attach. Deciding which of those may leave is your call, per job, and twinny keeps the providers for each job independent so that the decision is possible.

Two mechanisms narrow the damage when something does leave. The secret shield replaces API keys, tokens, private keys and passwords with placeholders before the request is sent, and puts them back in the reply. With the default, offMachine, it covers hosted APIs, gateways, paired devices and servers elsewhere on the network. It catches credentials. It does not make proprietary code less proprietary.

The second is the log. Every request is written to the Twinny output channel with the provider and model, and at Debug level with the full prompt, cut to 8,000 characters. API keys and bearer tokens are redacted before anything is written. If you want to know what left the machine, the answer is on your machine.

A team gateway moves the boundary rather than removing it. Prompts go to the gateway and its backend, on the team’s hardware. The gateway records which model was used, how long it took and token counts, and keeps request content only if the team has switched recording on, in which case the connect screen says so. Your code has left your laptop. It has not left the building.

What it costs

The honest counterweight is quality. A hosted model has a higher ceiling than anything that fits in 8 GB of VRAM, and the docs say so in the same table that says where your code goes. Local inference is a trade of ceiling for control, and for narrow jobs such as completing the next few lines the trade is cheap, because the job is small. For a long review of unfamiliar code it may not be.

What matters is that the trade is yours to make and visible when made. A tool that sends your code somewhere by default, with a setting to reduce it, asks you to trust the setting. A tool that sends it nowhere until you type an address asks you to trust only what you typed.

The full table of what is sent and to whom is under Status bar, logs and privacy at docs.twinny.dev.