Skip to content

Concepts

This group answers why the system works the way it does. Four pages explain everything on the API that behaves differently from a single-vendor endpoint: why the same model has more than one price, why a trust mode can make a request fail, and what a response lets you prove.

Read these when a header, an error, or a charge did something you did not expect, and you want the reason rather than a workaround.

Page When you need it What it solves
Models and providers Before you pick a model, or the first time a request behaves differently across two identical calls Explains that a model ID names a capability served by many independent providers, and that the Router picks one per request — the root of failover, price spread, and per-provider TEE capability
Trust Modes You need to constrain who may serve a request, or a request failed with no_provider_for_trust_mode Defines standard, verified, and private as routing constraints, what each tier guarantees, and why the Router fails rather than silently downgrading
Verification and TEE You have to show a response really came from the model you paid for, or prove nobody read the prompt Separates authenticity from confidentiality, explains TeeML and TeeTLS, and shows what x_0g_trace and verify_tee let you check yourself
Pricing and billing You are sizing a deposit, or two calls to the same model cost different amounts Covers prepaid on-chain balance, per-token pricing set by each provider, and the exact charge reported on every response

Start with Models and providers. The decentralized provider network is the premise everything else rests on, and once it is clear the rest follows naturally: trust modes are a filter over which providers may serve you, pricing varies because providers set their own, and verification exists because you did not choose the provider yourself.

If you came here with one specific problem rather than to build a mental model, go straight to Trust Modes — it is the page most API surprises trace back to.