Models

Regional availability

OpenAI, Anthropic and Gemini models require an incoming request from a region on the respective maker's supported API list. We check the request IP, including requests made through the Playground. Missing or uncertain locations are refused with 403 model_location_not_supported. For OpenAI and Anthropic, Ukraine also requires a supported subdivision; Crimea, Sevastopol, Donetsk, Kherson, Luhansk and Zaporizhzhia are excluded. Gemini uses Google's own country list, which includes Ukraine without that subdivision condition.

The rule follows the model through provider fallbacks, resellers and BYOK. Platform applies the Gemini API list to Gemini models on Vertex as well. Additional verified country restrictions can apply to an exact model or version and can only narrow its service baseline. GPT-5.4 and GPT-6 Astra currently share OpenAI's country baseline; data-residency or account access restrictions are separate from the incoming request's country. It covers HTTP, Responses WebSockets, continuations and batch submissions. A replay of a keyed request requires every possible route to be geographically eligible, since its saved answer may have come from any rung. Other makers are unaffected by this check. The catalog remains a global listing; listing a model does not establish regional eligibility.

An IP identifies the calling server or VPN when one is used. This check does not establish residence, nationality, sanctions status or the location of a downstream end user. See the OpenAI, Anthropic and Gemini lists. IP geolocation by DB-IP, licensed under CC BY 4.0. Contact support to review an incorrect location.

The catalog

Every model is a slug (for example claude-opus-5, gpt-5.5, gemini-3.7-flash) with a display name, context window, input and output modalities, and pricing. The catalog is the public rows plus your organization's own custom and local models. Browse it in the web app at /models, or read it over the API: GET /api/modelsis public and needs no key (it returns the public rows), and sending your key adds your organization's own custom and local models.

Experiential Cloud is a curated collection of models, hosted and optimized by Experiential Labs. Those slugs appear in the catalog like any other model. Call them with your Experiential Labs key. They are not a provider connection you attach yourself.

curl "https://api-pr-1518.preview.experientiallabs.ai/api/models?sort=preferred&limit=20"

Filter and sort with query parameters: modality, category, provider, min_context, max_input_micro_usd_per_million, supports, retention, and sort (one of preferred, price, age, context, throughput) with limit and offset. One model's detail is GET /api/models/<slug>; its deployments are GET /api/models/<slug>/providers.

Zero data retention is browsable: each list entry carries a retentionverdict over its platform-funded routes' documented provider postures (zdr_all_rungs, zdr_enforceable, not_zdr), and ?retention=zdr_all_rungs (or zdr_enforceable) narrows the list — the same facet the /models catalog exposes as its Retention filter and ZDR tag. Both the list verdict and the model page's verdict count only the lanes the gateway actually routes for that model, so a lane the active plan skips never claims a ZDR route; an entry with no platform-funded routed lane has no verdict. Neither is enforcement: to guarantee your requests only ever route through zero-retention lanes, set the require-ZDR policy in Settings → Data controls, which the gateway applies per request at rung granularity.

Provider waterfalls

A slug does not point at one provider; it points at a waterfall, an ordered list of deployments (each a provider plus a provider model id, and for some providers a base_url, region, or api_version). The gateway tries each rung in order, fails over on capacity and transport errors, and returns the first success. The routing is invisible to the caller: you get one OpenAI-shaped response.

Every model has a default chain. An organization can override it with its own ordering. Read and replace the chain with the waterfall endpoints; model_provider_ids is the ordered list of deployment ids, and an empty list clears your override (falling back to the default).

# Read the chain for a model
curl "https://api-pr-1518.preview.experientiallabs.ai/api/models/claude-opus-5/waterfall" \
  -H "Authorization: Bearer $EXPLABS_API_KEY"

# Replace your org's override with an ordered deployment list
curl -X PUT "https://api-pr-1518.preview.experientiallabs.ai/api/models/claude-opus-5/waterfall" \
  -H "Authorization: Bearer $EXPLABS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model_provider_ids": ["<deployment-a>", "<deployment-b>"]}'

Two lanes: BYOK and platform-funded

Each deployment is paid for through one of two lanes, and the gateway adds no markup on either:

• Pass-through (BYOK): your own provider key. The provider bills you directly. These deployments are customer_managed.
• Platform-funded: our credits, priced from the public catalog. These deployments are host_managed and are seeded by operations, never self-asserted.

To use the pass-through lane, connect your own provider key — free on any plan. See Adding models → Bring your own key for the step-by-step and each provider's fields.

Estimated vs measured stats

Every route carries the source of its numbers so you can tell a seeded estimate from something we measured on our own serving, and a field flips from estimate to measured once we have enough volume to trust it:

• Stats (uptime, throughput, latency): seeded values are stats_source = 'openrouter'. Once a route has enough completed requests in the trailing 30 days, the catalog overlays values measured from our usage ledger and marks them stats_source = 'observed'. Below that floor the seeded estimate stands.
• Pricing: real prices carry their source (openrouter, provider-docs, aws-price-list); a value we had to guess is pricing_source = 'estimate' and is display-only , an estimated price is never billed or served on the platform lane.

Custom and local models

Register your own OpenAI-compatible server as a model scoped to your org, callable by slug like any other — and bring your own provider key to serve a catalog model on your own account. Both live in Adding models, with the guided in-app flow and the POST /api/models shape.

See also

The API reference lists every field and response shape, and Errors covers what a failed route returns.