Claude ZDR (Zero Data Retention)

What ZDR Is — Meaning and Scope

Zero Data Retention (ZDR) is a contractual agreement under which Anthropic does not store the input/output that passes through the Claude API after the response is returned to the caller, except where required by law or to detect policy abuse.

Compared with Anthropic's default retention — since 14 September 2025, Anthropic reduced API retention from 30 days to 7 days (for commercial customers) — ZDR makes retention 0 days (deleted immediately).

What ZDR Covers

• Claude API (Messages API, Files API) used with a commercial organization API key
• Claude Code when used via a commercial organization API key
• Other Anthropic products that use a commercial org API key (depending on Anthropic's definition at each point in time)

What ZDR Does Not Cover

• Consumer interfaces: claude.ai web, Claude Desktop, Claude Mobile
• Claude Team / Enterprise web app: users working through the UI directly (not the API)
• So if a team in your organization works via the claude.ai web — even if the organization has signed ZDR — that UI traffic is not covered

The Common Misconception: "ZDR Makes Claude Forget — Do I Have to Re-explain Every Time?"

This question comes up very often, and the straightforward answer is — ZDR has nothing to do with whether "Claude remembers or forgets", because the Claude API is already stateless by nature on every plan, whether or not you sign ZDR.

What "Stateless API" Means

It means that every time you call the Claude API, you must send the full messages array of the conversation history — Claude does not "remember" what was discussed with whom previously, because each API call is an independent request with no session.

For example — if a user chats with your chatbot for 3 turns:

# Turn 1
messages = [
  {"role": "user", "content": "Hi, can you explain Claude?"}
]

# Turn 2 — must send the full history
messages = [
  {"role": "user", "content": "Hi, can you explain Claude?"},
  {"role": "assistant", "content": "Claude is an AI..."},
  {"role": "user", "content": "And what is ZDR?"}
]

# Turn 3 — send the history of every previous turn
messages = [
  ...(all previous messages)
  {"role": "user", "content": "Is ZDR right for our organization?"}
]

This is standard behavior of the Claude API on every plan, not specific to ZDR — so who stores the conversation history? The answer is you (the client), not Anthropic.

So What Is the 7-Day Default?

It is the log on Anthropic's side for:

• Policy abuse detection
• Debugging during a support ticket
• Anthropic's own compliance/audit

It is not Claude's "memory". The API caller does not use this log, and Claude does not "read" this log when generating a new response.

Therefore sending the full history on every call is something you must do in all cases, whether you choose ZDR or the 7-day default — ZDR only changes "how long Anthropic keeps logs" from 7 days to 0 days; it does not change how your application works.

Prompt Caching Works Normally with ZDR

A worry many people have — if ZDR deletes everything, does prompt caching (the feature that reduces cost and increases speed when there is a repeated system prompt or context) still work?

The answer: it works normally — both automatic caching and explicit caching. Anthropic confirms that the KV (key-value) cache representation and the cryptographic hash of cached content are held in memory only, not retained at rest, which satisfies the ZDR definition.

An Important Change on 5 February 2026

Since 5 February 2026, Anthropic changed the prompt cache from organization-level isolation to workspace-level isolation on:

• Claude API
• Claude Platform on AWS
• Microsoft Foundry (beta)

Meanwhile AWS Bedrock and Google Vertex AI remain organization-level as before. This change matters for organizations with a multi-workspace setup under one org — the cache is separated by workspace, preventing data leaks between workspaces.

Pros and Cons of ZDR

How You Must Store Context Yourself — Architecture Pattern

Since the Claude API is already stateless, and ZDR does not change this behavior — your application must store conversation state itself in all cases. The following are patterns usable for both the default and ZDR cases.

1) A Basic Conversation Persistence Layer

Store the messages in your own database (PostgreSQL, MongoDB, DynamoDB, Redis, etc.) and assemble the messages array before every API call:

