Summary: Zero Data Retention (ZDR) is a narrow promise, not a privacy shield: a provider reads your prompt, returns a response, and keeps neither. Its real value is narrower and more useful—ZDR becomes an enforceable routing rule, one that confines sensitive traffic to endpoints that have undertaken not to persist it. Treat it as blanket protection and you misread it.
Zero Data Retention (ZDR) is a narrow promise, not a privacy shield: a provider reads your prompt, returns a response, and keeps neither. Treat it as blanket protection and you misread it. The request still travels to the provider, the model still reads it, and your application logs may still keep a full copy. Its real value is narrower and more useful—ZDR becomes an enforceable routing rule, one that confines sensitive traffic to endpoints that have undertaken not to persist it.
The single question ZDR answers
One narrow question is all ZDR settles: once inference finishes, does the provider keep prompts and responses at rest? Data in transit, training, and what your app later does with the response all sit outside it. OpenRouter’s guide puts it bluntly—a policy of “no training” doesn’t imply ZDR. A provider may spare your data from training yet still hold it briefly to run abuse checks or meet a legal duty. The converse does hold, and it is the stronger claim: an endpoint that retains nothing has nothing left to train on later.
Third-party tools fall outside ZDR as well. Switch on a web search plugin or wire in an external service, and the request reaches that tool under retention terms of its own. Your app adds another layer: an error tracker, an analytics event, or a database row may still hold a complete prompt from a ZDR request. Those copies are beyond what provider-side ZDR touches.
Turning ZDR into a rule on OpenRouter
A provider offering ZDR does not make your requests compliant on its own; you have to switch it on, and OpenRouter gives you three places to do it:
- Account-level privacy settings: demand ZDR for a model group (Anthropic, OpenAI, Google, SpaceXAI, non-frontier) with no code changes.
- Guardrails: extend ZDR over larger sets of requests.
- Per-request field: pass
provider.zdrastrueon the call.
The per-request flag behaves as an OR against the guardrail and account-wide settings—switch ZDR on in any one of the three and enforcement takes effect. Loosening or overriding a rule that already exists at the account level is beyond what the request-level flag can do.
One minimal call pairing ZDR with a data-collection denial:
{
"model": "meta-llama/llama-3.3-70b-instruct",
"messages": [{ "role": "user", "content": "Hello" }],
"provider": {
"zdr": true,
"data_collection": "deny"
}
}data_collection: "deny" rules out endpoints that hold user data in non-transient fashion and may train on it. That control is separate from ZDR, though the two often belong together.
Two easy traps: caching and metadata
Provider-side prompt caching in memory sits fine alongside ZDR, since the prompt never reaches persistent storage. OpenRouter’s own response caching behaves differently and holds generated responses for a time. Switching response caching off is what account-level ZDR does, whereas the per-request provider.zdr field does not change response-cache eligibility. Where zero storage has to hold at every layer, the response caching setup needs an audit of its own.
Metadata leaves another gap. Even with prompt and response content unretained, request metadata—token counts, latency, model, cost—stays with OpenRouter. Usage and activity views run on it, and the price of that is simple: ZDR still isn’t the same as “no record of the request ever existed.”
Checking a vendor’s ZDR claim
Data policies are read by OpenRouter at the endpoint level, not merely the provider level. A provider’s general policy may not match what a particular model endpoint carries. Where an endpoint’s policy can’t be confirmed, the cautious classification applies: retaining the data and training on it.
Five questions are worth putting to any vendor. Which exact data does ZDR cover—prompts, completions, uploaded files, tool inputs, cached representations, identifiers? Does the policy attach per provider, or per endpoint? What falls outside it—metadata, plugins, batch APIs, stateful features? Which mechanism enforces it—account policy, guardrail, or request-level control? And how can continued eligibility be verified? OpenRouter publishes the live ZDR endpoint list at https://openrouter.ai/api/v1/endpoints/zdr, so routing can follow current policy instead of a stale spreadsheet.
ZDR’s place in a wider privacy stack
ZDR is a single control in a set of many. Where a request gets processed is a question for region pinning (inside the EU, for GDPR, say). Keeping inference on your own infrastructure is what self-hosting does. What was sent, and to where, is what your own logging records. ZDR replaces none of them, and none of them replaces ZDR.
The same layered logic shows up in other infrastructure choices. Picking an OpenAI model on Bedrock means weighing cost per correct answer rather than the sticker price. ZDR has you weigh per-endpoint retention risk, not a line from a provider’s marketing page.
For sensitive inference traffic, stack whichever controls your policy actually calls for: ZDR for retention, data_collection: "deny" for storage and training limits, and in-region routing where the processing location matters. Then walk your application logs, the tools you’ve enabled, and the caching setup, so no other layer rebuilds the data you stripped from the provider.