A model that runs on your own laptop cannot send your prompts anywhere. The software wrapped around it can, and two of the seven tools we tested did, before anyone had typed a word.
The Local AI Telemetry Report 2026 is the first report from Stridenalysis, the research desk of StrideNote. It gathers eleven investigations we published between June and August 2026 into one question: what does a local AI tool send from the machine it runs on? Seven tools from a working local AI stack went through the same inspection on one test machine, an Apple M4 Pro with 48 GB of memory. We read their code, listed every network connection they held and, where we could, captured what they sent. Every finding carries an evidence grade, and the dataset behind every chart is published with the report.
The PDF is free. Enter your email in the download box and it opens straight away.
What the local AI telemetry report found
Four of the 13 findings in the dataset show data sent to a reporting service without the user asking. None of our captures showed a prompt or a file leaving the machine.
OpenJarvis, the personal agent framework from Stanford, ships with analytics switched on. During use it sends one event per chat session to a PostHog host, with turn counts, token counts, latency figures, a hashed model name and an anonymous install ID. We redirected that host to a listener on our own machine and captured the one request byte for byte. It held no message content. The switch that turns it off, an [analytics] heading in the config file, works. The project’s own documentation never names it. The full test is in our OpenJarvis retest.
OpenCode, the desktop coding agent, opens a connection to its Sentry crash-reporting endpoint at launch, before any input and with no project open. The address is compiled into the app. It ships 41 OPENCODE_DISABLE_* flags, and none of them controls that connection. We did not capture a payload, and the report says so in the same sentence as the claim. The socket listing and the bundle reading are in OpenCode contacts Sentry before you type anything.
The data trail that matters is often ordinary. LM Studio holds no telemetry settings and opened no outbound connection at rest, but on a default install it routes every model search and download through its own proxy, which then sees what you look for and the address doing the looking. The Hugging Face library that sits under most model downloads adds your Python and PyTorch versions to a header on every request, with no switch for the header itself. Both are disclosed, and both create a record of what you are building.
Alarming names made poor evidence. Fifteen hits for “amplitude” in OpenCode were an SVG attribute. Three Electron apps carry Chromium’s crash reporter, and none had an upload address configured. Graphify, the tool we trusted least, opened no connection beyond the local model server in 358 socket samples. Section 5 of the report lists all six false leads, because a method that cannot catch them is not a method.
How we tested seven tools on one Mac
Every tool sits on the highest step of an evidence ladder we could reach for it. Grade A is a capture: we pointed the tool’s reporting host at a listener on the same machine, ran one fixed task with the setting on and then off, and recorded every request. Only OpenJarvis reached that step. Grade B is sockets: every network connection held by every process of the running tool, with the addresses resolved. OpenCode, LM Studio and Graphify sit there. Grade C is code: what the shipped bundle, the settings and the files on disk say the software is built to do. The Hugging Face library, Visual Studio Code and Pi rest on that step.
Two rules held throughout. A search count is not a finding; a string in a bundle shows that a byte sequence is present, and only the code around it shows what it does. Presence is not transmission; a crash reporter or an analytics library is a finding once there is an address it reports to, and the strongest evidence is a connection to that address.
The limits are stated in the report rather than left for a reader to discover. Every test ran on one Mac, on the version installed at the time. Socket listings are snapshots, so a tool that reports every few hours would not appear in one. We induced no crashes. Two tools, Visual Studio Code and Pi, were not network-tested at all and appear only in the disk and bundle checks. Our method guide, how to prove your data never leaves, explains why we grade evidence this way.
Five checks you can run on your own tools
Each check needs 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, and an established connection to an outside address is a question worth answering. Read the settings file for keys named for analytics, telemetry or usage, and for proxy or mirror settings. Look for the destination rather than the machinery: a DSN, a collector URL or a hard-coded host, because a library with no address sends nothing by that route. Filter identifier-shaped values by where they live, since a value inside a compiled binary is a build constant and one small file written at install is a machine identifier. When a tool lets you set its reporting host, run the A/B capture, which is the only check that shows the bytes themselves.
Section 7 of the report walks through each of these with the exact keys and paths we used, and the case studies show what a positive result looks like.
Download the report and the dataset
The PDF runs to 30 pages. Inside:
- A summary of the six findings, and the four numbers behind them
- The method and the evidence ladder, from code reading to byte-for-byte capture
- Results by tool, with 18 figures: OpenJarvis, OpenCode, LM Studio, huggingface_hub, Graphify, Visual Studio Code and Pi
- Six leads that looked like telemetry and were not
- A case study on Claude Code, reported by others
- Five checks anyone can run, the limitations, and the tests planned for the next edition
- Three appendices: the dataset, the sources and a glossary
The dataset, local-ai-telemetry-2026.csv, has one row per finding: tool, version, test date, evidence grade, method, destination, trigger, what is sent, whether it is on by default, and what we found of an off switch. Every row links to the published investigation it came from.
The report and its dataset are licensed CC BY 4.0. Copy them, share them and build on them, with credit to StrideNote. The permanent record is on Zenodo under DOI 10.5281/zenodo.22848632. To cite it: StrideNote (2026) Local AI Telemetry Report 2026. Edited by StrideNote Studio. Stridenalysis Reports, edition 1. No company named in the report paid for it or reviewed it before publication. If you find an error, write to info@stridenote.net and the correction will appear in the next edition.
What the next edition will test
Edition 1 rests on the evidence we had. Its biggest gap is the OpenCode payload: the findings there rest on connections seen, not content captured, so the first test on the list is an error capture with a local sink in place. LM Studio gets a full working day of recorded requests instead of a snapshot. Hermes Agent, the always-on assistant in our own stack, has not yet been inspected. Pi and Visual Studio Code move from disk checks to socket evidence, and Ollama, the runtime the OpenJarvis installer added, joins the list.
The next report narrows to agents. The Local Agent Telemetry Report 2026 will cover coding and personal agents only, with the same evidence ladder and a version recorded for every test. A tool that is absent from either report has not been cleared by us. It has simply not been tested yet. The identifier sweep and the crash reporter check show what each of those tests will look like when it is done.