# Pseudo-code (Python + anthropic SDK)
def chat(conversation_id, user_message):
    # 1) Load history from your DB
    history = db.get_messages(conversation_id)

    # 2) Call the Claude API with the full history
    response = anthropic.messages.create(
        model="claude-opus-4-7",
        max_tokens=1024,
        messages=history + [{"role": "user", "content": user_message}]
    )

    # 3) Save the new turn back to the DB
    db.save_message(conversation_id, "user", user_message)
    db.save_message(conversation_id, "assistant", response.content[0].text)

    return response.content[0].text

2) Long Conversation → Summarization

When a conversation gets so long that the context window starts to fill up (Claude Opus 4.7 has a large context, but it still has a limit and the token cost grows with length), use rolling summarization:

• Keep the system prompt + a summary of the old history + the latest 10–20 turns
• When the history reaches a threshold, summarize it into "Up to turn N: [summary]" and reset the memory window
• This summary can be produced by Claude itself — call the API with a "Summarize this conversation:" pattern

3) Cross-session Knowledge → Vector Store + RAG

If you want Claude to "know" permanent organizational data (HR policy, SOPs, product knowledge) — do not store it in the conversation, but put it in a vector database (pgvector, Pinecone, Weaviate, etc.) and retrieve the relevant chunks into the prompt at inference time (RAG pattern).

4) The Important Thing Not to Forget — Your DB Is the Source of Truth

Once you use ZDR, your conversation history lives with you alone. Anthropic has no backup — if the DB is corrupted / hit by ransomware, the data cannot be recovered. Therefore:

• Back up regularly (with restore drills to test)
• Encrypt at rest (because you are now the holder of sensitive data)
• Strict access control — who can access the conversation log
• Your own retention policy — if ZDR has Anthropic keep 0 days, how many days do you keep? What is your deletion policy?
• Your own audit log — who called the API, when, and did what (Anthropic no longer provides a log)

Should You Choose ZDR or Not — Decision Matrix

✓ ZDR suits	○ The 7-day default is enough
Banking · Healthcare · Defense · Government classified · legal services that do pre-deployment review by legal/security · industries with a data classification policy that forbids persisting in a third party · organizations that must report data sovereignty to the board/regulator	General SMEs · private companies with standard PDPA/ISO 27001 controls · using Claude for productivity work (writing/translating/analysis) · no specific requirement from a regulator · still want Anthropic to help with abuse monitoring + debugging

Steps to Enable ZDR through Grand Linux Solution

1. Consult our team — review the workload + risk profile to see whether ZDR is really worth it (some organizations ultimately choose the 7-day default because the trade-off is better)
2. Enterprise eligibility check — ZDR requires being an Anthropic enterprise customer first; we help prepare the use case + volume + submission documents
3. Review the addendum with legal — the Anthropic ZDR addendum is an English document; we help review it + brief your legal team on the key clauses
4. Sign the addendum with Anthropic — we coordinate both sides
5. Configure the API + caching workflow — set up the production environment correctly for ZDR
6. Conversation persistence implementation — our Claude Integration service helps implement the history-storage + audit-log layer on your side, ready for the ZDR architecture

See also: Claude Enterprise for Thai Organizations · Claude Integration & Solutions · Setting Up Claude Team to Pass Thai PDPA.

ZDR only changes "how long Anthropic keeps logs" — it does not change how you design your application. Every application using Claude must store conversation state on the client side regardless. Choose ZDR because of a real requirement, not because it sounds safer.

- Saeree ERP Team

Summary

ZDR is a powerful compliance tool for organizations in regulated industries — but it is not the default choice and it does not solve "will Claude forget", because the Claude API is already stateless. Every application using Claude must store conversation state on the client side regardless. ZDR only changes "how long Anthropic keeps logs", which matters for compliance/breach posture but does not change how you design your application.

The right decision is to choose ZDR if you have a real requirement from a regulator/policy/board, not to default to it — and then invest in keeping your own conversation log secure and encrypted. Grand Linux Solution is ready to help with both the decision and the implementation.

Factual note: the information in this article references the Anthropic Privacy Center, Claude API Docs, and Claude Code Docs, verified on 4 June 2026 — Anthropic's policies and technical details may change. Verify against Anthropic's official documentation before making contract-level decisions.