Trust Modes

A trust mode is a routing constraint: it restricts which providers are eligible to serve your request, based on what they can cryptographically prove. Set it with the X-0G-Provider-Trust-Mode header or on the API key itself.

At a glance

	standard	verified	private
Routes to	Any TEE-backed provider	TeeML and TeeTLS providers	TeeML providers only
Independently verifiable	No independent method disclosed by the upstream	Yes — the response provably came from the real model	Yes
Privacy guarantee	None — the upstream sees plaintext	None — the upstream sees plaintext	Prompts never leave the enclave
Typical use	Throughput-first work on non-sensitive content	Audit trails, research, anything where model substitution is the risk	Regulated data, personal data, proprietary prompts

verified and private are not two strengths of one guarantee. verified answers was this really the model I paid for. private adds who saw the plaintext. See Verification and TEE.

Standard — any TEE-backed provider

Use it when the content is public or low-sensitivity and you want throughput, but still want execution on TEE-backed hardware stated explicitly rather than left to chance.

What you give up: the upstream discloses no independent verifiability method, so you cannot prove after the fact which model produced the response.

curl https://router-api.0g.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ZG_API_KEY" \
  -H "X-0G-Provider-Trust-Mode: standard" \
  -d '{"model":"glm-5.2","messages":[{"role":"user","content":"Hello"}]}'

Full walkthrough: Quickstart.

Verified — provable execution

Use it when model substitution is the risk you care about: audit trails, research, benchmarks, anything where you need to show the response came from the model you asked for and not a cheaper substitute.

Routes to TeeML and TeeTLS providers. The response can be proven to come from the real model. The upstream still processes your prompt in plaintext under its own data policy — this tier is about provenance, not secrecy.

curl https://router-api.0g.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ZG_API_KEY" \
  -H "X-0G-Provider-Trust-Mode: verified" \
  -d '{"model":"glm-5.2","messages":[{"role":"user","content":"Hello"}],"verify_tee":true}'

Full walkthrough: Verify a response.

Private — sealed inference

Use it when the prompt itself must not be readable by anyone else: regulated data, personal data, proprietary prompts, customer content you have promised not to disclose.

Routes to TeeML providers only. The model runs inside the enclave, your prompt enters encrypted, and the response is signed inside. Neither 0G nor the operator of the hardware can read the plaintext. This tier includes everything verified gives you.

curl https://router-api.0g.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ZG_API_KEY" \
  -H "X-0G-Provider-Trust-Mode: private" \
  -d '{"model":"glm-5.2","messages":[{"role":"user","content":"Hello"}]}'

Full walkthrough: Route sensitive prompts through private mode.

How tiers behave

Three rules govern every tier, whichever one you pick.

No default tier

Omit the header and the Router applies no trust-tier restriction. It balances across every healthy provider for that model, across all tiers, optimizing for performance.

That is deliberate. An unstated preference is not a guarantee. If a tier matters to you, state it.

A tier is a floor, not an exact match

The tiers are ordered:

standard  <  verified  <  private

Asking for a tier means “at least this strong”. A request for verified can be served by a private-capable TeeML provider, because TeeML satisfies everything verified requires and more. You are never rejected for asking for less than what is available.

The practical read: pick the weakest tier that actually satisfies your requirement. Asking for private when you only need verified shrinks your candidate pool and raises your odds of hitting a supply gap.

The Router never silently downgrades

If you ask for private and no TeeML provider is available for that model, the Router fails the request. It does not quietly serve you from a TeeTLS provider and let you believe your prompt stayed sealed.

{
  "error": {
    "message": "failed to select provider: no provider available for the requested trust mode: tier=private",
    "type": "server_error",
    "code": "no_provider_for_trust_mode"
  }
}

The 503 is transient: it is about tier supply right now, not about your permissions or a malformed request. Two reasonable responses:

• Retry with backoff. Supply returns as providers come back healthy.
• Switch to a model that has a TeeML provider. More reliable if the model you chose rarely has one.

Do not retry without the header

Catching the 503 and re-sending the request with the trust mode header removed converts a loud failure into exactly the silent downgrade the Router refused to perform — and your logs will record the request as a success.

An invalid value (anything other than the three strings) is a different error: 400 with code: invalid_trust_mode. That one is a bug in your code; retrying will not fix it. Full error semantics are in Headers.

Setting a trust mode

Per request: the header

The header applies to one request. It lets you route one endpoint’s sensitive traffic through private and leave everything else unrestricted. The cost is that the guarantee lives in your application code, so any code path that forgets the header gets unrestricted routing. X-0G-Provider-Trust-Mode is documented alongside the other routing headers in Headers.

Per key: the Console or the API

In the 0G Private Computer Console, open Dashboard → API Keys and set the key’s trust mode. Programmatically:

curl https://router-api.0g.ai/v1/api-keys \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ZG_MANAGEMENT_KEY" \
  -d '{"name":"sealed-prod","trust_mode":"private"}'

This requires an mk- management key with the appropriate scope, not your sk- inference key.

Every request made with that key routes only to that tier. The key-level setting cannot be weakened from the request side — and the attempt is an error, not a no-op: sending X-0G-Provider-Trust-Mode: standard with a private key returns 403 with code: trust_mode_mismatch, verified against the live API on 2026-07-20. Send the matching tier or no header at all.

	Per key	Per request
Enforcement point	The credential, outside your app	Application code
Can a code path forget it	No	Yes
Mixed tiers in one service	Not with one key	Yes
Best for	Compliance boundaries, third-party callers	Mixed workloads under your control

The strongest posture is to make the tier a property of the credential. Mint a private-mode key, hand it to the service that handles sensitive data, and the guarantee holds even if that service’s code is wrong.

Which models support which tier

Not every model can serve every tier. Some models have no TEE-backed provider at all: they are not verifiable, so verified and private cannot route to them.

Verified against the live catalog on 2026-07-20: of 22 models, 5 report TeeML (they can serve private), 11 report TeeTLS (verified but not private), and 6 report no verifiability method at all — the three claude-* and three gpt-5.6-* models, which verified and private can never reach. The catalog is the live source of truth; check it rather than this sentence.

Two consequences:

• A request for verified or private will never be served by one of those models.
• Pinning one of those models with X-0G-Provider-Address while requiring private returns 503 no_provider_for_trust_mode. No provider for that model can satisfy the tier, and the Router will not downgrade.

The models catalog is public and needs no authentication. Filter it by the verifiability field to find models that can serve private:

curl -s https://router-api.0g.ai/v1/models \
  | jq '.data[] | select(.verifiability == "TeeML") | .name'

Models reporting TeeTLS can serve verified but not private. Check this before shipping a private-mode integration; the alternative is discovering the gap as a production 503.

Note

Selecting a model that happens to have TeeML providers does not guarantee you land on one. When a model has providers of both kinds, the Router balances between them for performance unless a trust mode is set. The guarantee comes from the header or the key, not from the model name.

Related

• Quickstart — first request against the Router
• Verify a response — working code for verified
• Route requests in private mode — working code for private
• Verification and TEE — how each tier produces its guarantee
• Headers — X-0G-Provider-Trust-Mode and the other routing headers