Models and providers

With a centralized API, a model ID names one vendor’s backend. Here it names a capability that several independent providers offer, and the Router picks one of them per request.

How models get served

0G does not host the models behind a single backend. Each model is run by independent providers on the network, and one model ID usually has several providers able to serve it. You call the Router at https://router-api.0g.ai/v1, and the Router selects a provider for each request.

That one difference explains most of what follows.

Because models come from many providers	What it means for you
The same model has more than one source	You get redundancy, and you should design for failover rather than assume one endpoint
Providers price their own capacity	The cost of a model can differ between providers serving it
TEE capability differs per provider	Whether a request is verifiable depends on which provider serves it, not only on the model

How providers register, stake, and get paid on-chain is network-layer material. It lives in the 0G compute network documentation; this site stays on the API surface.

The provider network

A provider’s identity is an on-chain address, written as 0x…. Every Router response carries an x_0g_trace block whose provider field is that address, so you can tell after the fact which provider served any given request and keep an audit trail of it.

A provider’s TEE capability shows up as its verifiability value — TeeML, TeeTLS, or empty — and that value decides which trust tiers it can satisfy. See Trust Modes for what each tier guarantees.

The Router routes only among providers it considers healthy.

To see who serves a model:

curl -s "https://router-api.0g.ai/v1/providers?model=<MODEL_ID>"

How the Router picks one

By default, with no routing headers set, the Router round-robins across the healthy providers for your model and fails over to another provider automatically when one errors. Only when every candidate fails does the request return 503.

You can constrain that selection. Each of these is a request header, documented in full in Headers.

Header	What it does
`X-0G-Provider-Sort`	Orders candidates by `latency` or by `price` instead of round-robin.
`X-0G-Provider-Address`	Pins the request to one provider address, which implies no fallback.
`X-0G-Provider-Max-Price-Usd-*`	Sets a price ceiling as a hard filter, applied before sorting and before failover.
`X-0G-Provider-Trust-Mode`	Restricts candidates to those meeting a trust tier: `standard`, `verified`, or `private`.
`X-0G-Provider-Require-Parameters`	Filters on whether a provider supports the sampling and reasoning parameters your request uses.

Because the price ceiling runs before failover, a fallback attempt can never land on a provider above your limit. For the retry behavior that pairs with this, see Failover and retries.

Where to see the catalog

GET /v1/models is public and needs no authentication:

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

Filter it to the models whose providers can run the model inside the enclave:

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

The Console models page at https://pc.0g.ai/ shows the same information with prices attached.

As of 2026-07-20 the catalog lists 22 models — 20 chat, 1 image, 1 speech-to-text — of which 19 accept the OpenAI format and 5 the Anthropic format. The catalog is the live source of truth; read it at runtime rather than trusting that sentence. Per-model fields and a dated snapshot are in Model Catalog.

Model Catalog — field-by-field schemas for /v1/models and /v1/providers
Trust Modes — what standard, verified, and private restrict
Headers — every routing header and its error semantics
Failover and retries — handling provider failure in client code