What does "zero data retention" actually mean?

Under a ZDR arrangement, the provider does not store your prompts or the model's outputs at rest after the response is returned. The model still reads your text to answer it, metadata such as usage statistics and billing counters is still kept, short-lived operational state can exist, and safety carve-outs still apply — but no conversation content is stored at rest afterward. It is the strongest retention arrangement cloud AI providers offer.

Why is zero data retention approval-only instead of a setting?

Because retention is what abuse monitoring runs on. OpenAI keeps abuse-monitoring logs for all API usage for up to 30 days by default — longer where law requires it or where needed to protect against harm — and grants ZDR only after prior approval and additional requirements — a ZDR customer is one whose traffic the provider largely cannot retroactively inspect, so the provider decides who qualifies. Safety-critical checks survive the arrangement regardless: OpenAI retains CSAM-flagged images for review even under ZDR, and Anthropic carves out flagged content and legal holds from every arrangement.

Does zero data retention cover everything I do with an API?

No — it is scoped per endpoint and per feature. OpenAI publishes an eligible-endpoint list and states that stateful services (Assistants, Threads, Conversations, Vector Stores, Batches) may still store application state even with ZDR enabled. Anthropic scopes ZDR to its Messages and Token Counting APIs, excludes stateful and consumer products, and its Covered Models — currently Claude Fable 5 and Claude Mythos 5 — cannot run under ZDR at all, carrying a mandatory 30-day safety retention instead.

Can anyone verify a zero-data-retention promise?

Not from outside — a customer cannot observe an absence, so ZDR rests on contracts and the enterprise trust apparatus around them (DPAs, SOC 2 reports, auditors examining controls). The closest public corroboration so far is indirect: when a US court ordered OpenAI to preserve conversation logs in the New York Times litigation, the scope — on OpenAI's own account — covered consumer tiers and standard API traffic but not ZDR API customers, because a preservation order freezes what exists, and for them nothing did.

Is "we don't log your data" the same as zero data retention?

No. A no-logging or no-collection declaration is a policy statement one rung below a formal ZDR arrangement; OpenRouter's documentation notes that some providers that do not train on your data still retain it, and that a provider's general policy can differ from a specific endpoint's. Retention policy belongs to the endpoint and the contract, not the brand — which endpoints, whose contract, what carve-outs is the test for any claim.

Does Secret Chat use zero-data-retention APIs?

Where the arrangement exists, the stack benefits from it, but we deliberately do not claim uniform zero retention across all models — retention varies by provider and endpoint, exactly as this article describes. What Secret Chat verifiably does: business API access with no training on your queries, per-response deletion requests with a Session Privacy Report where providers support deletion, chat history stored only in your own browser, and anonymized routing — so whatever a provider retains under its own terms is not linked to your name, account or IP.

Why "Zero Data Retention" Is Hard

Published August 21, 2026

"Zero data retention" is the strongest retention arrangement you can get from a cloud AI provider, and it is real: under a ZDR agreement, your prompts and the model's answers are not stored at rest once the response is returned. It is also one of the most misread phrases in AI privacy — because it is a configuration, not a property of a company. It is approval-gated rather than a toggle, scoped per endpoint and per feature rather than per brand, and it comes with carve-outs written by the providers themselves: OpenAI's stateful features "may still store application state, even if Zero Data Retention is enabled", safety-flagged content is carved out at both major providers, and Anthropic's two newest models cannot run under ZDR at all — they carry a mandatory 30-day retention window because, in Anthropic's words, "some attacks only become visible across multiple requests". None of this makes ZDR hollow. When a US court ordered OpenAI to preserve conversation logs in 2025, the order reached free users, paid users and ordinary API traffic — and OpenAI's own account of the scope put ZDR API customers outside it, for the simplest possible reason: there was nothing stored to preserve. This article explains what ZDR actually promises, why it is genuinely difficult to build, why providers ration it, and how to read any ZDR claim — including ours.

What the Promise Actually Is

