Skip to content

Model Catalog

The model catalog is live. It reflects providers currently registered on-chain, not a static list, so GET /v1/models is the only authoritative answer to “what can I call right now”. It is public and needs no authentication, which makes it the cheapest thing to check when a recipe fails.

Terminal window
curl -s https://router-api.0g.ai/v1/models

Each entry carries an id you pass as model in an inference request, plus the metadata the recipes here depend on:

Field What it tells you
id What you send as model
type chatbot, text-to-image, or speech-to-text
supported_formats openai, anthropic, or both — which API surface accepts it
verifiability TeeML, TeeTLS, or empty — which trust modes can route to it
tee_type / tee_verifier The enclave technology and the tool that checks its attestation
provider_count How many providers currently serve it, which is your redundancy
context_length Maximum context window

Verified against the live endpoint on 2026-07-20: 22 models — 20 chat, 1 image, 1 speech-to-text — of which 19 accept the OpenAI format and 5 the Anthropic format, and 5 report TeeML, 11 TeeTLS, and 6 no verifiability method. Treat that as a snapshot; the live list is authoritative.

verifiability names the method by which a provider’s execution can be independently checked. It is the field that connects the catalog to Trust Modes, and it is what decides whether a model can serve the tier you ask for.

verifiability Meaning Satisfies trust mode
TeeML The model itself runs inside the TEE. Prompts enter the enclave encrypted and responses are signed inside it, so neither 0G nor the hardware operator sees plaintext. standard, verified, private
TeeTLS The 0G broker, itself in a TEE, forwards over attested TLS. The broker cannot see the traffic, but the upstream handles plaintext under its own data policy. standard, verified
empty TEE-backed execution with no independent verifiability method disclosed. standard

The tiers are a floor, ordered standard < verified < private. A TeeML model satisfies every tier; an empty verifiability satisfies only standard. Asking for a tier with no supply fails with 503 no_provider_for_trust_mode rather than downgrading silently — see Provider Routing Headers and Error Codes.

Models that can serve private:

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

Models that can serve verified, where either TEE method qualifies:

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

Run the filter rather than reusing a model ID from an example. A model that served private last month can drop out of the TeeML set when its providers change.

GET /v1/providers lists the endpoints serving a model, with the on-chain address you can pin through X-0G-Provider-Address. It is public too.

Terminal window
curl -s "https://router-api.0g.ai/v1/providers?model=glm-5.2"

Healthy private-tier endpoints for a model, fastest first:

Terminal window
curl -s "https://router-api.0g.ai/v1/providers?model=glm-5.2" \
| jq -r '[.data[] | select(.is_healthy == true and .trust_mode == "private")]
| sort_by(.latency)
| .[] | [.address, .latency, .uptime] | @tsv'

Two things to know before you act on that list. provider_count in /v1/models counts endpoints regardless of health, so a model can show providers and still have none servable; read is_healthy per endpoint. And on a provider entry, verifiability is a descriptive TEE label that is empty for standard endpoints, while trust_mode is the tier the Router actually routes on — check trust_mode when you care about a floor.

Pinning trades resilience for determinism: X-0G-Provider-Address implies Allow-Fallbacks: false, so if that provider goes down your request fails rather than moving on. In most cases setting X-0G-Provider-Trust-Mode: private and letting the Router pick gets you the same guarantee with failover intact.

Field-by-field schemas for /v1/models and /v1/providers, including pricing objects, TEE attestation fields, and the beta canonical-ID filters, live in the Router models reference in the 0G Documentation: https://docs.0g.ai/concepts/compute. This page covers only what the recipes here depend on.