Product
Some documents cannot go to a server
A client's file, a patient's notes, an unpublished manuscript. Runlix has no account, no telemetry and no crash reporting, and it touches the network only when you go looking for a model.
Updated 2026-09-12
There is a category of work where "we do not train on your data" is not the reassurance it sounds like. A lawyer's case file, a doctor's notes, a company's unpublished results, a journalist's source, a manuscript nobody has read yet — for these, the question is not what a provider promises to do with the text. It is whether the text goes anywhere at all.
Runlix answers that by not having anywhere to send it.
lsof settle this page's claims without taking our
word for any of them.
What is not there
It has no account. There is nothing to sign up for, no email address to give, no licence key to activate, no "sign in to continue". The application does not know who you are because it never asks.
It has no telemetry. No usage statistics, no feature-flag service phoning home, no anonymous identifier assigned on first launch. This is worth stating in those words because "anonymous telemetry" has become normal enough to feel like nothing, and an identifier that persists across sessions is not nothing.
It has no crash reporting. When something breaks, the log stays in a file on your disk, and you can read it, and you can decide whether to send it to anybody.
And there is no cloud tier. There is no version of Runlix where your text goes somewhere for processing, so there is no setting you might get wrong, and no default that might change in an update.
What actually touches the network
Two things, and you start both.
Searching the model catalogue asks Hugging Face for a list, and downloading a model fetches files from Hugging Face. Those requests go to Hugging Face and are covered by their terms, not by anything on this site. If you never open the catalogue, the application never opens a connection.
That is the complete list. Not "the complete list of what we send about you" — the complete list of connections the application makes.
Where things are, on your disk
Models live in your Application Support folder, as files you can see, count and delete with Finder. There is no opaque store and no proprietary container: the safetensors that Hugging Face published are the files sitting on your disk.
Conversations live in a SQLite database in the same place, separate from the settings database. SQLite is a public format with tools everywhere, which means you can open it, read it, back it up and destroy it without asking us for an export feature.
Your Hugging Face token, if you choose to add one, goes in the macOS Keychain rather than in that database — the system's own encrypted store, protected by your login, and readable by the same tools you already use to audit what has your credentials.
The one place data does travel: the local API
Runlix can serve an HTTP API so other applications on your Mac can use the loaded model. It binds
127.0.0.1 and nothing else, which means it is reachable from your machine and not from your
network. It is off until you turn it on, and when it is on, whatever you point at it is
sending text into it — so what you connect matters, and that is your decision rather than a
default we made for you.
If you deliberately expose it beyond the machine, put a proxy in front and let the proxy decide who gets in. The application will not do that for you, because a checkbox marked "allow remote access" is exactly the kind of thing people tick once and forget.
What this does not mean
Local is not a synonym for safe, and it would be dishonest to let the word do that work.
The model is not audited by us. You download weights that somebody else published, and Runlix checks whether they will run rather than whether they behave. A model can produce confident nonsense, and running it on your own machine does not make it more truthful.
Your disk is the perimeter. If your Mac is not encrypted, your conversations are not protected. FileVault is doing more for you here than any promise on this page.
Tools reach out if you tell them to. Runlix speaks MCP, and an MCP server you configure can do whatever it does — including calling a remote service. Nothing arrives configured; everything in that file you put there yourself. But once you have, the guarantee on this page ends at the edge of the tool.
The application is not notarised yet. It is signed ad-hoc, which means macOS blocks the first open until you allow it explicitly. That is a real gap and it is on the roadmap, not hidden.
Compared with the alternatives
It is worth being precise about where Runlix differs from the other ways of doing this, because several of them are also local and the differences are narrower than marketing usually admits.
A hosted assistant with a no-training promise is the weakest position for this kind of work, and not because the promise is insincere. It is that the text still crosses a network, sits in a provider's logs for some retention period, falls under some jurisdiction, and can be reached by a subpoena, a breach or a change of ownership. None of those are hypothetical, and none of them are affected by what the provider does with the text for training.
A local application with an account is much closer, and for most people it is fine. The distinction that matters here is that an account is a link between you and a company's records — so there is a database somewhere with your email in it, a login that can be required again after an update, and a business that can change what the free tier includes.
A command-line runner gives you the same locality with none of the account, and it is what a lot of people reading this already use. Runlix is not arguing against it: the engine underneath is verified against the same reference. What it adds is a chat that remembers, a catalogue that checks before downloading, and one process instead of several.
Why you do not have to take this on trust
Check it yourself
Everything on this page is verifiable from outside the application, which is the only kind of privacy claim worth making.
Run lsof -i -a -p $(pgrep Runlix) and see which sockets exist. Open Little
Snitch, LuLu or any outbound firewall and watch what it asks permission for — the answer
should be nothing, until you open the catalogue. Point Console at the log file and read what
it records. Open the conversation database with any SQLite browser and look at what is
stored.
If any of that disagrees with what is written here, the page is wrong and should be corrected. That is a more useful commitment than a privacy policy, because it can be falsified.
Built this way, not configured this way
Almost every application that sends data somewhere has a setting to stop it, and the setting is usually honoured. The difference is where the burden sits: with a setting, staying private is something you have to keep being right about — across updates, across defaults that change, across a feature added by someone who did not know about your situation.
Runlix has no such setting because there is no such feature. That is a smaller promise than "we protect your data", and a more durable one: the parts that do not exist cannot be misconfigured, cannot regress, and do not need to be trusted.