Zero Data Retention (ZDR): What It Means and How to Get It

Zero data retention (ZDR) means an AI provider processes your prompt, returns the response, and stores neither one. The request lives in memory for the length of the call and is then discarded. That is the meaning in one sentence, but the details matter. Providers still keep some records, such as billing data, and content that is flagged for legal or abuse reasons. A ZDR policy is a promise about your prompts and outputs, not about every byte that touches the service.

This guide covers why ZDR matters, how to get it on an API, what it covers and what it leaves out, and how OpenAI, Anthropic and OpenRouter each implement it. It also covers what to check in a zero data retention agreement before you sign. You will finish with a checklist you can run against any provider.

Geodd serves open-weight models through an OpenAI-compatible API, and several of them run with ZDR by default. That puts us close to the questions a security review asks, so the guide stays practical and shows where the real limits sit.

Why zero data retention matters

Zero data retention matters because every stored prompt is a copy of your data that you do not control. If that copy is breached, requested through legal process, reviewed by a person, or used to train a model, the risk lands on you and on the people whose data you sent.

Stored prompts are a second copy of your data

Think about what goes into a typical prompt. Support tickets with customer names, source code from a private repository, contract text, internal financial figures. Each one goes to a third party, and without ZDR that third party may keep it for as long as its own policy allows, which you did not write.

A retained prompt widens your attack surface and your compliance scope. A breach at the provider exposes it, and a legal request can reach it. If the content is personal data, rules such as GDPR expect you to limit storage to what you need, which is hard to show when a vendor holds copies you cannot delete on demand.

A prompt that is never stored cannot leak or be requested later.

Retention, training and logging are not the same thing

Buyers often treat "we don't train on your data" and "we don't keep your data" as the same promise. They are not. Retention is about storage, training is about reuse, and logging is about why the storage happens. A provider can promise one and still do the others.

Routers that list provider policies make the gap visible. OpenRouter notes that some endpoints do not train on your data but still retain it, for example to scan for abuse or meet legal duties. So a "no training" claim is weaker than ZDR, because the data still exists somewhere.

Who needs it

ZDR pays off when the data in your prompts is sensitive, regulated, or covered by a customer contract. It is overkill for public text, and it costs you some features, so match it to the risk.

• Healthcare teams. HIPAA coverage of an AI tool often depends on retention terms. Anthropic's documentation, for example, says organizations without its HIPAA configuration still need ZDR for BAA coverage of Claude Code.
• Legal and finance teams. Client confidentiality and audit duties make a vendor-held copy of a prompt hard to justify.
• EU and UK companies. Data minimization and storage limitation under GDPR are easier to satisfy when the processor keeps nothing.
• Software vendors. Your own enterprise customers may forbid sub-processors from storing their data, and ZDR lets you pass that term down.

How to get zero data retention for an API

To get zero data retention on an API, either choose a provider where it is the default, or ask a provider that grants it by approval, and then make sure your traffic flows through the covered account. Most failures happen in that last step, not in the request.

Three routes to ZDR

Providers grant ZDR in three different ways, and the route decides how much work you do.

Default is the least effort. Approval gives you ZDR on a specific vendor's own models, at the price of a review. A router helps when you mix models from many vendors and want one switch that filters them all.

Steps to enable it

Work through these in order. Skipping the early steps is how teams end up with ZDR on paper and stored prompts in practice.

1. Classify your data. Write down which prompts contain data that must never be stored.
2. Inventory what you use. List the models, endpoints and features. Anything stateful, such as stored files, saved sessions or cloud-hosted agents, may be unavailable under ZDR.
3. Confirm eligibility. Ask the provider whether your models and features are covered, and get the answer in writing.
4. Request enablement. For approval-based providers, go through sales or your account team. Anthropic says each new organization needs its own enablement.
5. Scope your traffic. Use only keys and logins that belong to the ZDR organization. Anthropic provides forceLoginMethod and forceLoginOrgUUID managed settings so developers cannot sign in with personal accounts.
6. Test and keep evidence. Send a request, check that your provider dashboard shows metadata only, and file the result next to the agreement.

What providers look at when you ask

ZDR is usually a contract and an account setting, not a checkbox. OpenAI's community guidance describes it as available to trusted customers with sensitive applications. Anthropic says ZDR for Claude Code is available to qualified accounts on Claude for Enterprise, is not part of the standard plan, and cannot be switched on from admin settings.

Expect to describe your use case, your company and the data involved. Ask early, because enablement is a manual review rather than an instant toggle.

