Does OpenRouter train on your prompts? Data policy, explained
OpenRouter itself retains nothing unless you opt into logging. Training risk lives with the providers it routes to. The data_collection and zdr controls, what they cover, and what they cost you.
OpenRouter itself does not train on your prompts and does not retain them: “your prompts are not retained unless you specifically opt in to prompt logging.” The training question lives one layer down, with the providers your requests get routed to. Some of those retain inputs, and some may train on them. You control that layer two ways: account-wide defaults in your privacy settings at openrouter.ai/settings/privacy, and per-request provider preferences, data_collection: "deny" to exclude providers that store or train on inputs, or zdr: true to route only to Zero Data Retention endpoints. The trade is reach: the stricter the policy, the fewer endpoints qualify to serve you.
Two layers, two different questions
A request through OpenRouter passes through two hands: the router, then whichever provider actually runs the model. The router’s own posture is the easy half: OpenRouter has a zero-retention policy for itself, with prompt logging as an explicit opt-in (you flip it on if you want request history in your dashboard, and it stays off otherwise).
The provider layer is where the “do they train on me?” anxiety belongs, and it is genuinely per-endpoint: the same model can be served by several providers with different data policies. That is why the answer to “does OpenRouter train on your prompts” is properly “OpenRouter, no; where it routes you, depends, and you decide.”
Retention and training are different promises
The docs draw a distinction worth keeping: “Providers that do not retain your data are also unable to train on your data. However we do have some endpoints & providers who do not train on your data but do retain it (e.g. to scan for abuse or for legal reasons).” So three postures exist: retains-and-may-train, retains-but-does-not-train, and zero-retention. If your concern is training specifically, the middle posture is acceptable; if your concern is the data existing anywhere at all, only the third is.
The controls, exactly
Account-wide: the privacy settings page on your OpenRouter account sets the defaults every request inherits, including whether providers that may train on inputs are eligible for your traffic at all.
Per request: the provider object in the request body takes two relevant preferences:
"provider": {
"data_collection": "deny", // exclude providers that store or train on inputs
"zdr": true // route only to Zero Data Retention endpoints
}data_collection defaults to "allow"; "deny" restricts routing to providers that do not collect your data. zdr: true is the stricter cut: only endpoints with a Zero Data Retention policy qualify. ZDR can be enforced globally, per model group, or per request, so an agent can run strict by default and relax for a task that needs a model only available loosely.
Before relying on any of this, check the endpoint you’re actually getting: every model page on OpenRouter carries a data-policy section per provider, the same information the routing preferences filter on, readable before you send anything.
What the controls do not cover
Two boundaries are documented and worth quoting. First, “ZDR enforcement only applies to provider routing for inference requests. It does not apply to plugins and tools you choose to enable, such as web search”: those are third-party services with their own retention policies, and your prompt-derived queries reach them on their terms. Second, OpenRouter’s stated stance is that implicit prompt caching (repeated prompt data held in memory in the provider’s datacenter to speed up subsequent calls) “is not considered ‘retaining’ data.” Reasonable people can differ with that line; you should at least know where it is drawn.
The price of strictness
Every restriction shrinks the routing pool. A model whose only host retains data is unreachable under deny; a model with one ZDR endpoint loses its fallbacks under zdr. For an agent that runs unattended this matters more than for interactive use, because a refused route surfaces as a failed call at 3 a.m. rather than a picker with fewer entries. The workable pattern: set the account default to match your real floor, and treat per-request loosening as a deliberate exception, the same one-way discipline you would apply to any data boundary. For whose eyes reach an agent’s conversations beyond the model provider (the machine, the backups, the channels), the visibility map is the wider answer.