Data privacy on 0G Private Computer

Zero data retention by policy. Sealed inference by hardware. One of them you do not have to take on faith.

Most AI APIs ask you to trust a privacy policy. The policy says your prompts are never stored and never used for training, and you have no way to check any of it. For an exchange or a healthcare platform routing customer data through an LLM, "trust us" is not a compliance posture.

This page describes exactly what happens to your data on 0G Private Computer (pc.0g.ai): what we retain, what we never store, and how to enforce the strictest privacy tier per API key or per request.

Zero data retention

0G Private Computer operates with zero data retention on inference content. Prompts and completions pass through the Router in memory for the lifetime of the request and are never written to storage. There is no conversation table and no response archive; billing records carry metadata only.

What we do retain is billing and usage metadata, such as request ID, wallet address, model, provider, token counts, trust tier, and cost. This is what powers your usage dashboard and monthly statements. It contains no request content.

Three clarifications most providers leave out:

• Multipart inputs are not stored. Audio and image inputs pass through the Router in memory for the lifetime of the request and are never persisted. The Router does not store generated images and keeps no long-term copy of user content.
• 0G does not train on your data. Content that is never stored cannot be used for training.
• Web search is opt-in. If you turn it on for a request, a search query built from your prompt goes to a third-party search provider.

ZDR at the platform layer is a policy, and we hold ourselves to it. But we also think you should not have to stop at policy. On 0G, privacy comes in two levels of removal, and you choose how far to go:

1. Policy: the Router retains no content (this section).
2. Hardware: privacy mode routes only to models sealed inside TEE enclaves, where no one can see the inference at all (next section).

Beyond ZDR: privacy mode

Everywhere else in the industry, ZDR is where the privacy conversation ends. On 0G it is where it starts, because a retention policy still requires you to trust the operator enforcing it. Privacy mode removes the operator from the trust equation.

In privacy mode, your request is served only by models running inside a Trusted Execution Environment: an Intel TDX enclave paired with TEE-enabled GPUs. The model loads inside the enclave, your prompt enters the enclave encrypted, the response is signed inside the enclave before it leaves, and the host machine sees only encrypted traffic in and out. Inside the enclave, the inference is invisible: neither 0G nor the provider operating the hardware can see the data or the computation.

Every enclave publishes a hardware attestation, verifiable through dstack. Instead of reading a policy document and hoping, you check a cryptographic proof that the code and the environment are exactly what we say they are. We call this Sealed Inference, and it is the difference between a promise and a property.

Encrypted Transit extends that protection to the path before the enclave. On supported models, your request is encrypted inside an attested TEE gateway and crosses the Router as ciphertext, so the Router never sees your prompt. Served by a Private (TeeML) provider, the request is end-to-end encrypted: it exists in plaintext only inside the gateway and provider enclaves. Today this covers GLM-5.3, 0GM-1.0-35B-A3B, Qwen3 Embedding 8B and Qwen3 Embedding 0.6B. Use a Private API key to make sure your request lands on a TeeML provider. On other models, the Router reads a request in memory to route it and stores none of it. How verification works shows the full path, what the Router can still see (model name, token usage, message sizes and timing), and how to check the gateway yourself.

Three trust tiers

Every request on the 0G Compute Router resolves to one of three routing tiers. You pick per key or per request:

verified is a floor, not an exact match: an enclave-hosted provider also satisfies a verified request, since running the model inside the TEE gives you everything path attestation does and more.

The tiers map to two verification mechanisms. TeeML means the model itself runs inside the enclave. TeeTLS means the model is hosted upstream by a centralized provider, and 0G's broker, itself running inside a TEE, relays your request over TLS and signs a routing proof binding the request hash, response hash, provider identity, and the provider's TLS certificate fingerprint. The broker cannot read or modify your data in transit. 0G acts as a verifiable relay, not a middleman.

The honest caveat: with TeeTLS, the upstream provider still processes your prompt under its own data policy. We said the same thing when DeepSeek V4 Pro went live: TeeTLS is a smaller-scope guarantee than TeeML, and we do not pretend otherwise. Standard Routing goes further: it places no restriction on the provider pool, widening the catalog to third-party channels that are non-verifiable. Standard endpoints publish no attestation and no signed proof, so there is nothing to check on the response. Many models are served only on this tier today, including the Claude, GPT and Gemini families, and the live list is always GET /v1/models. If your requirement is that no third party ever sees plaintext, use private.

One default matters here: a request that does not pin a tier can be served by any provider of the model, including Standard Routing ones, and the model list shows each model by its highest-capability provider. Selecting the model is not the same as selecting the tier. If you need the enclave, set the tier.

How to enable privacy mode

Two mechanisms, depending on whether you want the guarantee per key or per request.

Pin it to an API key. In pc.0g.ai, open Dashboard, then API Keys, and set the key's trust mode to Private. Every request made with that key routes only to sealed-inference providers. No code changes, and nobody holding that key can accidentally downgrade it. The same field is available programmatically: POST /v1/api-keys with "trust_mode": "private".

Send it as a request header. Add X-0G-Provider-Trust-Mode: private to any individual request:

from openai import OpenAI

client = OpenAI(
    base_url="https://router-api.0g.ai/v1",
    api_key="sk-YOUR_API_KEY",
    default_headers={"X-0G-Provider-Trust-Mode": "private"},
)

If no sealed-inference provider is available for the requested model, the request fails with 503 no_provider_for_trust_mode. It never silently falls back to a lower tier.

Models with privacy mode

As of October 2026, nine models on the Router run inside enclaves and accept private requests:

The catalog changes as providers join the network, so the live source of truth is the models endpoint: any model with "verifiability": "TeeML" in GET https://router-api.0g.ai/v1/models accepts privacy mode. No authentication required to check. A model can carry both enclave and relay providers at once; the per-provider breakdown is on each model's detail page at pc.0g.ai, and the Encrypted Transit filter on the models page shows which models are end-to-end encrypted.

Audit it, then verify it

Privacy claims are only useful if your compliance team can check them after the fact.

• Responses carry a trace with the request ID and the serving provider's address. On private and verified routes, add verify_tee: true and the trace also reports whether the provider's TEE signature verified.
• On Encrypted Transit requests, that check moves from the Router to the gateway: it seals only to a provider whose hardware attestation it has verified, and it verifies the signature on every response.
• Account usage endpoints break down consumption by trust tier, so you can show exactly which share of your traffic ran sealed, per day and per model.
• The Encrypted Transit gateway can be checked with one command, described on How verification works.
• Provider attestations can be independently verified with dstack-verifier, and container image integrity through sigstore. The data privacy and ZDR reference, the verification modes documentation, and the trust modes reference cover the full mechanics.

FAQ

What does 0G retain from my API requests?

Billing and usage metadata only, such as request ID, wallet, model, provider, token counts, trust tier, and cost. Never prompt or completion content. Multipart inputs pass through in memory and are never stored.

What is the difference between verified and private?

verified guarantees the response came from the real model, whether that model runs in an enclave on 0G or upstream at a centralized provider behind a TEE relay. private adds the stronger condition: the model itself runs inside the enclave, where neither 0G nor the provider can see the inference.

How do I make sure my whole team only uses sealed inference?

Create your production API keys with trust mode set to Private. The pin lives on the key, not in the code, so every request through those keys is enclave-only regardless of what the calling code sends. If a model has no enclave provider, those requests fail loudly with 503 no_provider_for_trust_mode instead of quietly routing somewhere weaker.

Get started at pc.0g.ai. Full API documentation at docs.0g.ai. For enterprise privacy requirements, reach out through 0g.ai.