If you need ZDR for a launch, start the request weeks before it, not the day before.

What zero data retention covers and what it leaves out

ZDR covers the content of your inference calls, meaning the prompts you send and the responses the model generates. It does not cover everything around them, and every provider lists exceptions. Read those exceptions before you promise anything to your own customers.

What is covered

The core promise is simple. Anthropic's documentation says that with ZDR enabled, prompts and model responses are processed in real time and not stored after the response returns. OpenAI makes the same promise for eligible API customers and adds that customer content is not available to its personnel for review. OpenRouter describes ZDR as a provider not storing your data for any period of time.

That promise applies to inference content, and it applies at the level the provider enabled it. It may be per organization, per workspace or per request. A request made outside that scope is not covered.

Exceptions to expect

Providers keep a short list of things even under ZDR. The table lines up what the sources say.

The pattern is clear. ZDR removes your content from storage. It does not remove records that show you were a customer, and it does not reach services that the provider does not run.

Features you give up

Anything that needs the provider to remember something conflicts with ZDR. Anthropic disables these features at the backend for ZDR organizations on Claude for Enterprise:

• Cloud sessions, including those started from the desktop app
• Claude Tag, which retains channel memory and session transcripts
• Artifacts
• Feedback submission through /feedback, /bug and /share
• Remote Control, which stores the session transcript to sync across devices

Models can be affected too. Anthropic's documentation says its Fable models are Covered Models that require data retention by default, and that whether a ZDR organization can use them is decided by the Covered Models policies. Where it cannot, the models are absent or disabled and the server rejects requests for them. So if you ask whether you must give up ZDR to use those models, the documented answer is that retention requirements decide access, and you should confirm with your account team before you plan around them.

Debugging also gets harder, because you cannot ask the provider to replay a failed request. Keep your own minimal, scrubbed logs and treat them as data you are now responsible for.

Under ZDR you trade provider-side convenience for control, so decide which features you can live without.

How OpenAI, Anthropic and OpenRouter handle ZDR

OpenAI and Anthropic grant ZDR to approved customers on their own platforms, while OpenRouter enforces it as a routing rule across many providers. The three differ in who can ask, at what level ZDR applies, and what they still keep.

The three approaches side by side

The first two are contracts with the model maker. The third is a filter that depends on how accurately OpenRouter records each endpoint's policy.

OpenAI

OpenAI describes ZDR as a clear promise to eligible API customers: it does not retain prompts or model responses after a request is processed. Content is not available to its personnel for review, and enterprise customer data is not used to train models unless customers opt in.

The interesting recent development is Private Safety Processing. OpenAI argues that serious risks can show up only across several interactions, so per-request checks are not enough. Private Safety Processing looks for patterns across related interactions without giving OpenAI staff access to the content. In ZDR deployments, content stays on infrastructure the customer controls. OpenAI is also building an option where content sits on its infrastructure, encrypted with keys the customer holds. Its September 22, 2026 update says the rollout to API customers is phased.

When a risk is found, OpenAI receives a narrow signal about the type of activity, not the content itself. Customers can investigate using their own systems and choose what to share if they appeal.

Anthropic

Anthropic offers ZDR for Claude Code on Claude for Enterprise. It is not in the standard plan and is enabled per organization by your account team after an eligibility check. All enablement actions are audit-logged.

Two details trip people up. First, ZDR applies only to requests that authenticate into the ZDR organization. A developer who signs in with a personal account or an API key from another organization is not covered, which is why the managed login settings matter. Second, ZDR on Claude for Enterprise applies only to Anthropic's direct platform. If you run Claude on Amazon Bedrock, Google Cloud or Microsoft Foundry, those platforms' data retention policies govern instead.

Teams using ZDR through pay-as-you-go API keys can move to Claude for Enterprise to gain administrative features, including cost controls per user, an analytics dashboard, server-managed settings and audit logs, while keeping ZDR. Coordinate that through your account team.

OpenRouter

OpenRouter sits between you and many providers. It tracks each endpoint's data policy and, when you enable ZDR, routes only to endpoints with a zero retention policy. If it cannot establish a provider's policy, it assumes the endpoint retains and trains on data and marks it that way. That conservative default is what you want from a filter.

You can enforce ZDR globally, per model group, per guardrail, or per request. The request-level parameter works as an OR with your other settings, so it can add enforcement but never switch off account-wide enforcement.

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

Two limits apply. ZDR enforcement covers provider routing for inference only, not plugins or tools like web search, which may run on third-party services. And OpenRouter does not count in-memory caching as retention, so cached endpoints stay eligible. If your policy forbids even transient caching, check each endpoint.

