Network use that is not an external API: downloads, update checks, usage data

A tool that calls no external API still goes online. There are three common cases: downloading a model or data, checking for a new version, and sending usage data (telemetry). This note sets out, with code from real repositories, what goes back and forth in each case and how the way to turn it off shows in the code.

1. Downloading models and data

A tool that runs a model locally often downloads the model files on first run. Hugging Face Hub is the most common source, and some tools also fetch extra packages from a package registry (PyPI, npm) while running. Here files come in; your data does not go out. Model files can run to several gigabytes, though, and the first run fails where the internet is blocked.

A tool that fetches models with Hugging Face's huggingface_hub library uses only the files already cached when HF_HUB_OFFLINE=1 is set. That is the way to use a model offline once it has been downloaded.

2. Update checks

Command-line tools often ask whether a new version exists when they run. It is a single request, but what is sent along with it differs from tool to tool.

Lines 1–26 of update_check.rs in the sandbox tool nolabs-ai/nono describe this in a detailed comment. The check runs in the background once a day with a 3-second timeout. The request carries a random UUID created and stored on first run, the current version, the operating system, the CPU architecture, a coarse classification of whether it runs in CI, and a coarse classification of how it was installed. The way to turn it off is in the same place: set the environment variable NONO_NO_UPDATE_CHECK=1, or put [updates] check = false in the settings file (lines 201–202 check that variable).

What this example shows is that an update check can carry an identifier fixed for each install. It is not personal information, but it lets requests from the same install be linked to each other. To learn this for another tool, search its code for update, version check or releases/latest.

3. Usage data (telemetry)

Usage data is information such as which commands were run or which screens were opened, sent to the people who make the tool. What is sent, and whether it is on by default, varies widely. Two shapes seen in real code:

On by default, announced once, and off when a variable says so

Lines 555–576 of packages/cli/src/index.ts in the command-line tool of JuliusBrussee/caveman decide on or off, in this order:

• If DO_NOT_TRACK is set to anything other than empty or 0, it is off.
• If CAVEMAN_TELEMETRY is set, its value decides (1, true or on turns it on; anything else turns it off).
• In CI, or when not run from a terminal a person is typing in, it is off.
• A saved choice wins; with none saved, the default is on.

The default is on, but lines 637–661 are written so that nothing is sent until a one-line notice has been printed on first run. If you know you want it off, set DO_NOT_TRACK=1 before the first run.

The items sent fixed in code, and a switch in the settings

Lines 1–43 of app/src/analytics.ts in the desktop app amone-labs/porch write out the name and fields of every event sent, as types. The comment at the top says no paths, projects, prompts or summaries are sent, and that a build without an analytics key, or with the setting turned off, sends nothing. Lines 51–67 turn off the analytics tool's (PostHog) automatic capture, session recording, surveys and similar features one by one.

Code like this lets you check what is sent in the code rather than in a document, because a field that is not in the types cannot be sent.

Where to look for the off switch

• Set DO_NOT_TRACK=1 first. Many tools follow this convention, but not all. It works only for tools whose code checks that name, as caveman's does above.
• Search the code for names. Searching for DO_NOT_TRACK, TELEMETRY, analytics, and common analytics tools such as posthog, sentry, segment and mixpanel usually turns up where data goes and the variable that stops it.
• Check the tool's own variable or setting. Names differ per tool, like CAVEMAN_TELEMETRY=0 and NONO_NO_UPDATE_CHECK=1 above. They are often in a “Telemetry” or “Privacy” section of the README.

Where to look on a result page

This site does not count these connections as external APIs; it lists them separately (see What “No external APIs found” says).

• “Fetched over the network”: connections that bring things in, such as package registries, GitHub, release downloads and update checks, and documentation sites.
• “Data sent out”: what goes where, telemetry included, split into “Confirmed”, “Estimated” and “Unconfirmed”. “Estimated” rests on evidence not directly tied to the point where data is sent, so open the evidence lines and check for yourself.