What "Runs Locally" Actually Means: A Marketing Claims Audit

“Runs locally” shows up on more AI companion landing pages every month, and it means at least four different things depending on which one you’re reading. Only one of those four actually delivers the privacy guarantee most people assume the phrase promises.

That gap between what a phrase implies and what it technically commits to is worth taking seriously, because it’s exactly the kind of gap that survives a legal review while still misleading a normal reader.

Four phrases, four different guarantees

The short version: “runs locally,” “on-device,” “hybrid,” and “private by design” each promise a different, specific thing, and treating them as synonyms is how the confusion happens.

“Runs locally” technically refers to where the AI model itself does its processing. Taken literally and precisely, it says nothing about the rest of the application. An app can have a model that genuinely runs on your device while the surrounding software still phones home for telemetry, crash reports, usage analytics, or settings sync. Both of those facts can be true about the exact same product at the exact same time.

“On-device AI” carries essentially the same scope as “runs locally,” describing the model’s location rather than the application’s complete network behavior. It’s a real, meaningful claim about one component. It just isn’t a claim about the whole system, even though it often reads like one.

“Hybrid” is the most honest of the four, in a strange way, because it openly admits the architecture splits between local and cloud processing rather than implying a purity it doesn’t have. A hybrid app might run simple requests locally and route complex ones to a server. That’s a legitimate design. It’s also not what most people picture when a landing page leads with “local AI” in large type and mentions the hybrid part in the FAQ section three scrolls down.

“Private by design” is the one with no specific technical content at all. It’s a values statement, not an architecture claim, and it can be paired with any of the three setups above, including ones that send plenty of data out, without technically lying about anything, because it never committed to a specific mechanism in the first place.

Here’s an illustrative example, not a claim about any real product, to make the gap concrete. Imagine an app whose landing page reads “Runs Locally. Your Data Stays Private.” in large type at the top. Underneath, in the FAQ, a single line says the app “may collect anonymous usage data to improve the product.” Both statements can be entirely true at once: the model genuinely processes on-device, and a separate analytics pipeline genuinely runs alongside it, sending event data to a third-party service. Nothing here is a lie in the legal sense. But a reader who stopped at the headline walked away with an impression the footnote quietly contradicts, and that gap between headline and footnote is where most of the confusion in this category actually lives, not in outright false claims.

A local model is not the same claim as zero network traffic

The short version: the model running on your device and the app making no outbound connections are two separate facts, and a product can have the first without the second.

This is the actual gap worth internalizing, because it’s the one marketing copy has every incentive to blur. A company can accurately say its AI model runs locally while shipping an app that still calls home constantly for reasons that have nothing to do with the model itself: usage analytics to understand feature adoption, crash reporting to catch bugs, a check-in to verify a license or subscription, sync of your settings across devices. None of that involves the model doing anything except sit there locally, exactly as advertised, while the surrounding application behaves in a way most users picturing “fully local” would not expect.

Neither behavior is inherently dishonest on its own. The dishonesty, where it happens, is in letting a narrow, technically true claim about the model stand in for a broader impression about the whole product that the company never actually made. I’ve written about exactly how to check the difference yourself, rather than take any vendor’s word for where the line actually sits.

It’s worth being fair to the companies that get this right, too, even without naming any specific one. A product that says plainly “the model runs locally, and we also collect anonymized crash reports over the network” has told you everything you need to decide whether that trade works for you. The problem was never that some network traffic exists alongside a local model. The problem is when the marketing implies a purity the architecture doesn’t have, and the reader has no easy way to find out otherwise short of running a network monitor themselves, which almost nobody does before installing an app.

How to check any product’s claim yourself, not just mine

The short version: a network monitor that asks permission before any connection goes out will show you the real behavior directly, for any app, not only the one I build.

The methodology doesn’t depend on trusting a specific company at all, which is the entire point of using it. Install an outbound firewall, Little Snitch on macOS or GlassWire on Windows, set it to alert on every new connection rather than silently approving them, and then use the product normally for a few minutes. A model that genuinely runs locally produces silence during an ordinary conversation, because there’s no server in the loop to talk to. Anything that fires during that window is traffic worth understanding, and a specific enough privacy policy should be able to tell you what it was and why.

This test works on any app claiming any of the four phrases above. Run it before you trust a “runs locally” badge on a landing page, and you’ll know within minutes whether the claim describes the whole product or just the one component it technically refers to.

A few practical things to watch for once the monitor is running. Connections that fire on a predictable schedule, every few minutes regardless of whether you’re actively chatting, usually point to background telemetry or analytics rather than anything related to the AI itself. Connections that fire exactly when you send a message, every single time, are the strongest signal that at least part of the response generation is happening somewhere other than your device, no matter what the marketing copy called the architecture. And connections that only ever appear once, right after install, are the most benign category: a one-time model download or an update check, the kind of traffic even a fully local app legitimately needs.

Why I’m not naming names here

I could make this piece more dramatic by listing specific companies that lean on these phrases loosely. I’m not going to, because I haven’t personally run the network-monitor test against their products, and asserting a specific accusation I haven’t verified myself would be exactly the kind of unsupported claim this entire piece is arguing against. That would be a worse failure than the vague marketing copy I’m criticizing, not a better one.

What I can tell you honestly is how my own product’s claim holds up, because I control it and can describe it precisely: the model runs on your machine, and the privacy policy names the specific, narrow set of things that do leave your device, each one tied to a feature you’d have to deliberately turn on. That’s a testable claim, not a values statement, and I’d rather you verify it yourself than take my word over anyone else’s. The app is free to try, and the network monitor is free too.

Questions people ask

Back to the blog