Models

INFRO routes to the text, image, video, and audio models your connected providers serve, from every major lab, behind one API. Each model has a stable ID you pass as model — to chat completions, images, video, or audio — and a catalog entry with its vendor's reference rate and capabilities.

See which providers you can connect at /providers, and fetch the models your key can call with GET /v1/models — useful for model pickers, validating IDs at startup, or filtering by capability.

Model IDs

Every model ID is vendor/model-name; IDs are matched case-insensitively. The vendor is the lab that trained the model, not the account that serves it — anthropic/claude-sonnet-5 is served by whichever of your connections can serve Anthropic models (Anthropic directly, or Vertex AI, for example). A bare name without the vendor, like claude-sonnet-5, also resolves when exactly one of your connected vendors has a model by that name; if more than one does, the request returns 400 with code ambiguous_model. The name of one of your routes is also a valid model. For providers whose ids INFRO cannot derive (LaoZhang, Together, Fireworks, Bedrock, an OpenAI-compatible endpoint and others), <provider>/<model id> sends the provider's own id to that provider's connections exactly as written, case included; see Providers. Every response names the provider and connection that served it, and route gives its position in the chain (primary, standby_a, …).

openai/gpt-5.6-sol
anthropic/claude-sonnet-5
google/gemini-3.1-pro
deepseek/deepseek-v4-flash
qwen/qwen3-coder

A mistyped or unknown ID returns 404 with error type model_not_found. A known model that none of your connections can serve returns 503 with code no_provider_connected, naming the provider to connect. Don't retry either — see error handling for which statuses are retryable.

List models

GET /v1/models returns what the calling key can actually reach: a catalog model appears only when at least one enabled, healthy connection in the key's environment serves it and every allowlist that applies permits it. Your organization's active routes are listed too, with type: "route". It works with any OpenAI-compatible SDK's models.list().

curl https://api.infro.io/v1/models \
  -H "Authorization: Bearer $INFRO_API_KEY"

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.infro.io/v1",
    api_key=os.environ["INFRO_API_KEY"],
)

for model in client.models.list().data:
    print(model.id)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY,
});

const models = await client.models.list();
for (const model of models.data) {
  console.log(model.id);
}

{
  "data": [
    {
      "id": "anthropic/claude-sonnet-5",
      "type": "model",
      "name": "Claude Sonnet 5",
      "context_length": null,
      "pricing": {
        "prompt": "0.000002",
        "completion": "0.00001",
        "source": "vendor_list"
      },
      "capabilities": [],
      "served_by": [
        { "id": "conn_8Kx2mQ4vR7tYb1Zp", "name": "Production Anthropic", "provider_kind": "anthropic" }
      ]
    },
    {
      "id": "support-agent",
      "type": "route",
      "name": "Support agent",
      "context_length": null,
      "pricing": { "source": "unpriced" },
      "capabilities": [],
      "strategy": "priority",
      "targets": [
        { "model": "anthropic/claude-sonnet-5", "connection": "conn_8Kx2mQ4vR7tYb1Zp" }
      ]
    }
  ]
}

idstring

Canonical vendor/model-name ID for a model, or the slug of a route. Pass this as model in requests; model IDs (not route slugs) can also go in fallbacks lists.

type"model" | "route"

Whether the entry is a catalog model or one of your organization's routes.

namestring

Human-readable display name, suitable for UI.

context_lengthinteger | null

Maximum context window in tokens — prompt and completion combined. null when the catalog does not record it, and always null for a route.

pricing.promptstring

USD per prompt token at the vendor's published list rate — reference data for cost estimation, not a price INFRO charges. This field always shows the list rate; your organization's own rate, once entered under Prices in the console, is what cost estimates use instead. A string to avoid float precision issues; multiply by 1,000,000 for per-1M-token comparison. Absent when the model is priced per unit or not priced.

pricing.completionstring

USD per completion token at the vendor's published list rate, on the same terms.

pricing.unit / pricing.perstring

For models billed per unit (images, video, audio): the list rate in USD and the unit it applies to.

pricing.source"vendor_list" | "unpriced"

vendor_list when the figures are the vendor's published rate; unpriced when no rate is known, in which case requests to the model are recorded as unpriced, never as free.

capabilitiesarray of strings

Feature flags: any of tools, vision, json. See below.

served_byarray of objects

Models only. Your connections that would serve a request for this model, in the order they would be tried: id, name and provider_kind.

strategy / targetsstring / array of objects

Routes only. The route's strategy and its enabled targets in order, each a model and a connection ID.

Capabilities

The capabilities array records what a model supports. The catalog only lists a flag once it has been verified for that model, and many entries do not record capabilities yet, so an empty array means not recorded, not unsupported. Three flags:

toolscapability

Supports the OpenAI tools/tool_choice schema, normalized across providers. See tool calling.

visioncapability

Accepts image_url content parts (HTTPS or base64 data URLs, 20MB max per image request). See vision.

jsoncapability

Supports strict json_schema structured outputs. Plain {"type": "json_object"} works on most models regardless of this flag — json specifically gates strict schema mode. See structured outputs.

To filter the catalog by capability, fetch the list and check membership:

curl -s https://api.infro.io/v1/models \
  -H "Authorization: Bearer $INFRO_API_KEY" |
  jq -r '.data[] | select(.capabilities | index("vision")) | .id'

import os
import requests

resp = requests.get(
    "https://api.infro.io/v1/models",
    headers={"Authorization": f"Bearer {os.environ['INFRO_API_KEY']}"},
)

vision_models = [
    m["id"] for m in resp.json()["data"]
    if "vision" in m["capabilities"]
]
print(vision_models)

const resp = await fetch("https://api.infro.io/v1/models", {
  headers: { Authorization: `Bearer ${process.env.INFRO_API_KEY}` },
});
const { data } = await resp.json();

const visionModels = data
  .filter((m) => m.capabilities.includes("vision"))
  .map((m) => m.id);
console.log(visionModels);

Context length and pricing

context_length, when recorded, is the total window: input tokens plus generated tokens must fit inside it. When a completion hits the window (or your max_tokens), it stops with finish_reason: "length" — budget accordingly for long prompts.

Catalog pricing is the model vendor's own published rate, and INFRO adds nothing to it — your provider invoices you directly at whatever you have negotiated with them. Each response carries usage.cost, an estimate of what that request will cost you, and usage.price_source, which says where the rate came from: custom_provider or custom when you have entered your own rate under Prices, list for the vendor's list rate, or provider when the provider reported the cost itself. When no rate is known, usage.cost is null and price_source is absent.

Model reference pages

Each model in the reference catalog has its own page: the vendor's list rate, the endpoint it is called on, and a request sample. The rates are the vendor's published list rates, checked 2026-10-05. Your provider bills you at whatever you have negotiated with them, and INFRO adds nothing. A model is reachable through INFRO only when one of your own provider connections serves it.

Choosing a model

There is no single best model — pick by workload, and let the gateway handle the rest. A rough map:

You don't have to commit to one. A route can spread a model across the provider accounts you connect, and fallbacks let you chain models — a common pattern is a flagship primary with an open-weight fallback, so an outage degrades quality instead of availability. Per-request fallbacks apply when model is a model ID; when model names a route, the route's own targets decide failover and fallbacks is ignored.

Deprecation policy

Catalog models are deprecated with at least 30 days notice, announced by email and in the console. During the notice window the model serves normally. Whether a model stays available at all is ultimately up to the provider whose account you connect.

After retirement, the old ID becomes an alias for its designated successor — existing code keeps working with no 404. Retired IDs drop out of GET /v1/models, but aliases keep resolving indefinitely.