Privacy and procurement answer

Does OpenRouter store prompts? Retention, logging, providers, and ZDR

OpenRouter says it does not store prompt or response bodies by default, unless the account opts into input/output logging or OpenRouter use of that content. It does store request metadata such as model, token counts, and latency. The selected provider endpoint, enabled tools or plugins, optional logging, and ZDR settings each have separate retention rules, so a gateway-level default is not proof that the complete request path retains nothing.

Last reviewed 2026-08-26 · Editorial review: KeepRouter Editorial

Direct answer

OpenRouter's current data-collection documentation says prompt and response content is not stored by default. It also says request metadata is stored. If a workspace enables private Input & Output Logging, the full content is stored for a minimum of three months and may be retained longer unless deletion is requested. A separate setting allows OpenRouter to use inputs and outputs in exchange for a usage discount.

That answer covers the OpenRouter gateway layer. A request still goes to a provider endpoint and may call a plugin or tool. Those components have their own policies.

Follow the data through every layer

Layer	What can be present	Current documented boundary
Application	Prompt, files, tool results, user identifiers	Controlled by the application owner
OpenRouter gateway	Request body and response in transit	Prompt and response bodies are not stored by default; metadata is stored
Optional OpenRouter logging	Full prompt and response content	Off by default; when enabled, minimum three-month retention and possible longer retention unless deletion is requested
Provider endpoint	Prompt, response, abuse signals, cache state	Endpoint-specific provider policy; it may differ from a provider's general policy
Plugin or tool	Query, arguments, returned data	Separate third-party policy; OpenRouter ZDR does not automatically cover plugins and tools
In-memory prompt cache	Repeated prompt prefix	OpenRouter states that it does not classify provider in-memory caching as retention for ZDR routing

The useful procurement diagram is therefore:

Application
  -> OpenRouter gateway
      -> selected provider endpoint
          -> optional tool or plugin

Write the owner, region, storage rule, deletion route, and evidence source beside every arrow. A single privacy toggle cannot answer for the whole graph.

Metadata is still stored

OpenRouter lists token counts, latency, model and similar request information as stored metadata. Metadata is not prompt content, but it can still matter for security classification, tenant attribution, retention schedules, and deletion requests. Ask whether your own customer or project identifier is placed in a header, model field, tool argument, or prompt body, because those locations can follow different storage paths.

What happens when input/output logging is enabled

Private Input & Output Logging is a separate, opt-in observability feature. OpenRouter says the stored content is encrypted at rest in an isolated Google Cloud Storage project, organization admins can view it, and retention is at least three months. It may remain longer unless the account owner requests deletion.

That can be useful for debugging, but it changes the data inventory. Record who can enable the setting, who reviews it, which workspace it affects, and how deletion is requested. Do not assume turning it off deletes previously stored records.

ZDR filters provider endpoints

OpenRouter defines Zero Data Retention as a provider not storing request data for any period. Current controls can enforce eligible ZDR endpoints at account, model-group, guardrail, or request level. A request-level example is:

{
  "model": "gpt-4",
  "messages": [{"role": "user", "content": "..."}],
  "provider": {
    "zdr": true
  }
}

OpenRouter says that when zdr is true, routing is restricted to endpoints marked with a ZDR policy. If no eligible endpoint exists, policy and availability can conflict. Test that failure rather than silently removing the restriction.

What ZDR does not prove

It does not cover a third-party plugin or tool just because the inference route is ZDR.
It does not mean no request metadata exists at the gateway.
It does not describe your application's own logs, traces, error captures, or analytics.
It does not guarantee that every endpoint from the same provider has the same policy.
Under OpenRouter's stated position, provider in-memory prompt caching can still be eligible under ZDR.
It does not replace a contract, data-processing review, regional requirement, or deletion test.

Compare the KeepRouter boundary carefully

KeepRouter's security page says its request log stores usage metadata rather than prompt or completion bodies and that optional response caching is off by default. Requests still pass through KeepRouter and the configured upstream route. KeepRouter does not currently publish a customer-facing request-level ZDR selector for its private upstream chain, so do not describe it as equivalent to OpenRouter's provider policy controls.

This is not a claim that one service is more private. The two public contracts expose different controls. Evaluate the exact model route, upstream policy, optional features, application logging, and legal agreement.

Procurement checklist

Export the current OpenRouter workspace privacy and observability settings.
Confirm whether Input & Output Logging or OpenRouter use of inputs/outputs is enabled.
Identify the exact model and eligible provider endpoints.
Decide whether ZDR is required globally, by model group, by key or guardrail, or per request.
Inventory plugins, tools, web search, file handling, and external observability destinations separately.
Record metadata fields, tenant identifiers, regions, retention periods, access roles, and deletion procedures.
Send a non-sensitive test request and capture the chosen route and policy evidence.
Re-review the official pages when routing or privacy settings change.

Use the AI gateway security checklist to turn this inventory into a review, then use the gateway evaluation guide to test the route before approval.

The source set on this page was opened on 2026-08-26. Product settings and provider policies can change after that date.

Frequently asked questions

Does OpenRouter log prompt text by default?

Its current documentation says no. Prompt and response storage is opt-in, while request metadata is stored. Provider endpoints and enabled tools have separate policies.

How long does OpenRouter input/output logging retain content?

OpenRouter currently says a minimum of three months and possibly longer at its discretion unless deletion is requested. This applies to the optional private logging feature.

Does provider.zdr=true cover tools and plugins?

No. OpenRouter states that ZDR enforcement applies to provider routing for inference, not automatically to plugins or tools, which can have separate third-party policies.

Does ZDR mean OpenRouter stores no metadata?

No. The data-collection page says request metadata such as model, token counts and latency is stored. ZDR controls provider endpoint retention for inference content.

Is KeepRouter equivalent to OpenRouter ZDR?

No equivalence is claimed. KeepRouter publishes that its request log excludes prompt and completion bodies and response caching is off by default, but it does not expose OpenRouter's request-level provider ZDR controls.