Available Models And Access

Use /v1/models to see which deployment-defined router model groups your caller token can request. This is the first check to run after receiving a router endpoint and caller token.

From Getting Started, you might be looking for CLI guides: see Codex CLI or Claude Code CLI.

These docs are built into the hosted GenAI Smart Router server delivered for your deployment. Examples that show the router base URL use this browser origin, so on this deployment they render as https://<router-host> and https://<router-host>/v1.

Check Your Allowed Groups

export ROUTER_BASE_URL="https://<router-host>"
export ROUTER_TOKEN="rtr_metrum_<user>_<project>_<env>_<key>_<secret>"

curl "$ROUTER_BASE_URL/v1/models" -H "Authorization: Bearer $ROUTER_TOKEN"

Example response:

{
  "object": "list",
  "data": [
    {
      "id": "default",
      "object": "model",
      "owned_by": "smart-llmrouter"
    },
    {
      "id": "vision",
      "object": "model",
      "owned_by": "smart-llmrouter"
    }
  ]
}

Use one returned id as the model value in /v1/chat/completions, /v1/responses, /anthropic/v1/messages, Codex CLI, Claude Code CLI, or another compatible client. Model discovery stays at /v1/models for both OpenAI-compatible and Anthropic-compatible setup flows.

What The Names Mean

The returned IDs are router model groups, not a full inventory of every upstream provider model. A deployment might expose groups such as default, fast, coding, vision, or different names chosen by the platform team. GenAI Smart Router does not require any specific group names.

Each group is a policy contract. The platform team can change the upstream model or provider model mix, weights, fallbacks, TypeScript policy, tool support, VLM support, cost controls, and validation criteria behind the group without changing the caller-facing name.

The same group can expose different effective target pools by API surface. OpenAI Chat clients use OpenAI Chat-compatible targets, Codex uses Responses-compatible targets, and Claude Code uses Anthropic Messages-compatible targets. If a group is listed but a specific client receives no-eligible-target, the group is allowed for that token but lacks an eligible target for that request shape.

Why A Group May Be Missing

/v1/models is filtered by the caller token allow list. If a group is not listed, that caller token is not allowed to use it. Requests for unlisted groups fail with 403 model-not-allowed before any upstream provider is called.

Symptom	Meaning	Next step
Expected group is missing	The token allow list does not include that group	Ask the deployment administrator to add access if intended
No groups are listed	The caller token may be wrong, disabled, or scoped too narrowly	Verify the caller token and endpoint with the administrator
401 or 403 before a model list appears	Authentication failed or the caller token is not accepted by this deployment	Check the base URL and router token value
A listed group returns no-eligible-target for tools or images	The group is allowed, but no target matches that request shape	Ask the administrator to enable a compatible target or use an allowed group designed for that client

For Administrators

Administrators control this list with each caller token's allow entries. Use Key Generation And Rotation for router-token creation and Caller Tokens for allow-list behavior.

For API details and compatible endpoint shapes, see API Compatibility.