The four tiers
Tier 1 — Pass-through
Model suffix::anon (default)
Tier 1 routes to frontier providers on standard cloud infrastructure. The gateway is an anonymizing proxy: Z does not retain prompts or completions, but the upstream provider operates under its own retention and content policies. Tier 1 is the right choice for general-purpose work where the privacy guarantee that matters is that Z itself does not retain the content, and where the developer trusts the upstream provider’s own posture for the rest.
Egress moderation on Tier 1 defers to the upstream provider’s native guardrails. The gateway propagates the provider’s flags as response headers but does not impose its own content filter.
Tier 2 — Private
Model suffix::private
Tier 2 routes to partner GPU networks running open-source models under contractual privacy commitments. The upstream operator agrees, by contract, not to retain or train on the content. This is a contractual guarantee, not a cryptographic one: the gateway cannot prove the partner is honoring the agreement, only that the agreement exists.
Tier 2 is appropriate for workloads where the model choice is open-source-compatible and where the regulatory or commercial posture benefits from explicit contractual coverage in addition to Z’s own Zero Data Retention.
CSAM scanning on Tiers 2 and 3 is performed by the gateway via a perceptual hash check at ingress. The scan operates on the prompt in memory only and is not logged or retained beyond its verdict. The scanner is fail-closed: when the scanner is unavailable, the request returns 503 content_safety_unavailable rather than being passed through unscanned.
Tier 3 — Managed Verifiable Hardware
Model suffix::tee
Tier 3 routes to nodes running inside hardware-attested trusted execution environments. Attestation verification must complete before any payload is dispatched to the node. This ordering is mandatory and not performance-optional: a node that has not produced a valid attestation cannot receive a request.
The attestation chain proves three things: that the code running inside the enclave is the code Z approved for that model and tier; that the hardware is genuine, signed by the hardware vendor’s root of trust; and that the attestation has not been revoked.
Tier 3 is the right choice for workloads where the integrity of execution matters and the developer needs hardware-level evidence that the request ran inside an attested enclave. Video is not supported on Tier 3. Z observes plaintext on Tier 3 and there is no in-line video content-safety scanner at V1. Video workloads requiring privacy use Tier 4.
Tier 4 — Sovereign End-to-End Encrypted
Model suffix::e2ee
Tier 4 is end-to-end encrypted between the client and the TEE node. The client and node perform an ephemeral X25519 ECDH key exchange via /v1/handshake. The prompt is encrypted to the resulting session key under AES-256-GCM with a fresh random nonce per request. The gateway sees ciphertext only; it is a blind byte-pipe and holds no decryption key.
The trade-off Tier 4 makes is that the gateway cannot inspect content for moderation, web search injection, persistent memory features, or gateway-resolved tool calls. Compliance for Tier 4 is anchored to a per-session signed AUP attestation rather than to content inspection. A Tier 4 session cannot begin until the wallet has signed the current AUP version.
Tier 4 is the only tier where Z is cryptographically incapable of seeing user content. Anywhere “Z does not see your data” is the load-bearing claim, Tier 4 is the correct answer.
Tier 4 is wallet-native. Subscription-tier users access Tier 4 by linking a wallet to their account.
How tier selection works
Tier is selected on a per-request basis by appending a suffix to the model identifier in the request body:400 tier_conflict.
If no suffix or header is provided, the request defaults to :anon. In the TypeScript SDK, tier: 'auto' resolves to Tier 1; there is no automatic tier escalation. Explicit opt-in is required for Tiers 2, 3, or 4 to prevent silent changes to billing behavior or privacy guarantees.
What “cryptographically enforced” means
Tier enforcement happens at parse and at routing. The gateway extracts the tier specifier before any other processing. The request is then routed to a pool of nodes that are eligible for that tier and only that tier. Cross-tier fallback is disabled: if no healthy node is available at the requested tier, the request fails with a5xx tier_unavailable rather than degrading to a lower tier.
For Tiers 3 and 4 there is an additional cryptographic gate. Billing finalizes only after the gateway verifies a fresh hardware attestation from the serving node. A node whose attestation fails or whose code measurement is not on the active allowlist cannot produce a billable response, regardless of what the routing layer attempts.
The practical implication: a developer who selects Tier 3 for a sensitive workload can rely on Tier 3 properties holding for that call, or on the call failing. The gateway will not deliver a Tier 1 response in response to a Tier 3 request.
Selecting a tier
The right tier is the lowest tier that meets the workload’s actual trust requirement. Tiers are not strictly ordered in cost or latency. Tier 1 frontier models are often the most expensive, but they are ordered in operational constraint. Tier 4 has the strongest cryptographic guarantee and the most integration surface to manage. Rules of thumb:- Default tooling, internal experimentation: Tier 1.
- Production workloads where the regulatory posture wants contractual privacy coverage: Tier 2.
- Workloads where the developer needs to attest to a counterparty that execution is integrity-protected: Tier 3.
- Workloads where the gateway must not be able to see the content under any circumstance: Tier 4.