> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Model registry

The model registry is the canonical list of models available through the gateway, along with the trust tiers at which each model is reachable. The registry is read by routing logic and by the model-discovery endpoint that clients use to enumerate available options.

## What the registry tracks

For each model, the registry records:

**Canonical identifier.** The string used in the `model` field of a request (without tier suffix).

**Available tiers.** Not every model is available at every tier. Frontier models from major laboratories are typically reachable at Tier 1 only. Open-source models are typically reachable at Tiers 2 through 4. Specific models on specific TEE hardware are reachable at Tier 3 and Tier 4.

**Capability flags.** Whether the model supports streaming, vision, tool calls, JSON mode, and so on. These are passed through from the upstream specification.

**Per-token pricing.** The price per input and output token at each tier. Pricing can differ across tiers for the same model because the underlying infrastructure differs.

**Quality signal.** Where available, the registry includes a third-party quality score. The score is informational and is exposed to the client as one of several routing inputs.

**Status.** Whether the model is generally available, in preview, or being deprecated.

## Accessing the registry

The registry is exposed at `/v1/models`. The endpoint returns a JSON array of models with their metadata. Clients can filter by tier, capability, or status. For routine integration, most developers will not interact with the registry directly; they will pin a specific model and tier in their request and only consult the registry when adding new model paths.

## Permissionless access

The registry is designed to be open. Z does not gate access to specific models behind premium plans; if a model is in the registry and the requesting account has credits, the model is reachable. This is a deliberate design property: the routing layer should not impose a tiered access scheme on top of what the upstream provider already imposes.

## Community-hosted models

Community-hosted models (models served by independent node operators) are tracked on the roadmap. The registry is currently curated by Z; the community-hosted path arrives with broader Z Compute availability.

## Discovery

The model registry is the right place to look when:

* Adding a new model path to a production integration.
* Verifying that a specific model is reachable at the trust tier the workload requires.
* Comparing prices across tiers or across models for cost optimization.
* Checking whether a deprecation has been announced for a model the integration depends on.