Start with the definition, which we keep in our glossary entry on zero-retention APIs: under ZDR, the provider does not keep your prompts or the model's outputs after the response is returned. The model still reads your text — it has to, to answer — but no conversation content is stored at rest afterward. Anthropic's engineering docs state it cleanly: under a ZDR arrangement, customer prompts and responses are not stored at rest after the API response is returned.

Three boundaries are built into that sentence, and each one carries weight:

"At rest" is not "never existed". During the seconds of processing, your prompt exists in plaintext in the provider's memory — decrypted at their edge, tokenized, batched through GPUs. ZDR governs what survives the request, not what happens inside it. (We traced the whole in-flight journey in What Actually Happens to a Prompt Inside an LLM Provider's Infrastructure.)
Content, not metadata. What ZDR removes is the conversation itself. Records about the traffic — usage statistics, token counts, timestamps — sit outside it, and Anthropic states outright that it retains its User Safety classifier results even under ZDR. The bill still has to be computed from something.
Retention is one axis of three. Whether a copy is kept, whether the data trains models, and whether humans can read it are separate questions — a provider can decline all training and still retain chats for years. ZDR answers the first question only; API terms usually answer the second separately.

Why It Is Genuinely Hard to Build

The naive picture of retention is a database the provider could simply skip writing to. The reality is that a modern inference service makes copies at many layers for many reasons, and "zero retention" means hunting down every one of them:

Logs are the default everywhere. Request logging, error logging, crash dumps, debugging traces — ordinary operations capture payloads at multiple points in a serving stack. A ZDR pipeline has to be engineered so that no layer writes conversation content, including the layers that only fire when something breaks. This is genuinely unusual engineering: when a request fails at 3 a.m., the on-call engineer's normal tool is the log that ZDR forbids.
Caches hold prompt-derived state by design. Providers cache repeated prompt prefixes for speed and price. What is kept is typically a derived, often encrypted representation rather than the raw text — OpenAI documents its cached key/value tensors as encrypted, GPU-local application state that expires within 24 hours — but it is state derived from your prompt that outlives the request, one more thing the arrangement has to bound.
Abuse monitoring wants exactly what ZDR forbids. This is the deepest tension, and the next section is about it.
Stateful features store by definition. Anything that remembers your conversation for you — threads, assistants with persistent state, vector stores, uploaded file libraries, batch queues — exists because it stores. OpenAI's documentation is explicit that its stateful endpoints "may still store application state, even if Zero Data Retention is enabled", and Anthropic excludes its stateful agent product from ZDR for the same reason. A feature whose job is remembering cannot be zero-retention; the arrangement covers features that can work without keeping your content, and excludes the ones that exist to keep it. Even eligible paths leave short-lived operational state — OpenAI documents background-mode responses sitting on disk for roughly ten minutes, and audio conversation state kept for an hour.
Even the browser gets involved. A small but telling detail from Anthropic's docs: organizations under ZDR cannot call the API directly from browser-based apps (CORS is unsupported) and must route through a backend proxy. Zero retention is not a checkbox on top of the normal architecture — it constrains the architecture.

The result is a hierarchy worth internalizing, because each rung is meaningfully stronger than the one below it: never stored beats stored then deleted beats stored for a window beats stored indefinitely. Deletion — even honest, prompt deletion — still leaves an interval in which the copy exists, can be breached, or can be frozen by a legal hold. ZDR's whole value is living on the top rung.

Why Providers Ration It

If ZDR is so much better for customers, why is it something you must apply for rather than a switch in the dashboard? Because retention is not laziness — most of it exists for a reason, and the reason does not go away when a customer asks nicely.

