The model runs on your laptop. The interface sends a request somewhere else. The comforting sentence about everything being local has suddenly acquired an asterisk large enough to live in.
This is a systems question, which is probably why it gets less attention than a contest between model families. The visible answer comes from one component. The information may move through several. You cannot describe the entire route by naming the component you like best.
The recent argument about old local models and newer hosted ones concerns a different question, but it illustrates the broader habit: we talk about the model as though the model were the whole experience. It is not. The rest of the application gets a vote.
Here is the fictional setup I use to make the issue ordinary. A person runs a local assistant to help sort personal notes. The application can also retrieve web pages, use an external search service and invoke a document plugin. The local model processes the final text. Before that happens, the surrounding tools may have performed work outside the machine.
That does not prove the application leaks information. It means the word local has not yet described its behavior fully enough to establish the privacy claim.
My notebook page for the surrounding app
I would write the task first. Which material will the user provide? Which external information is genuinely needed? Which optional features are enabled? What does the interface tell the person before a tool receives information?
Then I would describe the path of the data in ordinary nouns and verbs. This component reads the note. That component receives the search query. This other component stores the result. If I cannot explain a step without waving at a reassuring diagram, that step needs more investigation.
I would also look at the abilities the application exposes. OWASP's guidance on excessive agency makes a useful distinction between an assistant's intended task and the wider powers its tools may provide. A local answer does not cancel the consequences of an overly capable plugin.
The interesting test is not whether the interface has a switch with a comforting name. It is whether the configured system behaves as the person reasonably expects. A switch might be helpful. An explanation of what it changes is more helpful. Evidence from a controlled test is better still.
No automatic halo
I prefer local operation for some tasks. That preference does not oblige me to defend every application using the label. Nor does the existence of a questionable configuration make every local system pointless. The useful comparison is between actual arrangements, with their routes and constraints visible.
A hosted system might describe its handling clearly enough for a particular public task. A local system might be a better fit for an offline experiment. Another arrangement might require a feature neither can provide under the needed conditions. The decision gets clearer when the labels stop doing all the work.
I want documentation that tells me where information goes before I supply it. I want optional network features to have comprehensible consequences. I want an application to describe the difference between a local model and a local workflow without making the reader become a network detective.
Running inference at your desk can be a useful part of control. It is not a magical silence spell for the rest of the app. Follow the route, including the boring bits. The boring bits are often where the promise becomes true—or stops being true.
A thought worth keeping?
