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
400or404does not, because it would fail identically elsewhere. - The provider that actually served the request is returned in the
providerfield and theX-Openbase-Providerheader.
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
| Capability | Meaning |
|---|---|
| streaming | The model can return server-sent events. |
| vision | Image parts are accepted in message content. |
| tools | Function and tool calling are supported. |
| json mode | A 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.