Zero Data Retention: How Blackbox Enforces It By Default

Prompt and response content is not retained. Zero Data Retention is applied to every request by default, and where we cannot meet it, we reject the request rather than serving it without protection. Usage metadata required for billing is retained — the details are below.

What Zero Data Retention covers

Zero Data Retention (ZDR) applies to the content of your requests: your prompts, the model's responses, reasoning output, and tool inputs and outputs. That content is used to answer your request and then discarded. It is not written to durable storage, and it is not used for training.

ZDR is a statement about content. It is not a statement that we record nothing at all — we retain the operational metadata needed to bill and run the service, listed explicitly below.

What we retain, and what we don't

We publish this split deliberately. A ZDR claim that implies literally nothing is recorded would not survive a security review, and it isn't what any provider — including us — actually does.

Our three commitments

1. It's on by default

Zero Data Retention is applied automatically to every request. It is not a setting you switch on, not a parameter you must remember, and not limited to a particular plan.

Requests are routed only to destinations operating under a Zero Data Retention standard.

2. Where we cannot guarantee it, we reject the request

A small number of models have no route meeting our Zero Data Retention standard. There are two honest options: refuse the request, or serve it without the protection.

We refuse. The request fails with an explicit error stating that Zero Data Retention could not be guaranteed.

The alternative — silently serving without ZDR — would leave you believing your data was protected when it was not. Our system is built so that cannot happen.

3. No accidental path to non-ZDR

Zero Data Retention is not switched off at the account level, and is not lost through a missing parameter, a default, or an automatic fallback to another route. Waiving it requires a deliberate, explicit instruction on an individual request.

The trade-offs — what ZDR costs you

Zero Data Retention is a real constraint, not a free label. Being straightforward about the cost:

A smaller pool of routes. Only destinations under a ZDR agreement are eligible. That means less redundancy during an upstream incident, and occasionally higher latency or reduced throughput than an unconstrained routing policy would achieve.

Some models are unavailable. Where no compliant route exists, the model cannot be served at all — the request is rejected rather than downgraded.

No server-side conversation state. For models that would normally retain state between turns, that state cannot be held for you. It is returned to you in encrypted form and must be passed back on the next turn, which makes request payloads larger on long conversations.

Reduced ability to debug on your behalf. Because we do not retain your prompts or responses, we cannot inspect a past request to diagnose an issue. Investigating a quality or correctness problem requires you to supply a reproduction. This is the trade-off customers feel most often in practice.

Possible cost differences. The ZDR-eligible pool is smaller, so pricing and performance may differ from an unconstrained policy.

We think these are the right trade-offs for enterprise workloads. You should know you are making them.

Prompt caching under ZDR

Some models support caching of repeated prompt content, reducing cost and latency on long or repetitive requests.

This caching is held in memory on the serving side and is not written to durable storage, so we treat it as compatible with Zero Data Retention. If your policy requires that no copy of prompt content exists anywhere, even transiently in memory, tell us — that is a stricter standard than ZDR and needs to be handled separately.

Models with enforced stateless operation

Certain reasoning models are run with server-side storage disabled on every request, regardless of what is sent. Conversation state cannot be retained on the serving side, so it is returned to you encrypted, unlocked in memory only to produce the next response, then discarded.

The practical result is full continuity across multi-step conversations without state being stored anywhere.

Our own policy

Blackbox does not retain your prompts or responses, and does not use them for training.

Where we cannot establish or verify a clear data policy for a route, we take the conservative position: we assume it retains and trains on data, and route away from it.

Frequently asked