Zero Data Retention on OpenRouter, and how to check the claim

Turn on Zero Data Retention. Then verify it, because a toggle in a settings page is not evidence.

ZDR means a provider does not store your prompt or response after the request completes. OpenRouter can restrict routing to endpoints with that policy. It is a retention guarantee, not a privacy guarantee: your prompt still leaves your network and the model still processes it.

Retention and training are different claims

A provider that does not retain your data cannot train on it. The reverse does not hold. OpenRouter's docs are explicit that some endpoints do not train on your data but do retain it, for abuse scanning or legal reasons.

So "we don't train on your data" is not ZDR. Two toggles, two claims.

Four things ZDR does not cover

1. Transmission and processing. ZDR governs retention at rest only.
2. In-memory caching. OpenRouter does not count implicit prompt caching as retention, so cached endpoints stay reachable under ZDR.
3. Plugins and tools. Enforcement applies to inference routing, not to tools you enable.
4. Metadata. Token counts, latency and similar are kept for reporting and your activity feed.

Enforcing it

Three levels: account privacy settings per model group, guardrails per API key or org member, and the zdr field on a request.

They stack as an OR. Setting zdr: true on a request adds enforcement. Setting it false does not remove enforcement configured elsewhere, so a developer cannot opt a request out of an org policy by accident.

Set it at account or guardrail level. Treat the request field as backup.

Verifying it

Monitor the list. ZDR endpoints are published at api/v1/endpoints/zdr and update when a provider changes policy. An endpoint you validated in March may not be one today.

curl -s https://openrouter.ai/api/v1/endpoints/zdr > zdr-new.json
diff <(jq -S . zdr-current.json) <(jq -S . zdr-new.json) || \
  echo "ZDR endpoint list changed"
mv zdr-new.json zdr-current.json

Weekly, alerting on a non-empty diff. If a model you depend on drops off, hear it from your monitoring, not your auditor.

Check endpoints, not providers. A provider's general policy may differ from a specific endpoint's. "Anthropic is ZDR" means nothing on its own.

Know the fallback. Where OpenRouter cannot ascertain a clear policy, it assumes the endpoint retains and trains, and marks it so.

Check where requests actually went. Routing is dynamic. The activity feed shows the provider that served each request.

Ask for third-party evidence. SOC 2 Type II or ISO 27001. General vendor diligence, but self-reported policies carry little weight in an audit.

The setting to leave alone

Prompt logging is opt-in, off by default, and traded for a 1% discount. Enabling it means OpenRouter stores your prompts and completions under terms broader than most people expect. Read section 6.2 before deciding.

Training opt-out is configured separately for paid and free models. Set both.

What ZDR cannot fix

ZDR governs what happens after your data arrives. Nothing about what you send.

That matters most when the data is not yours to leak. A clinician pasting a patient summary, a solicitor pasting a client file: ZDR means the provider does not keep it. It does not mean the disclosure did not happen, and it does nothing about your own application logs.

Strip identifiers before the call. Redaction at the boundary is the only control that survives a change in someone else's policy.

Checklist

• ZDR on per model group, and on the guardrail for each key
• Training opt-out for paid and free models
• Prompt logging off
• api/v1/endpoints/zdr monitored with alerting
• Activity feed spot-checked against expected providers
• DPA covering OpenRouter and downstream providers
• Identifiers stripped before the request leaves your app

ZDR is worth turning on. It is not worth trusting without the diff job.