Abuse monitoring runs on retained data. OpenAI's default for the API is that abuse-monitoring logs are generated for all API usage and kept up to 30 days — longer where required by law, or where "reasonably necessary to protect our services or any third party from harm". A ZDR customer is a customer whose traffic the provider largely cannot go back and inspect — so OpenAI grants the arrangement only after "prior approval" and "acceptance of additional requirements". You are asking the provider to trust you with its own blind spot; it decides whether you qualify.
Some safety checks override the arrangement outright. OpenAI's docs state that an image flagged by its CSAM classifier is retained for manual review "even if Zero Data Retention... is enabled". Anthropic's docs likewise carve out flagged content and legal holds from every arrangement. No provider will contract away its ability to act on the worst category of abuse, and none should.
The newest models are pulling retention back. The most instructive recent development: Anthropic designates its most capable models — currently Claude Fable 5 and Claude Mythos 5 — as "Covered Models" that cannot run under ZDR anywhere they are offered. Prompts and outputs are retained for 30 days for safety work, because sophisticated misuse — jailbreak campaigns, state-sponsored operations — "only become[s] visible across multiple requests": you cannot detect a pattern across requests you did not keep. Organizations with ZDR agreements must enable retention workspace-by-workspace to use those models at all. OpenAI keeps the same lever in its own docs, reserving the right to make models ineligible for Zero Data Retention for specific customers. The direction of travel matters: as model capability rises, the safety case for retention gets stronger, and the zero-retention perimeter gets redrawn around it.

Notice what this list has in common: the exceptions providers refuse to negotiate away are the safety mechanisms. That is not a scandal — it is the honest shape of the trade-off. A provider that retained nothing, ever, for anyone, would also be a provider that could not investigate anything, ever, done by anyone.

How It Is Actually Implemented

Mechanically, a ZDR arrangement looks like this across the providers that document it:

It attaches to an organization, not an account or a model. At Anthropic, ZDR is enabled per organization by the account team, negotiated through sales, and does not automatically extend to a second organization under the same account. At OpenAI it is an approval granted to eligible customers. Nobody's consumer product is included — Anthropic's docs exclude the Free, Pro and Max plans and even the Teams and Enterprise chat interfaces by name.
It attaches per endpoint and per feature. OpenAI publishes the eligible endpoint list — chat completions, responses, embeddings, audio transcription, image generation, moderation and a few more — with the stateful services outside it. Anthropic scopes ZDR to its Messages and Token Counting APIs, and a feature that rides on an eligible endpoint can still be excluded: code execution runs on the same Messages API and is marked not covered. The unit of the promise is not "Claude" or "GPT"; it is one route into one feature.
The flag travels with the traffic, and everything downstream must honor it. Content from a ZDR organization has to be skipped by every logging pipeline, excluded from every durable store, and given the shortest practical lifetime in every transient one — while the same infrastructure keeps full default behaviour for the next request from a non-ZDR customer. Providers do not publish those internals; but that per-request bifurcation is what the contract obliges, and the flag has to hold at every layer for the promise to mean anything.
What remains is the envelope. Billing counters, rate-limit state, usage statistics — and, at Anthropic, safety-classifier results — the metadata layer keeps running, because the service cannot function without it. We wrote about how much that envelope alone can say in The Metadata Problem Nobody Talks About.

The Verification Problem — and the One Public Stress Test

Here is the uncomfortable epistemology: you cannot observe an absence from outside. Auditors can examine controls, configurations and evidence; a customer cannot watch the pipelines, and "we never wrote it anywhere" is a claim about internals no customer can inspect directly. In practice, ZDR is a contractual promise, backed by the general apparatus of enterprise trust — DPAs, SOC 2 reports, auditors examining controls — which we unpacked in the compliance-alphabet guide. A contract binds future conduct and assigns liability; it does not give you X-ray vision.

Which is why the one public stress test matters. In 2025, a US court ordered OpenAI to preserve conversation logs — including chats users had deleted — in the New York Times copyright litigation. The scope, on OpenAI's own account, reached Free, Plus, Pro and Team users and standard API traffic, and did not apply to API customers with Zero Data Retention agreements. Sit with that for a moment: when a preservation order landed on the whole customer base, the ZDR tier fell outside it — not because those customers had better lawyers, but because a preservation order freezes what exists, and for them nothing did. (The forward-looking obligation ended in September 2025; everything captured while it ran stays preserved.) It is the closest thing to outside corroboration the arrangement has had — the order is the court's, the ZDR carve-out and its reason are OpenAI's own account of the scope — and it is exactly the shape of benefit "never stored" promises over "stored then deleted": deleted-but-retained-in-a-window data was precisely what the order froze. (The full story of that order is in Your AI Chats Can Be Subpoenaed.)

