OpenRouter ZDR: How Zero Data Retention Routing Works

01

Overview

OpenRouter now gives developers several ways to require Zero Data Retention, or ZDR, when routing AI requests across its model marketplace. The important part is that ZDR is not a vague privacy label: OpenRouter exposes it as an enforceable routing requirement at the account, guardrail and individual-request level.

For a single API request, developers can set provider.zdr to true. OpenRouter says that request will then route only to endpoints whose policy qualifies for Zero Data Retention. That makes ZDR especially relevant for teams using multiple model providers but wanting one consistent retention control at the gateway layer.

02

What is OpenRouter ZDR?

Zero Data Retention means an eligible inference provider processes a prompt and response without persisting either after the request is completed. OpenRouter explicitly distinguishes this from a broader claim that data never leaves your environment.

Your request still reaches the selected model provider for inference. ZDR also does not automatically control copies created elsewhere in your stack, including application logs, connected tools, plugins, caches or downstream storage.

That distinction matters. A system can use a ZDR inference endpoint and still retain sensitive data in its own request logging pipeline. ZDR solves one layer of the problem: provider-side prompt and response retention.

03

How do you enable ZDR on OpenRouter?

OpenRouter documents four practical enforcement layers:

• account-level privacy settings;
• model-group settings;
• guardrails;
• per-request routing with provider.zdr.

For request-level enforcement, include zdr: true inside the provider object. OpenRouter says this limits routing to endpoints with a Zero Data Retention policy.

A minimal request can look conceptually like this:

provider: { "zdr": true }

OpenRouter also documents a separate data_collection control. Setting data_collection to deny excludes endpoints that store user data non-transiently and may train on it.

These controls address different questions. ZDR asks whether prompts and responses are retained after inference. The data-collection setting addresses broader storage and training eligibility.

04

ZDR vs no-training: what is the difference?

A no-training policy and a zero-retention policy are not identical.

An endpoint can promise not to train on your data while still retaining prompts for abuse monitoring, legal requirements or operational purposes. ZDR is stricter on retention: the provider is expected not to persist the prompt or response after processing.

OpenRouter therefore recommends treating retention and training as separate policy dimensions. For a stricter request, developers can combine zdr: true with data_collection: "deny".

That does not make the entire application zero-retention. It only constrains eligible provider endpoints. Your own infrastructure and any tools used during the request still need their own policies.

05

How does ZDR work with US and EU in-region routing?

OpenRouter also offers region-specific API base URLs for US and EU processing. Its US in-region routing launched on September 9, 2026, joining an existing EU option.

Requests sent to the US endpoint are decrypted inside the United States and routed only to provider endpoints running there. The EU endpoint applies the same concept to EU-region processing.

Region controls and ZDR solve different problems:

• ZDR controls provider retention.
• data_collection: "deny" controls broader storage/training eligibility.
• in-region routing controls where eligible processing occurs.

For regulated or sensitive workloads, the useful pattern is to combine the controls that match the policy requirement instead of assuming one switch covers everything.

06

Does OpenRouter itself store prompts?

OpenRouter's ZDR documentation focuses on provider-side inference retention and repeatedly warns developers to account for other layers. Its privacy policy and product configuration should be reviewed separately for OpenRouter-side account, billing, security and operational data.

The safest reading is not “ZDR means nobody stores anything.” It means a ZDR-routed inference request is restricted to eligible provider endpoints that do not retain prompt and response content after processing, subject to the exact policy OpenRouter records for that endpoint.

07

Which models support OpenRouter ZDR?

There is no permanent model-name rule.

OpenRouter explains that policies can differ by provider endpoint even for the same model. A model may have one provider endpoint with stricter retention and another with different terms. OpenRouter tracks policy at the endpoint level and uses that policy information when routing.

That means a static list of “ZDR models” can become stale quickly. Developers should check current endpoint eligibility in OpenRouter rather than assuming a model is always ZDR-compatible everywhere it is served.

08

What happens if no eligible ZDR endpoint is available?

The point of using ZDR as a routing requirement is that privacy requirements constrain provider selection. If the requested model has no eligible endpoint matching the configured controls, the request should not silently fall back to an endpoint that violates the restriction.

This may reduce provider choice, affect availability or change cost/latency compared with unrestricted routing. Those trade-offs are normal consequences of stronger routing constraints.

09

Why this matters for AI agents

Agentic applications often generate more sensitive context than a simple chatbot. They may send source code, customer records, business documents, tool outputs and long conversation histories to models repeatedly.

They also use prompt caching, tools and persistent application logs more heavily. That makes a single “do not train on my data” preference insufficient for many teams.

OpenRouter's ZDR control is useful because it makes retention policy part of the request-routing decision. A developer can enforce a policy centrally even when switching between several model families and providers.

The same flexibility also increases the need to audit the rest of the stack. A ZDR model request can still be copied into a monitoring service, tool trace or database by the application itself.

10

Practical privacy checklist

For a sensitive OpenRouter workload, check the following separately:

1. Require ZDR at the account, guardrail or request level.
2. Use data_collection: "deny" if provider storage/training restrictions are also required.
3. Use US or EU in-region routing if processing location matters.
4. Review application logs and tracing.
5. Review tool and plugin data handling.
6. Review caching behavior.
7. Verify the live endpoint policy instead of relying on an old model list.
8. Recheck policies before moving a sensitive production workload to a new provider.

11

Is OpenRouter ZDR the same as private or on-prem inference?

No.

ZDR still sends data to an external inference provider. It controls retention after processing; it does not keep the request entirely inside your own network.

Organizations that require data never to leave customer-controlled infrastructure need a different architecture, such as self-hosted inference or a provider arrangement specifically designed for that requirement.

12

Bottom line

OpenRouter ZDR is best understood as an enforceable provider-retention routing control rather than a universal privacy mode.

Its main advantage is consistency: developers can require eligible zero-retention endpoints while continuing to route across multiple model providers. Combining ZDR with data_collection: "deny" and region-specific routing creates a more precise policy stack for teams that care about retention, training and processing location.

The main limitation is equally important: ZDR only controls one part of the data path. Logs, tools, plugins, caches and application storage remain the developer's responsibility.

Because endpoint policies can change, any provider or model eligibility claim should be verified against OpenRouter's live policy data before deployment.