Zero Data Retention (ZDR) is a specific guarantee: an AI provider processes your prompt, returns a response, and doesn’t store either one afterward. It’s not a magic privacy shield. Your data still reaches the provider, the model still sees it, and your own application logs can still keep a full copy. What ZDR actually gives you is a routing rule you can enforce, so sensitive requests only hit endpoints that promise not to persist them.
What ZDR covers—and where it stops
ZDR answers one narrow question: does the provider retain prompts and responses at rest after inference? It doesn’t control data in transit, training on data, or what your app does with the response. OpenRouter’s guide is explicit: a “no training” policy doesn’t imply ZDR. A provider might decline to train on your data but still hold it temporarily for abuse checks or legal reasons. The reverse is stronger—an endpoint that doesn’t retain data can’t later train on it.
ZDR also doesn’t cover third-party tools. If you enable a web search plugin or external service in a workflow, that tool has its own retention terms. Your application is another layer: a ZDR request can still leave a complete prompt in an error tracker, analytics event, or database row. Provider-side ZDR doesn’t delete those copies.
Enforcing ZDR on OpenRouter
A provider offering ZDR doesn’t automatically make every request compliant. You have to turn it on. OpenRouter supports three enforcement points:
- Account-level privacy settings: require ZDR per model group (Anthropic, OpenAI, Google, SpaceXAI, non-frontier) without touching code.
- Guardrails: enforce ZDR across broader groups of requests.
- Per-request field: set
provider.zdrtotruein the API call.
The per-request flag composes as an OR with account-wide and guardrail settings. If any one of them turns ZDR on, enforcement applies. The request-level flag can only ensure ZDR is on—it can’t override or loosen an account-wide rule.
Here’s a minimal request that combines 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" excludes endpoints that store user data non-transiently and may train on it. It’s a separate control from ZDR, but they often need to be combined.
Caching and metadata: two easy traps
Provider-side in-memory prompt caching is compatible with ZDR because the prompt isn’t written to persistent storage. But OpenRouter’s own response caching is different: it temporarily stores generated responses. Account-level ZDR disables response caching, but the per-request provider.zdr field does not affect response-cache eligibility. If your system requires zero storage across every layer, review response caching separately.
Metadata is another gap. OpenRouter retains request metadata—token counts, latency, model, cost—even when prompt and response content aren’t stored. That’s necessary for usage and activity views, but it means ZDR doesn’t mean “no record of the request ever existed.”
Verifying a vendor’s ZDR claim
OpenRouter evaluates data policies at the endpoint level, not just the provider level. A provider’s general policy may differ from the policy attached to a particular model endpoint. When they can’t confirm an endpoint’s policy, they classify it conservatively as retaining and training on data.
For any vendor, check five things: what exact data ZDR covers (prompts, completions, uploaded files, tool inputs, cached representations, identifiers), whether the policy is per provider or per endpoint, what falls outside (metadata, plugins, batch APIs, stateful features), how ZDR is enforced (account policy, guardrail, or request-level control), and how you can verify continued eligibility. OpenRouter publishes the current list of ZDR endpoints at https://openrouter.ai/api/v1/endpoints/zdr, so routing decisions can follow live policy rather than a static spreadsheet.
Where ZDR fits in a broader privacy stack
ZDR is one control among several. Region pinning controls where a request is processed (for GDPR, for example). Self-hosting keeps inference inside your own infrastructure. Your own logging records what was sent and where. None of these replace ZDR, and ZDR doesn’t replace them.
This is the same kind of layered thinking that applies to other infrastructure decisions. When you’re picking an OpenAI model on Bedrock, you weigh cost per correct answer, not just raw price. With ZDR, you weigh retention risk per endpoint, not just a provider’s marketing claim.
For sensitive inference traffic, combine the controls that match your actual policy: ZDR for retention, data_collection: "deny" for storage and training restrictions, and in-region routing when processing location matters. Then audit your application logs, enabled tools, and caching configuration so another layer doesn’t recreate the data you removed from the provider.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.