Reading a ZDR Claim in the Wild

Because the phrase sounds absolute, it gets used loosely — by vendors, by tools built on top of the providers, and by well-meaning summaries. The router service OpenRouter, which sits in front of dozens of model hosts, is unusually honest about the taxonomy, and its docs make two distinctions worth stealing:

"No training" is not "no retention". In OpenRouter's own words: "we do have some endpoints & providers who do not train on your data but do retain it." A provider can be entirely sincere about never training on your prompts while keeping them in logs.
The policy belongs to the endpoint, not the brand. OpenRouter tracks retention policy per endpoint precisely because "a provider's general policy may differ from the specific policy for a given endpoint" — the same model, from the same company, can be zero-retention on one route and not on another. That matches what the first-party docs above show: eligibility lists, feature tables, workspace flags.
ZDR routing does not cover the tools you switch on. OpenRouter warns that its ZDR enforcement "only applies to provider routing for inference requests" — not to plugins such as web search, which keep their own retention policies. The model call can be zero-retention while the search engine behind it is not.

So when any product tells you "we use zero-data-retention APIs", the questions that make the claim testable are: which endpoints, under whose contract, with what carve-outs, and what happens on the models where ZDR is not on offer? A claim that cannot answer those four is a slogan.

What This Means for You

Three practical consequences fall out of everything above:

At the major model providers, ZDR is not on a consumer's menu. It is negotiated organization-to-provider, and both OpenAI's and Anthropic's docs exclude their consumer plans from it by name. What consumers get instead are retention windows and deletion schedules — the landscape our 13-provider retention audit maps — plus training toggles, which govern a different axis entirely.
Retention and identity are two different defenses, and you want both. Retention controls how long your words exist on the provider's side. Anonymization controls whether whatever exists is linked to you. They fail independently: a ZDR pipeline processing a prompt tied to your named account still ties the request to you while it runs and in its metadata; a fully anonymized prompt that is retained for 30 days is a stored transcript that is not yours in any record. The strongest position is minimizing both — how long, and whose.
The top rung is still your own device. Never-stored beats stored-then-deleted — and the only party that can hold the conversation history without any provider promise at all is your own browser or disk.

How Secret Chat AI Fits — and Its Honest Limits

Secret Chat AI's design maps onto exactly those three points, so here is the precise version of what it does and does not claim.

What it does. Secret Chat reaches every model through business API access rather than consumer apps — the tier where providers commit not to train on the traffic — and your queries are never used for training. Your chat history lives only in your own browser: there is no server-side conversation archive here, and a prompt exists on our side only for as long as it takes to fetch your answer. On top of retention, it moves the identity axis: your queries reach the LLMs anonymously — whatever a model provider holds under its own terms and configuration, the record on that side carries our gateway's credentials and server address, not your name, your account or your IP. And where a provider supports per-response deletion, the app requests it after each answer and hands you a Session Privacy Report recording what was deleted and what each provider's policy retains — deletion receipts, not just deletion promises. For the free DeepSeek model, routing is restricted to an allowlist of US-based providers whose declared policy is that they do not collect user data — which, as this article should make clear, is a no-logging declaration, one rung below formal ZDR; OpenRouter's own documentation notes such endpoints might still retain prompts briefly, and we say so rather than rounding it up.

