List Models

OpenAI Models API compatible endpoint. Returns everything the caller can put in model — in OpenAI’s models.list shape — so tools that point an OpenAI-compatible base URL at /v3/compat (gateways, n8n, LangChain, etc.) can discover the live catalogue without hardcoding model IDs.

Human labels are optional opper.display_name metadata; id remains the callable identifier. Dynamic routes additionally carry opper.pricing.kind=variable, never a fixed numeric price. Every entry carries opper.kind, which names what it is:

• model — a concrete catalog row (LLM or embedding), e.g. anthropic/claude-sonnet-4.5. Pinning this id pins that provider.
• pool — a bare model name that load-balances across providers, e.g. claude-sonnet-4.5. opper.members lists the catalog rows it routes over. Listed only for names that genuinely fan out (two or more routable members).
• dynamic_route — one of the calling org’s deployed routing graphs, addressed as dynamic/<name>. opper.version is the deployed version a call would execute. Org-scoped to the API key; draft-only routes are not listed. No numeric pricing is reported — the graph picks the model per request — but context_length and opper.max_output_tokens ARE, as the smallest any reachable candidate offers: a floor is a guarantee rather than a guess, and clients that must size a context before calling would otherwise have to invent one. Omitted when any candidate cannot be resolved here (e.g. an org-scoped BYOK model).

Narrow with ?type= (comma-separated, e.g. ?type=pool,dynamic_route); omitting it returns all three kinds, with concrete models first (their long-standing order is unchanged), then pools, then routes.

Entries additionally carry OpenRouter-shaped pricing (USD per token) and context_length, plus an opper block holding the entry’s type (llm or embedding — this list carries both, and capabilities cannot tell them apart), the model’s capabilities (text, tools, vision, pdf, structured_output, … — the same vocabulary as /v3/models), its max_output_tokens, selectable effort controls under opper.reasoning (supported and optional default), and a compliance summary (region, country, zdr, gdpr_residency, verification) so a client can declare what a model can do and filter on residency/ZDR criteria in one call; zdr is the tri-state retention facts object (logging, moderation, caching, training, subprocessors; null = not established), not a summary word — derive what you need from it; full data-handling detail lives on /v3/models?include=route. A pool reports a capability or compliance property only when EVERY member has it, takes the smallest context_length / max_output_tokens across members, and prices at the worst case. Pool effort controls are the intersection of all allowed members’ declared ladders; supported: [] means no portable selectable effort, even if members think internally. The default is present only if all members agree on a supported value. Concrete rows without declared effort controls and dynamic routes omit opper.reasoning. none is an explicit off-switch only when listed; omitting an effort leaves provider defaults in control. These fields do not change routing. This means a capability check, a residency filter or a pre-call cost estimate can never be flattered by one lucky member. Dynamic routes report only capabilities shared by every resolvable allowed candidate; an unresolved candidate leaves capabilities unknown. Their standard numeric pricing remains omitted because the graph picks the model per request. The whole listing is scoped to the caller’s comply allowlist: denied models, denied pool members, pools with no permitted member, and routes whose every model node is denied are all absent. Featured models first, then ID-ascending; no pagination, matching OpenAI.