Privacy & offline
TurboLLM is offline-first. Core local use needs no account, no backend, and no internet. Your prompts, chats, files, and keys stay on your machine — regardless of your telemetry choice. Telemetry itself defaults to on (see below) so setup problems and real-hardware speed get found and fixed, but it never touches your content.
No account, no backend, no internet required. Your prompts, chats, files, and keys never leave your machine, regardless of your telemetry choice.
No account, no cloud, no login
There is no TurboLLM cloud account to create and no login screen to get past. You run npx turbollm and the app is yours. There is no backend service that your session phones home to, and nothing is uploaded by default. TurboLLM works the same on a fully air-gapped machine as it does on a connected one.
Everything is stored locally
Your data lives on your disk, under a single directory in your home folder:
~/.turbollm/Chats, settings, and keys are kept there on your own machine. Nothing is synced to a server, because there is no server to sync to. If you want a clean slate, that directory is the whole footprint.
When TurboLLM touches the network
Every network request TurboLLM ever makes falls into one of these categories. The first three only ever fire from something you explicitly did; the fourth is the one periodic background exception, and its content is governed entirely by the telemetry level you chose (see below).
Downloading an engine build
When you choose to install an inference engine, TurboLLM fetches that build. No engine is downloaded until you pick it.
Downloading a model
When you pull a model from Hugging Face, TurboLLM downloads the weights you selected. Nothing is fetched unless you ask for it.
An in-chat tool call you approve
A web_search or fetch_url tool call reaches the internet only after you approve it. Every tool call passes through an approval gate first.
Telemetry (if not turned off)
A periodic background upload, on by default, whose content depends entirely on the level you chose — see the Telemetry section below for exactly what each level sends. Never your prompts, files, paths, or keys, at any level.
Auto-memory stays on-device
Auto-memory is experimental and off by default. When you turn it on, it uses your own loaded local model to extract facts from your conversation. That work happens entirely on your machine using the model you already have running — nothing leaves the device to make it happen.
Telemetry
Telemetry defaults to on (Usage + benchmarks + crash reports) so setup problems and real-hardware speed get found and fixed — verifiable telemetry only helps if enough people are actually sending it. Change your level any time from Settings → Privacy & telemetry, or turn it off entirely. The client is source-available, so every claim below is checkable against the code that ships.
Off
Sends only that one-time choice, nothing else, ever — no machine id, no hardware, no timestamp.
Anonymous usage + benchmarks
Which features you use, your hardware, model names, and measured speed. Never prompts, files, paths, or keys.
Usage + benchmarks + crash reports (default)
Adds error fingerprints, the resolved model config behind a load or benchmark, which coding tool is connected to the local API (e.g. Claude Code, opencode — never which files, projects, or prompts it sends), daily volume counts (chats, messages per chat, API requests), and which screens and buttons you use. Never your content, cursor position, or file paths.
You can preview the exact payload before anything is sent, and inspect a running log of every event this machine has actually transmitted, from the same Settings section. For scripted or unattended use, --no-telemetry (or TURBOLLM_TELEMETRY=off) is a hard, one-way kill switch, independent of the saved level.
Android
Two ways to run TurboLLM on Android, with different telemetry behavior:
Via Termux
Running the same npx turbollm package inside Termux uses the identical daemon and telemetry code as desktop — the levels and defaults described above apply unchanged, and you control them the same way, from Settings → Privacy & telemetry.
Standalone Android app (early access)
The companion Android app launches that same local daemon with its own desktop-style telemetry hard-disabled (--no-telemetry) in its own startup code — so none of the levels described above apply to it, and today the app ships with zero telemetry, zero analytics, and no crash-reporting SDK. Everything else on this page — no account, local-only chat/model storage, the tool-call approval gate — applies identically.
Neither path sends chat content, prompts, files, or model weights anywhere. Since this is source-available software, these claims are checkable against the code that ships.
If you apply to the app beta
Everything above describes the software. The beta application form is the one place TurboLLM asks you for personal information, and it is entirely separate from the app: nothing on that form is collected by the software, and running TurboLLM never sends anything to it.
If you fill it in, what is stored is what you typed — your name, your email address, the platforms you ticked, and your answer to why you want to test — plus the country your request came from and a one-way hash of your IP address, which exists only to stop one source flooding the form. The IP itself is never written down. That data lives in its own database, separate from the telemetry pipeline described above, and is used for exactly two things: sending you a build, and asking how it went.
You get one confirmation email when you apply, and then nothing until there's a build ready for a platform you picked. Sending it means your name and address pass through Resend, the email provider — the only third party in this, and only for delivery. No newsletter, no drip sequence, no analytics pixel in the email.
It is never sold, never shared with anyone else, and never used to send you anything you didn't apply for. Ask and it's deleted — reply to any email from the beta, or open an issue on GitHub if you'd rather not email.