What it does not claim. Exactly what the four test questions above demand. Retention guarantees vary by model and endpoint, so we do not claim uniform zero retention across the lineup — the honest, verifiable position is business API terms, plus per-response deletion where the provider supports it, plus history that lives only with you. And the boundary that never moves: Secret Chat AI removes you from your queries — it does not remove the data from your messages. Whatever you type reaches the model provider verbatim and is processed under that provider's terms while it is answered; retention may still apply at the provider, but your query reaches the LLM anonymized — not linked to your email or identity. Redacting identifying details before sending remains your responsibility here as everywhere.

Frequently Asked Questions

What does "zero data retention" actually mean?
Under a ZDR arrangement, the provider does not store your prompts or the model's outputs at rest after the response is returned. The model still reads your text to answer it, metadata such as usage statistics and billing counters is still kept, short-lived operational state can exist, and safety carve-outs still apply — but no conversation content is stored at rest afterward. It is the strongest retention arrangement cloud AI providers offer.
Why is zero data retention approval-only instead of a setting?
Because retention is what abuse monitoring runs on. OpenAI keeps abuse-monitoring logs for all API usage for up to 30 days by default — longer where law requires it or where needed to protect against harm — and grants ZDR only after prior approval and additional requirements — a ZDR customer is one whose traffic the provider largely cannot retroactively inspect, so the provider decides who qualifies. Safety-critical checks survive the arrangement regardless: OpenAI retains CSAM-flagged images for review even under ZDR, and Anthropic carves out flagged content and legal holds from every arrangement.
Does zero data retention cover everything I do with an API?
No — it is scoped per endpoint and per feature. OpenAI publishes an eligible-endpoint list and states that stateful services (Assistants, Threads, Conversations, Vector Stores, Batches) may still store application state even with ZDR enabled. Anthropic scopes ZDR to its Messages and Token Counting APIs, excludes stateful and consumer products, and its Covered Models — currently Claude Fable 5 and Claude Mythos 5 — cannot run under ZDR at all, carrying a mandatory 30-day safety retention instead.
Can anyone verify a zero-data-retention promise?
Not from outside — a customer cannot observe an absence, so ZDR rests on contracts and the enterprise trust apparatus around them (DPAs, SOC 2 reports, auditors examining controls). The closest public corroboration so far is indirect: when a US court ordered OpenAI to preserve conversation logs in the New York Times litigation, the scope — on OpenAI's own account — covered consumer tiers and standard API traffic but not ZDR API customers, because a preservation order freezes what exists, and for them nothing did.
Is "we don't log your data" the same as zero data retention?
No. A no-logging or no-collection declaration is a policy statement one rung below a formal ZDR arrangement; OpenRouter's documentation notes that some providers that do not train on your data still retain it, and that a provider's general policy can differ from a specific endpoint's. Retention policy belongs to the endpoint and the contract, not the brand — which endpoints, whose contract, what carve-outs is the test for any claim.
Does Secret Chat use zero-data-retention APIs?
Where the arrangement exists, the stack benefits from it, but we deliberately do not claim uniform zero retention across all models — retention varies by provider and endpoint, exactly as this article describes. What Secret Chat verifiably does: business API access with no training on your queries, per-response deletion requests with a Session Privacy Report where providers support deletion, chat history stored only in your own browser, and anonymized routing — so whatever a provider retains under its own terms is not linked to your name, account or IP.

Conclusion

Zero data retention deserves both halves of its reputation. It is real — real enough that a federal preservation order flowed around it — and it is rationed, scoped and carved out in ways the three-word name hides. The honest summary of the whole landscape fits in four sentences. At the major providers, some retention is the default — abuse logs, consumer history, safety stores — and the reasons they document are safety and operations, not malice. The strongest arrangement removes conversation content from rest but keeps the envelope, the safety carve-outs, and the stateful features that store by definition. The promise attaches to endpoints and contracts, never to brands, and it cannot be audited from outside — only corroborated, occasionally, when something like a court order tests it. And the two defenses no provider has to grant you are the ones you can always take: keep the history on your own device, and keep your identity out of the request. Retention decides how long your words exist somewhere else. Anonymity decides whether they were ever yours to find.

Zero Data Retention
Why It's Harder Than It Sounds — and How Providers Implement It