Zero Data Retention Routing Across NanoGPT
A model can be available through several infrastructure routes, each with different terms for prompts and responses. A Zero Data Retention badge on one route does not help if a fallback quietly sends the request somewhere else.
NanoGPT now treats Zero Data Retention as an enforceable routing rule. Turn on ZDR only, and eligible routes are filtered before a request is sent. Provider pins, automatic routing, direct routes, and fallback attempts all have to satisfy the same policy. If none can, the request fails instead of dropping the privacy requirement.
One account setting for web chat and API keys
The account-wide control is in Settings under Privacy & Analytics:
- ZDR only restricts requests to routes classified as Zero Data Retention.
- Anonymized keeps standard routing available. NanoGPT does not attach your account identity, but the model input is still sent for inference and there is no provider-side promise of no retention or no training.
API keys can carry their own policy
An API key can use ZDR only or Anonymized independently of the account default. This makes it possible to keep a general-purpose key on ordinary routing while requiring ZDR for a service that handles more sensitive text, or to do the reverse when an integration needs a model without a compatible ZDR route.
New keys receive an explicit policy aligned with the account at creation. A key created under a ZDR-only account starts as ZDR only; other new keys start as Anonymized.
The setting is available in the API-key editor and through the Management API as zdr_policy. API clients receive the error code zdr_provider_required when the policy cannot be satisfied. That gives an integration a clear choice: select another model, change the key's policy, or stop the task.
Fail closed includes fallbacks
Restricting the first route would leave a large gap. Model APIs retry for ordinary reasons such as temporary capacity limits, unsupported request parameters, or an empty response. Each fallback therefore receives the same ZDR requirement as the original attempt.
Explicit provider selections are checked too. Choosing a provider, setting an allowed-provider list, or adding a maximum-price constraint cannot force the request onto a route that fails the active ZDR policy. If the remaining constraints leave no eligible route, NanoGPT returns an error rather than relaxing one of them behind the scenes.
This can make ZDR-only requests less available than Anonymized requests during an outage. That is intentional: the setting prioritizes the retention rule over completing the request.
Auto Model now respects the same boundary
Auto Model chooses a model and route after looking at the request. That decision now happens inside the ZDR boundary rather than before it.
With ZDR only enabled, Auto Model considers only candidates that can complete the requested task through an eligible route. Tool requirements, provider restrictions, excluded providers, and maximum-price settings still apply. If no candidate satisfies the full request, automatic selection returns the same ZDR routing error instead of choosing a non-ZDR alternative.
Some model pages show separate Auto prices for ZDR and Anonymized routing. The eligible route pools can differ, so the cheapest available route can differ as well. Check the displayed price for the active privacy setting rather than assuming both modes cost the same.
Team policy follows team billing
Team owners and admins can enable Zero data retention only in the team's Settings tab. For requests billed to that team, the team setting acts as a minimum: a member or API key cannot weaken it to Anonymized.
The boundary follows the payer. A team member's personally billed request continues to use that member's account or API-key setting. This keeps the privacy rule aligned with the team activity it is intended to govern without changing unrelated personal work.
What the ZDR label promises
NanoGPT classifies a route as ZDR when its provider states that prompt data is not retained or used for training on that route. NanoGPT uses that classification to control routing, but cannot inspect or independently audit a provider's infrastructure. The setting is therefore a best-effort, provider-declared commitment rather than a cryptographic proof.
For normal inference, NanoGPT does not log or retain prompt and response content by default. API request and response logging is a separate, optional feature controlled by the API-key owner; enabling it stores content regardless of the provider-routing choice.
PII redaction is separate again. It removes common personal information and likely secrets before a standard request is forwarded, but it does not by itself impose a provider-side retention policy. These controls can address different parts of the same privacy requirement, but they are not interchangeable labels.
The account setting is available at nano-gpt.com/settings#zdr-routing. API-key policies can be reviewed in the API dashboard, and team owners can set the team-wide minimum from the team Settings tab.
