Skip to main content

List the models this provider can run

GET 
/api/v1/ai-providers/:ai_provider_id/models

Asks the provider which models it can run, using this provider record's own credentials and configuration, and returns provider-native model ids — the same strings default_model and an agent's model carry. Which models are reachable is a property of the credential, not of the provider type: a Vertex provider sees only the publisher models its Google Cloud project and location serve, and a Bedrock provider only the foundation models enabled in its region. Reading the list is how a caller avoids pinning a model that fails at generation time. Not every provider type can answer. azure lists deployments an operator named rather than models, and ollama lists whatever was pulled onto that host, so both return 400 MODEL_LISTING_UNSUPPORTED. Listing resolves credentials the same way generation does, so a record that can generate can list. The API-key types (openai, groq, xai, gateway, custom, anthropic, google) use the record's linked secret and cannot list without one. bedrock and vertex use the linked secret when there is one — IAM keys or a Bedrock API key, a Google service-account key — and otherwise fall back to the server environment (the AWS default credential chain, Google Application Default Credentials), so a record with no secret_id can still list. A Vertex record needs no config.project when its secret is a service-account key, since the key file names its own project. A Vertex record in express mode (API key) cannot list at all: the publisher-model listing rejects API keys and needs a credential that asserts a principal, so it returns 400 MODEL_LISTING_UNSUPPORTED. The Vertex answer is the publisher catalogue the record's config.location region serves. The project behind the credential is billed and quota'd for the call but does not filter the result, so a listed model may still be unavailable to that project at generation time.

Request​

Responses​

The models this provider can run