A model that runs on your own machine keeps your prompts on your own machine. That is the promise of local AI, and it holds. It says nothing about the software wrapped around the model. Between July and August 2026 we installed seven tools from a working local AI stack on our test machine, read their code, listed every network connection they held and, where we could, captured what they sent. Two of the four tools with reporting code contacted a server without being asked. None of our captures showed a prompt leaving the machine. This page is the index to those investigations: what we tested, how, what we found, and how to run the same checks on the tools you use. For a business deciding which of these tools staff may install, a section below turns each finding into the decision it forces.
Which local AI tools phone home?
Of the seven tools we tested, two report to an outside server by default. OpenJarvis sends one usage event per chat session to a PostHog analytics host, keyed to an anonymous install ID, and flushes it on a 30 second cycle. Its own documentation promises to explain how to opt out and never does. OpenCode opens a connection to its Sentry crash-reporting endpoint at launch, before anything is typed and before a project is open, from a production address compiled into the shipped app. Sentry’s own list of what its SDK collects runs to stack traces, OS and runtime versions, and the IP address of the request. It ships 41 disable flags. None of them turns that off.
Update, 19 October 2026: OpenJarvis has since merged a change, on 14 October, that makes its analytics opt-in. The finding above describes the version we tested in July.
The other tools tell a quieter story. LM Studio opened no outbound connection at rest: six processes, three sockets, all on localhost. What it does do, by default, is route model search and download through its own proxy, so its operator sees which models you look for. The Hugging Face library under most model downloads carries a 125-line telemetry module that nothing in the library calls, and reports your Python and PyTorch versions in a header on every request instead. Hugging Face documents an HF_HUB_DISABLE_TELEMETRY variable; it governs the function nothing calls, not the header. Graphify, the tool we trusted least going in, opened no connection beyond the local model server across 358 socket samples.
The count that matters is not two of seven. It is that in every capture we made, the payload held counters, timings and hashed names, never a prompt. Where we did not capture a payload, as with OpenCode, we say the finding is open.
How do we test whether an AI tool sends data?
Every finding on this desk comes from one of three kinds of evidence, and each article says which. The strongest is a capture: we point the tool’s reporting host at a listener on our own machine, run one fixed task with reporting on and then off, and compare what arrives. That is how we found the single OpenJarvis event, and how we confirmed that enabled = false under an [analytics] heading in its config file stops it, a switch its documentation never names.
The second kind is a socket listing. We launch the tool, do nothing, and list the connections its processes hold. Anything bound to 127.0.0.1 is talking to the machine it runs on. An established connection to an outside address is a question, and we resolve the address to see whose it is. The third kind is reading the shipped code, as we did when we read the whole of Graphify before installing it and listed all eight addresses hard-coded in its source.
The method depends as much on what it rules out. Fifteen hits for “amplitude” in OpenCode’s bundle were an SVG filter attribute. More than 150 references to OpenTelemetry had no exporter and no collector address. A Chrome-named crash handler in three apps had no upload address. A crash reporter in a bundle proves nothing on its own; what counts is the destination it would send to. Every retest that changed a finding is recorded in the article it changed, because a report that shows how a finding was reached can be checked rather than believed.
What did the telemetry investigations find, tool by tool?
The desk has published eleven pieces on this question so far. The list below runs in the order the work happened, with the finding each one established.
- OpenCode vs OpenJarvis: which local AI agent phones home? The first A/B capture. OpenJarvis sends one event per session and has an undocumented off switch; OpenCode has a Sentry address compiled in and no switch at all.
- OpenJarvis on a Mac, retested. The desktop build, the background model downloads nobody asked for, and the port conflict that made the app look broken.
- Reading Graphify’s source before installing it. Zero hits for telemetry, tracking or usage statistics; eight hard-coded addresses, six of them model providers you would have to choose.
- Running Graphify on a local model while watching every socket. 358 samples, LM Studio every time.
- How AI companies hide tracking code. The case of Claude Code, where a check on the user’s server and timezone was encoded into the date line of every prompt, found by a reader of the code in a public issue filed on 10 June 2026, and acknowledged by an engineer on the Claude Code team on 30 June.
- LM Studio’s model proxy. No telemetry settings, no outbound connection at rest, and a default route for model search through LM Studio’s own servers.
- OpenCode’s Sentry connection at launch. Two outbound connections before any input, the Breadcrumbs integration deliberately stripped, and 41 flags that do not reach it.
- Crash reporters in local AI apps. Three apps, one Electron handler, no upload address.
- The identifiers local AI tools write to disk. Visual Studio Code writes three, OpenCode one, and OpenJarvis keys each event to an anonymous install ID our capture confirmed.
- What the Hugging Face library reports. A telemetry function nothing calls, and a user agent that names your Python and PyTorch versions on every request, with no switch.
- AI privacy and data control. The rules we apply to every tool before it joins our own stack.
Two patterns run through the list. The first is that the alarming names were poor evidence and the ordinary plumbing was where the data went: a user agent header, a model search proxy, a session envelope. The second is that off switches are missing, hidden or pointed at the wrong thing. OpenJarvis has a switch its documentation never names. OpenCode has none. The Hugging Face library documents a switch for a function that is never called.
How can a business use the AI telemetry investigations to approve local AI tools?
Each finding above maps to a choice an IT or security team can make on the day it approves a tool. These are conditions, not quality verdicts: the settings under which each tool behaved the way our captures and socket listings showed.
OpenJarvis can be approved with a configuration line. Setting enabled = false under [analytics] in its config file stopped the one usage event per session in our capture. Ship that line with the install, and redirect the installer’s own analytics call, which has no off switch.
OpenCode cannot be quietened from inside the app. Its crash reporter connects at launch, and none of its 41 disable flags reaches it. The choices are to accept that connection or block the Sentry host at the network. We have not captured that payload, so a cautious team treats the finding as open.
LM Studio opened nothing outbound at rest, but model search goes through its own proxy by default, so its operator sees which models staff look for. Decide whether those search terms matter to you. For the Hugging Face library, expect Python and PyTorch versions in a header on every download request; the documented telemetry variable does not change that.
Graphify, pointed at a local model server, stayed on the machine across 358 socket samples. Approve the exact package name and the local backend together.
This page is the index. For a procurement file, the Local AI Telemetry Report 2026 is the document to attach: it gathers these findings into one dataset with an evidence grade on each, and it records the version tested every time.
How do you check your own AI tools for telemetry?
Four of the five checks we use need nothing beyond what ships with the operating system. Open the tool and do nothing, then list the connections its processes hold; on macOS, lsof -nP -iTCP -a -p <pid> does this for one process. Read the settings file for keys named for analytics, telemetry, usage, proxy or mirror, and check whether an access token is stored, because a token turns an anonymous request into an attributed one. Search the bundle for a destination, a DSN or a collector URL or a hard-coded host, rather than for the name of a library. Filter identifier-shaped values by where they live: a value inside a compiled binary is a build constant, many values that grow with use are session IDs, and one small value created at install and never changed is a machine identifier.
The fifth check is the capture, and it is the only one that shows the bytes. If a tool lets you set its reporting host, point it at a listener on your own machine and run the same task with the setting on and off. Where a tool does not expose that setting, as OpenCode does not, the honest result is an open finding, not a clean one. Proving your data never leaves is a method, and the method has limits we state each time: a socket listing is a snapshot, we did not induce a crash in any tool, and every test ran on one Mac on the version installed that day.
These eleven pieces are the basis of the first Stridenalysis report, the Local AI Telemetry Report 2026, which gathers them into one dataset with an evidence grade on every finding. It will publish once the next round of tests is complete: sixteen agents that can run a local model, each put through the same captures, with the version recorded every time. A tool that is not on this page has not been cleared. It has not been tested yet.
