Skip to main content
CloudLast verified June 29, 2026

OpenRouter data retention policy

OpenRouter does not log your prompts by default and offers Zero Data Retention controls, but retention and training also depend on the downstream provider you route to. Policy summary plus how to route OpenRouter through Meetily as a BYOK summary provider.

Quick policy snapshot

Default retention
See vendor policy
Zero data retention available
Yes
Trains on API customer data by default
No

OpenRouter's two-hop architecture

OpenRouter is a routing layer that exposes one API and one billing relationship while forwarding requests to dozens of downstream model providers (Anthropic, OpenAI, Mistral, Groq, and many open-weight hosts). This is convenient for model experimentation and cost management, but it changes the privacy model.

Every OpenRouter request crosses two administrative boundaries:

  1. Your client to OpenRouter (api.openrouter.ai).
  2. OpenRouter to the downstream provider you selected.

OpenRouter sees the prompt to route and log usage. The downstream provider receives the prompt to generate the response. The retention and training defaults that apply to your data are the union of both parties' policies.

Retention and training defaults

OpenRouter itself does not train models, and by default it does not log your prompts or completions. Its data-collection documentation states that OpenRouter "does not store your prompts or responses" unless you explicitly opt in to prompt logging, which is off by default. What it retains by default is request metadata: the number of prompt and completion tokens, latency, the model used, and similar request-level information, "not the content of your prompts or responses."

Opting in to logging is the user's choice. The "Private Input & Output Logging" option keeps your prompts and responses visible only in your own logs, and OpenRouter states it does not access or use that data. A separate opt-in ("OpenRouter Use of Inputs/Outputs") trades a small usage discount for letting OpenRouter use your inputs and outputs to improve its products; leave it off if you do not want that.

Whether your prompt is used for training and how long it is retained at the model provider is governed by the downstream provider's policy, not OpenRouter's. OpenRouter also exposes account-level toggles to disallow routing to providers that train on user data, with separate settings for paid versus free models.

Zero data retention

OpenRouter now offers Zero Data Retention as a setting, which is a change from the earlier per-provider-only picture. ZDR routes your request only to endpoints whose provider will not store your data, and providers with a ZDR policy cannot train on that data either. You can enforce ZDR at three levels:

  • Account-wide, via privacy settings.
  • Per model group, independently for different groups via settings or guardrails.
  • Per request, via the zdr parameter, which operates as an "OR" with your account-wide and guardrail settings.

The important nuance is that ZDR still depends on the downstream provider supporting it on the endpoint you call: the effective guarantee is the union of your OpenRouter setting and the selected provider's policy. For high-assurance no-retention workloads, enabling ZDR on OpenRouter plus verifying the chosen provider supports it gives the no-retention path; calling the provider directly removes one administrative boundary, and local Ollama removes the network entirely.

How Meetily uses OpenRouter

Meetily routes OpenRouter traffic through your own API key. Both OpenRouter's terms and the downstream provider's terms apply. The transcript text is sent over TLS to api.openrouter.ai, forwarded to the downstream provider you selected, and the response is returned to Meetily and stored locally on your device. Audio is never transmitted to OpenRouter at any point.

For production summary traffic with strict privacy requirements, calling the underlying provider directly (or running local Ollama) removes the OpenRouter administrative boundary entirely.

References

  1. Data Collection, OpenRouter Privacy documentation, https://openrouter.ai/docs/guides/privacy/data-collection (accessed 2026-06-29).
  2. Zero Data Retention, OpenRouter documentation, https://openrouter.ai/docs/guides/features/zdr (accessed 2026-06-29).
  3. Provider Logging, OpenRouter documentation, https://openrouter.ai/docs/guides/privacy/provider-logging (accessed 2026-06-29).
  4. Privacy Policy, OpenRouter, https://openrouter.ai/privacy (accessed 2026-06-29).

Last verified: June 29, 2026. Policy source: OpenRouter policy

Frequently asked questions

Does OpenRouter train models on my prompts?
No. OpenRouter is a routing service, not a model provider. It does not train any foundation models. However, prompts are forwarded to the downstream provider you select, and that provider's training and retention defaults apply to the request body.
Does OpenRouter retain my prompts?
Not by default. OpenRouter's documentation states it does not store your prompts or responses unless you opt in to prompt logging, which is off by default. By default it retains only request metadata (token counts, latency, model used, timestamps), not the content of prompts or responses. The downstream provider you route to applies its own retention separately.
Is zero data retention available for OpenRouter?
Yes. OpenRouter now offers Zero Data Retention controls that route only to endpoints with a ZDR policy. You can enforce ZDR account-wide, per model group, or per request via the `zdr` parameter. Because ZDR depends on the downstream provider supporting it on the endpoint you call, the effective guarantee is the union of your OpenRouter setting and the selected provider's policy. This is a change from earlier: ZDR is now a self-serve setting, not just a per-provider lookup.
How does the routing layer affect my data path?
An OpenRouter call is two hops: your client to OpenRouter, then OpenRouter to the downstream provider. OpenRouter sees the prompt to route and log usage. The downstream provider receives the prompt to generate the response. Your data crosses one additional administrative boundary versus calling the provider directly.
Where is OpenRouter data stored geographically?
OpenRouter operates primarily on US infrastructure. Downstream provider geography depends on which provider and endpoint you select. For EU data-residency requirements, calling EU-resident providers (Mistral, Azure OpenAI EU regions) directly is usually a cleaner data path than routing through OpenRouter.
How do I delete data OpenRouter has retained?
Account deletion is available via email request per OpenRouter's privacy policy. Downstream-provider data deletion is the responsibility of the user under that provider's policy.
How does Meetily handle OpenRouter when I pick it as my summary provider?
Meetily transcription is always 100% local. When you select an OpenRouter-routed model as your summary provider via BYOK, Meetily routes transcript text (not audio) to api.openrouter.ai using your own key. OpenRouter forwards the request to the downstream provider you selected. Both administrative boundaries apply.
When does it make sense to use OpenRouter with Meetily versus a direct provider?
OpenRouter is useful for testing multiple models behind one API and for cost-routing across providers. For production summary traffic with strict privacy requirements, calling the underlying provider directly removes one administrative boundary and one set of terms to audit. For zero retention by construction, use local Ollama and keep the entire pipeline on-device.

Use OpenRouter with Meetily, on your terms

Meetily transcription stays 100% local. For summaries, bring your own OpenRouter key (BYOK) so the data path matches the policy you just read - or pick a local model if you want zero retention by construction.

Set up BYOKDownload Meetily