Guides
What zero data retention means, and where it stops
Zero data retention is a promise a cloud provider makes about your request. How our /open chat enforces it, and which features fall outside it.
Before you type something sensitive into an AI chat, it helps to know where the words go and who promises what about them once they arrive. "Zero data retention" is one of the strongest promises a cloud service can make. It covers the model call, and features like web search and file parsing can fall outside it.
We built our free chat at offlinebase.com/open (opens in a new tab) around zero retention, and its limits show exactly where that promise ends.
What zero data retention means
Zero data retention, or ZDR, is a promise from the company running the model: it keeps nothing from your request. OpenRouter, the service our /open chat runs through, defines it in its docs (opens in a new tab): "Zero Data Retention (ZDR) means that a provider will not store your data for any period of time."
Our terms (opens in a new tab) describe the providers that the planned outside help on Base Drive and Base Router would use as ones that "contractually do not store the request or use it for training." On /open, the promise is the provider's zero-retention policy, enforced through OpenRouter.
Both are promises on paper. Your message still travels to someone else's server, gets processed and comes back. You cannot inspect that server, so you are trusting the provider to keep its terms.
Local AI removes the trip. The model runs on your own machine, so there is no request for anyone to retain. Our Base Drive page (opens in a new tab) says the drive's AI is designed to answer "entirely on your laptop... with no network involved at all" and to keep working with Wi-Fi off. Base Drive is coming soon and cannot be ordered yet. More in Base Drive, private AI for the laptop you already own.
Where you type | Where the text goes | What protects it |
|---|---|---|
A local model on your laptop | It stays on your machine | You control the machine |
A cloud chat under ZDR | The provider's servers, then deleted | The provider's terms |
An ordinary cloud chat | The provider's servers, where it may be stored | Its privacy policy and your settings |
How /open enforces it
Our /open chat is free, with 10 open-weight models as of October 2026. It has no account, and its headline reads "Open models. No account. Nothing saved." The models run in the cloud through OpenRouter under zero data retention, and the page says so.
Every model call the /open chat makes includes this in OpenRouter's provider settings:
"provider": { "zdr": true }
OpenRouter's docs say that when zdr is set to true, "the request will only be routed to endpoints that have a Zero Data Retention policy." Three choices on our side keep that promise from leaking:
- The request fails when the route is gone. If a model loses its zero-retention endpoint, you get an error, and the message is never handed to a provider that logs.
- The flag is set on our server. It is added to every request after the message leaves your browser, so nothing in the page can switch it off.
- Only listed models get through. The server refuses any model outside the curated list of 10, and every one of the 10 carries the flag.
Where the guarantee stops
The zdr flag covers one thing: which provider runs the model. OpenRouter is direct about this: "ZDR enforcement only applies to provider routing for inference requests." Tools such as web search "may be operated by third-party services with their own data retention policies."
On /open, two features sit outside the promise.
Web search, decided by the model. The /open chat offers web search with every model except Nemotron 3.5 Lightning, and the model decides when a question needs it. When it searches, the query goes to a search provider so the answer can cite sources. The page's privacy note says the model makes that call, and "that leg sits outside the promise." If your question contains a name or a case number, the search query can contain it too, even though you never pressed a search button.
PDF parsing, only if you attach one. None of the /open models read PDF files directly, so an attached PDF first goes through OpenRouter's file-parser plugin. OpenRouter's PDF docs (opens in a new tab) explain that its parser converts PDFs to text with an outside service. The zdr flag does not cover that step. The page tells you that attaching a file sends it to one more company, and attaching is always your choice.
There is a third edge, and it applies to every demo on our site. Our terms put it plainly: "Anything you paste into the demos on this site leaves your machine by definition." Zero retention describes what happens to your text after it leaves. Three things you can try on offlinebase.com without an account covers the other demos.
The same rules in our product design
Base Drive is designed to answer on your laptop. Base Router, the always-on box we are designing, is meant to handle every question locally first. We plan to give both products optional outside help for the hardest questions. On Base Drive that means web search and cloud escalation.
Outside help exists only as a design today. Both products are coming soon, and neither can be ordered yet. As designed, outside help:
- stays off until you turn it on
- names exactly what would be sent
- routes only to United States-hosted providers under zero-data-retention terms
- fails when no such provider is available, so nothing goes to one that logs
The /open chat already follows that last rule for zero retention, though it does not limit providers to the United States. Our terms call all of this design intent, which may change as we build. The rest of the consent design is in Why we make local the default for private AI.
Four checks for any "we keep nothing" claim
These work for our products and for anyone else's.
- Find out what the promise covers. Note which company makes it, which step it applies to (running the model, storing chats, training) and whether it sits in a contract or only on a marketing page.
- List the features outside it. Web search, file parsing, plugins and connected tools can run through other companies with their own policies. A trustworthy service names them.
- Check who turns those features on. On /open, you decide to attach a PDF, and the model decides when to search. A feature the software can trigger by itself deserves more caution.
- Ask what happens when no compliant provider is available. The answer you want is that the request fails. A service that quietly falls back to a provider that logs is making a weaker promise than it advertises.
For text you would not want on anyone else's server, the surest option is a model that runs on your own machine.