A router can only be as accurate as the endpoint policies it records, so verify the ones you depend on.

What to put in a zero data retention agreement

A good zero data retention agreement names the endpoints covered, the content that is never stored, the exceptions, and the way you will be told if terms change. Your internal ZDR policy then decides which data may use which vendors. The two documents work together, and neither is enough alone.

Write your internal ZDR policy first

Your policy is the rulebook for your own engineers. It should be short enough that people read it. At a minimum, state these points:

• Which data classes must only go to ZDR-covered endpoints, such as customer personal data, health data, credentials and unreleased source code
• Which providers and models are approved, and who can approve a new one
• Which keys, organizations or workspaces are the ZDR ones, and how developers are kept from using others
• Whether prompts may be logged in your own tools, and for how long
• Who reviews the vendor terms when they change

Without this, the vendor's promise covers one request path while engineers use another.

Clauses to look for in the vendor agreement

Whether the paper is a formal agreement or a published policy, look for specifics. Vague language such as "we minimize retention" is not zero. Check for a clear definition of covered content, a list of covered endpoints and models, a statement on training use, the exceptions and their maximum duration, the metadata kept, and a commitment to notify you of breaches. Geodd, for instance, commits to notify customers of personal data breaches without undue delay and, where feasible, within 72 hours.

Copy these questions into an email to any provider and keep the answers on file:

1. Which endpoints, models, and features are covered by ZDR, and which are excluded?
2. Is ZDR applied per organization, per project, or per API key?
3. What content, if any, is retained for abuse or legal reasons, for how long, and who can access it?
4. What metadata do you keep (account IDs, token counts, timestamps), and for how long?
5. Is any content used for training or evaluation in any form?
6. Which subprocessors handle request content, and do they also retain nothing?
7. How will you notify us of changes to these terms or of a breach?
8. Can you confirm these terms in writing, with the date they took effect?

Your own systems can break ZDR

The most common way to lose ZDR is on your side of the API. If your application logs full prompts to an observability tool, stores conversations in a database, or sends traces to a third-party debugger, the content is retained anyway, just by you and your vendors. Review your tracing, error reporting and analytics settings, and scrub or truncate prompt content before it is logged.

ZDR protects the provider's side of the call, and you are responsible for your own side.

Zero data retention at Geodd

Geodd runs three of its main text models with zero data retention by default: GLM 5.3 Flash, DeepSeek V4.1 Flash and GPT-OSS-120B. You do not need an approval process to get it, because it is the standard data handling for those endpoints. Use the table to compare them.

The three ZDR-by-default text models

To see what this costs, take a workload of 10 million input tokens and 2 million output tokens. On GLM 5.3 Flash that is 10 × $0.110 plus 2 × $0.400, or $1.90. On DeepSeek V4.1 Flash it is 10 × $0.300 plus 2 × $1.100, or $5.20. On GPT-OSS-120B it is 10 × $0.039 plus 2 × $0.158, or about $0.71.

What default ZDR means in practice

Geodd does not store API prompts, outputs or uploaded files unless that is separately agreed in writing, and it does not use API data for model training. The exceptions follow the pattern described earlier: Geodd keeps billing and financial usage records for 7 years, which are records of usage, not of your prompts. For EU customers, API inference is hosted in EU data center infrastructure by default. Geodd is GDPR ready, and its SOC 2 compliance is pending, so if your procurement team requires a finished SOC 2 report, treat that as an open item.

Privacy and data protection questions go to [email protected], and security and abuse reports go to [email protected].

Trying it without a rewrite

The API is OpenAI-compatible, so an application that uses the OpenAI SDK can switch by changing the base URL, the API key and the model ID. The model IDs are zai-org/glm-5.3-flash, deepseek-ai/DeepSeek-V4.1-Flash and openai/gpt-oss-120b. Before you move production traffic, run the checklist from earlier: confirm the data handling line on the model page, ask the question list above in writing, and check that your own logging does not capture prompts.

If ZDR is the default, your job shrinks to verifying it and keeping your own logs clean.

Start with the data, then pick the provider

Zero data retention means your prompts and responses are processed and then discarded, with a short list of exceptions for law, abuse and billing. The useful questions are about scope: which endpoints, which organization, which exceptions, and what your own systems keep. Get the answers in writing, scope your keys to the covered account, and test the setup before you rely on it.

If you want ZDR without a review process, you can browse Geodd's catalog of models and check the data handling line on each model page.