Skip to main content
GET /v1/models on the application URL returns the OpenAI-shaped list SDKs probe on startup. GET /v1/models/{id} is 200 for a listed id and 404 otherwise.

​
What is in it

This is gateway-owned discovery. It is not a passthrough of any provider’s /v1/models, and it is not the catalogue behind the console’s model pickers. It is the set of native model ids this application can call right now, which is narrower than either:
  1. For each registry the application may use — including fallback and pool members — start from the application’s model restriction if there is one, otherwise from the provider catalogue.
  2. Keep only native ids. auto, @provider/… and pool references are routing instructions, not models, and are excluded.
  3. Keep an id only if the registry’s provider supports its capability: chat always; embeddings and rerank only where the provider advertises them.
owned_by is the registry’s provider — openai, anthropic — which is what a client needs to make sense of a mixed list.

​
Why it differs from what you see in the console

The console’s pickers are narrowed per registry to what its credentials can list — Azure shows deployments, an OpenAI-compatible endpoint shows its live models — and fall back to the full catalogue when a provider cannot be queried. This endpoint applies the application’s restrictions on top. A model visible in the console but missing here is one the application is not allowed to use; that is the restriction working, not a sync problem. Files have no model ids and are never listed. Image models appear only when the catalogue or restriction includes them and an images-capable registry is attached.