Zero Data Retention for LLM Inference: What a Fixed Plan Guarantees (2026)

Every inference provider says it protects your data. Far fewer spell out, in their own docs rather than their marketing page, what that protection covers once a request lands on a GPU shared with other customers. Zero data retention (ZDR) is a specific, checkable claim: a provider agrees not to store your prompts or outputs after it returns a response, under whatever conditions its policy carves out. "We don't train on your data" is a looser, different claim, and providers routinely let the two blur together. This post reads OpenAI, Anthropic, OpenRouter, Together, Fireworks, DeepInfra and Groq's own ZDR documentation side by side and shows where shared-tenancy serving still leaves a gap that only single-tenant, reserved capacity closes structurally.

TL;DR: What Zero Data Retention Actually Guarantees

Zero data retention means a provider doesn't store your prompts or completions after it returns a response, but the scope, the opt-in process, and the exceptions differ by provider.

See Spheron's managed inference plans for how a fixed-price, reserved-GPU plan handles this differently from a shared endpoint.

Zero Data Retention vs "We Don't Train on Your Data": Two Different Promises

Zero data retention and "we don't train on your data" are not the same promise. Not training on your data only says a provider won't use your prompts and outputs to improve its models; it says nothing about whether that content is stored, for how long, or who can access it. Zero data retention is the narrower, stronger claim: the provider agrees not to retain your request and response content past the lifetime of the API call itself. A provider can honestly make the first promise while still logging every prompt for debugging or abuse review for weeks.

The split shows up architecturally, too. Some providers run requests through with no persistent write at all, a true pass-through. Others sync request and response data into a cache, a log store, or a files API to support features like retrieval or prompt caching, even on a platform that says it doesn't train on that data. DeepInfra's own docs draw this line precisely: its data privacy documentation says submitted data isn't used for training, except for requests routed to Google- or Anthropic-hosted models, where that model maker's own policy applies instead. "Doesn't train on it" and "doesn't store it" depend on which model you called and who actually served it, not just which provider's logo is on the invoice. The same split between a cost decision and a privacy decision shows up in Grok 4.5's API pricing compared against self-hosting, where the cheaper option on the invoice and the more private option for your data aren't automatically the same choice.

What OpenAI, Anthropic, OpenRouter, Together and Fireworks Say in Their Own Docs

Does OpenAI have zero data retention? OpenAI offers ZDR, but not for every endpoint, and the carve-outs are easy to miss on the trust page alone. The shape still tracks what you'd expect: an endpoint built around storing something, a thread, a file, a batch job, is structurally harder to make zero-retention than a stateless chat completion.

Does Claude (Anthropic) offer zero data retention? Yes, but as an enterprise arrangement, not a setting you flip yourself. Anthropic's own data retention documentation states that "under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned." Getting it means contacting Anthropic sales to enable it per organization, and it doesn't automatically extend to other organizations under the same account. ZDR also doesn't cover the Claude Console, Claude Managed Agents, the consumer Free, Pro, Max, and Ultra plans, the Teams and Enterprise product interfaces (Claude Code on Enterprise is a separate, covered offering), or Claude for Excel.

Even with ZDR active, Anthropic can retain a flagged session for up to two years if its automated trust and safety systems catch something in it, a safety carve-out worth knowing about before treating the guarantee as absolute. One more wrinkle: organizations under Anthropic ZDR can't call the Claude API directly from a browser, since the API rejects their cross-origin requests, so every integration has to proxy through a backend.

Three more providers are worth reading closely before assuming "ZDR available" means the same thing everywhere:

Two more follow the same pattern. DeepInfra's docs say inference inputs are held only in memory while a request is processed and aren't written to disk, with a Zero Data Retention commitment written into its Terms of Service that governs over the rest of its documentation. The common thread across all seven: every provider here treats ZDR as a conditional state reached by configuration, contract, or model choice, never as a property of the platform itself.

Where Shared-Tenancy Serving Still Leaves a Gap

Even a provider with a genuine, well-documented ZDR policy is running your request on infrastructure built for throughput across many customers, not for isolating one customer's data path. Two mainstream serving techniques show why the gap is structural, not a matter of any one provider trying harder.

Semantic caching stores a vector representation of past prompts so a new, similar request can skip recomputation and hit a cache instead of the model. That's exactly the kind of feature Together AI's ZDR toggle disables when prompt storage is turned off: a cache that works has to persist something, even briefly, or it isn't a cache. A provider offering both prompt caching and ZDR at once is making two claims that pull in opposite directions, and it's worth reading how it resolves that tension before assuming both apply to the same request.

Prefill-decode disaggregation splits a request's prompt processing and token generation across separate GPU pools for throughput, which means the prompt and the response for one customer's call can physically traverse more than one node before the answer comes back. Nothing here makes end-to-end ZDR impossible, but "zero retention" has to be verified at every hop a request takes through a shared fleet, not assumed from a single policy statement at the edge.

None of this is a reason to assume the worst about any provider above; it's a reason to ask a more specific question than "do you offer ZDR": does the agreement cover every stage a request passes through shared infrastructure, or just the endpoint you call directly? For regulated buyers who'd rather not have to ask that question at all, running inference on-premise instead of in the cloud removes it entirely, at the cost of taking on the hardware and operational burden the cloud was handling for them.

Getting Zero Data Retention on Reserved GPUs With a Fixed-Price Plan

A single-tenant reserved node sidesteps this whole class of question rather than answering it feature by feature. If a request is the only thing running on that GPU, there's no shared cache to account for and no other tenant's traffic sharing the serving path.

Spheron's managed inference plans are built around that structural answer. The API is OpenAI-compatible, so switching off a per-token router doesn't require rewriting an integration, just repointing one.

That comes with real limits worth knowing before requesting a quote. Only three models currently run on these plans, GLM-5.3, GLM-5.3-Flash, and DeepSeek V4.1 Flash, so a team tied to GPT, Claude, or Gemini gets no ZDR option through this plan; Anthropic and OpenAI's own arrangements, limitations included, remain the only path for those models. Starter and Growth are reserved capacity, not single-tenant hardware, so only Dedicated actually removes the shared-tenant question, and Dedicated requires 50 billion counted tokens a month and up, a volume most teams aren't running yet. Growth also carries a 3-month term, so a team still validating its compliance requirements has to start on Starter or stay on a per-token provider meanwhile. Plan pricing is quoted rather than published, so there's no public rate to compare against a shared provider's per-token price without asking for one. If the economics of a term commitment, rather than the data-handling guarantee, are the open question, the breakeven analysis between fixed-price and pay-as-you-go inference pricing works through when a commitment pays off.

For a team that needs ZDR today on a model a shared provider above already serves, reading that provider's own data retention docs line by line, not its trust page, is still the right first move. For a team where the model is flexible and the retention guarantee needs to be structural rather than contractual, reserved single-tenant capacity is the more direct answer.

If your zero data retention requirement is about where the model runs, not just what a shared provider promises in its terms, reserved single-tenant capacity closes that question structurally rather than contractually.

Request a Spheron inference plan →