Using the API

Models

Models are addressed by a provider-prefixed slug. One slug can be served by several upstreams, which is what makes failover possible.

Naming

A slug is vendor/model, for example anthropic/claude-sonnet-5 or google/gemini-3.7-flash. The vendor prefix identifies who built the model, not necessarily who serves it.

Listing what is available

GET /v1/models returns the OpenAI-shaped list your SDK expects. The catalog page shows the same data with pricing and capabilities.

curl https://api.openbase.ai/v1/models \
  -H "Authorization: Bearer $OPENBASE_API_KEY"

How a provider is chosen

Each model maps to one or more deployments, each pointing at a provider with a priority. The router walks them in order.

  • The lowest priority number that is healthy and has credentials is tried first.
  • A retryable failure moves to the next deployment. A 400 or 404 does not, because it would fail identically elsewhere.
  • The provider that actually served the request is returned in the provider field and the X-Openbase-Provider header.

Pinning a provider

To take routing into your own hands, send a provider object with an explicit order, and disable fallbacks if you would rather see an error than a substitution.

{
  "model": "anthropic/claude-sonnet-5",
  "messages": [{"role": "user", "content": "Hello"}],
  "provider": {
    "order": ["anthropic"],
    "allow_fallbacks": false
  }
}

Capabilities

CapabilityMeaning
streamingThe model can return server-sent events.
visionImage parts are accepted in message content.
toolsFunction and tool calling are supported.
json modeA structured response format can be requested.

Reasoning models need headroom

Models that think before answering spend part of their output budget on hidden reasoning tokens. A very small max_tokens can be consumed entirely by thinking, leaving an empty completion. Give reasoning models several hundred tokens of room.