# OpenRouter Zero Data Retention: restricting eligible routes

Evaluate OpenRouter Zero Data Retention across routing, provider endpoints, application logs and tools, including the announced screening-policy update.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/openrouter-privacy-zdr/
Language: en

OpenRouter Zero Data Retention concerns policies and settings for inference data handling. Evaluate the current platform terms and the specific endpoint rather than treating the abbreviation as a universal guarantee that nothing is stored anywhere. The complete application path includes components whose policies and logs must be checked independently.

## Map every processing participant

List the application, router, model endpoint and any tools or plugins that receive data. OpenRouter's ZDR documentation describes routing restrictions and boundaries involving tools and plugins. A single enabled setting does not explain the behavior of every participant in that chain.

Record what your own application logs, who can read those records and how long they remain. An external route's retention policy does not remove copies already created by a browser-facing backend, monitoring system or debugging session. Use this inventory as the starting point for a technical review.

## Read the announced policy update

The ZDR page includes notice of an update announced on October 27, 2026. OpenRouter's official CSAM-screening announcement describes screening traffic and the possibility of retaining flagged material for review and applicable procedures. The announcement explicitly includes ZDR traffic.

Read the current wording and effective conditions before relying on an earlier summary. Do not describe ZDR as an absolute exception to every platform process. This article records the policy context checked on November 1, 2026; a deployment decision should retain the version and date actually reviewed by the responsible team.

## Check settings at each boundary

| Boundary | What to establish |
| --- | --- |
| Application | Its own logs and access controls |
| Router | Current policies and applied settings |
| Model executor | The selected endpoint's handling policy |
| Tool or plugin | Separate transfer and retention conditions |

If a data-handling requirement is mandatory, verify routing behavior when no eligible endpoint exists. A controlled failure may be the intended result. A fallback must not quietly move the request to a route outside the recorded conditions merely to return an answer.

## Test without sensitive production input

Use neutral sample data to confirm settings, permitted routing and failure behavior. Keep the test separate from claims about legal compliance or universal confidentiality. Operational evidence can show what was configured and observed, while policy interpretation requires the appropriate responsible review.

Save the decision, owner and review date. Revisit it after changes to tools, endpoints or platform policies. For equipment owners, data handling is part of the deployment discussion alongside GPU readiness.

Official references: [openrouter.ai — zdr](https://openrouter.ai/docs/guides/privacy/zdr), [openrouter.ai — csam screening](https://openrouter.ai/blog/announcements/csam-screening/).

Related guides: [Errors inside an OpenRouter stream: why HTTP 200 is insufficient](/journal/openrouter-stream-errors/), [OpenRouter fallback with a price cap: limiting backup routes](/journal/openrouter-fallback-price-cap/).