Running an AI companion on your own computer can keep a conversation away from a hosted model. That is the draw of Ollama and LM Studio for anyone whose chats read like a diary. Local describes one step, though: the model generating a reply. A working companion also has an app around that model, optional services such as web search or cloud models, and saved history. Each is a separate question, so check which model your session selected and what the features you depend on need to run.
Check where the model runs
Ollama’s FAQ says the company does not see your prompts or data when you run locally. The same page describes cloud models, whose prompts and responses are processed on Ollama’s hosted service under a stated policy of no storage, logging or training. The processing still happens on hosted hardware. The FAQ also documents a local-only setting that disables Ollama’s cloud models and web search after a restart, the first control I would look for.
Bionic, an agent app that LM Studio’s documentation describes as separate from LM Studio, puts a similar choice in its session picker. Its model documentation offers Local, Remote and Cloud. For Remote, it says the chat history stays on the device you are using, but the prompt still travels to the linked device that generates the reply. That device may be your own desktop or a cloud VM: the LM Link page lists local devices, LLM rigs and cloud VMs as targets. The question is who operates the machine that receives the prompt.
| Bionic choice | Where the reply is generated | What to check |
|---|---|---|
| Local | Downloaded model on your device | Selected model |
| Remote | Another device you linked, which can be your own hardware or a cloud VM | Who operates that machine |
| Cloud | The vendor’s servers, under its stated Zero Data Retention policy | Whether hosted processing is acceptable to you |
A network connection is not a chat transcript
A locally installed app can still open connections. LM Studio’s offline documentation says the app can operate entirely offline once you have model files. Chatting with downloaded models, processing local documents and running the local server work without internet. Browsing and downloading models, fetching runtimes and checking for updates are the documented reasons for a connection, and the documentation ties none of them to your conversation. That page describes the LM Studio app itself, not Bionic.
One public thread illustrates the difference between traffic and transmitted content. On October 3, 2025, GitHub user VladimirOsipov opened an issue on LM Studio’s bug tracker because workplace security objected to the app’s internet connections, and asked how to disable update checks. On October 5 they clarified that they wanted to reach a remote server, which needs a connection. On October 8, a reply from yagil pointed to the offline documentation and its list of functions that need connectivity. It is one unverified account that reports a concern and supplies no captured prompt or traffic analysis demonstrating a chat upload.
Your computer still keeps copies
Where a reply is generated says nothing about what the app writes to disk afterwards. SillyTavern, a chat interface that stores each user’s data on the machine running it, shows why. Its user settings page describes a data subfolder for each new user and a Download Backup option that exports all of that user’s data, plus settings snapshots. That is a useful feature, and it also means the history sits in files that a backup job or export can pick up. The page documents exports. It says nothing about encryption or syncing.
Two questions cover most of this. Where does the app keep its history and exports, and who can open those files? Does a backup routine you already run, such as a synced folder or a whole-disk backup, include that location? If it does, the chat you kept off a hosted model already has a second copy. My deletion guide covers what to ask a hosted service about the copies it keeps. With a local setup, you are the one who has to answer.
Try the boundary before moving the conversation
My methodology distinguishes app testing from a security audit. Use this dependency check to see which features need a connection; it cannot establish what happens to every stored copy. Download the model and any runtime first, since those downloads are documented reasons for a connection. Confirm the session is set to a local model. Then, only for an on-device setup, disconnect from the internet and run each feature you intend to use, one at a time: the basic chat, then any document feature, then web search. For a remote setup, keep the connection it needs and check its destination separately.
Read the results narrowly. A feature that works offline shows only that it worked offline in that session. It says nothing about what the app does once you reconnect, or about the copies already on disk. A feature that fails offline is a reason to investigate whether a missing download, a connectivity dependency or another setup problem caused it. It is not evidence that anything was sent. Before moving a personal conversation, try the same setup with a harmless chat and check where the reply was generated and where the history is saved.