Model catalog

The catalog is the set of models you can name in a request. Ringside does not run any of them. It is a gateway: you send an OpenAI-shaped request to https://api.fightclub.pro/v1, name a model with a prefixed ref, and Ringside resolves that ref to a concrete model, picks the right upstream provider, signs the upstream call with a key you never see and meters the cost back to your wallet. One key reaches every provider in the table below. You are not juggling an OpenAI key, an Anthropic key and a Together key in your own code, and you are not maintaining four SDKs.

Because the surface is OpenAI-compatible, the mental model is short. Point the OpenAI SDK at the Ringside base URL, put your ko_ key in the Authorization: Bearer header, and prefix your model strings with fc:. That prefix is the one thing the catalog forces on you, and it exists so the same call can pin one exact build or hand the choice to Ringside. The rest of this page is the inventory and the grammar.

Providers

Ringside reaches 19 providers through three integration styles. The style is an implementation detail you almost never see: a fc:openai/gpt-4o-mini ref and a fc:groq/llama-3.3-70b ref are the same request shape to you. It matters in two places. Region pinning is wired for OpenAI and for Claude (via Bedrock and Vertex) only, and a handful of providers are reached as raw upstream HTTP rather than through the Vercel AI SDK, which is why their exact model ids track the upstream catalog.

OpenAI-compatible (12)

These speak the OpenAI Chat Completions wire format upstream, so Ringside fronts them through a shared OpenAI-compatible adapter. This is the bulk of the open-weight inference market plus a few first-party APIs.

AI-SDK native (3)

These three do not speak the OpenAI wire format natively, so Ringside drives them through their first-party Vercel AI SDK adapters and translates the request and response to the OpenAI shape for you. Anthropic is the provider that prompt caching and match: family resolution are wired for today.

Custom (4)

These need bespoke transport: a cloud signing flow, a hosted-inference job model or an enterprise-deployment URL. Two of them, Bedrock and Vertex, are also how Claude gets region-pinned (covered below).

Model reference syntax

Every model value is a typed reference, not a bare name. The prefix declares how the string becomes a concrete model. A bare name like gpt-4o is rejected with 400 invalid_model_ref, because Ringside refuses to guess whether you meant a pinned build, the newest in a family or an alias you control. There are four prefixes.

`fc:<provider>/<model>`

Pinned. Resolves to exactly that model with no indirection. fc:openai/gpt-4o-mini is OpenAI gpt-4o-mini and nothing else. Use it for evals, regression baselines and anything you need byte-for-byte stable across a deploy.

`match:<provider>/<family>`

Family resolution. Resolves to the newest catalog model in the family and rolls forward as new versions ship. Add a floor (match:anthropic/sonnet>=4) or a pin (match:anthropic/sonnet=4). Anthropic families (sonnet, opus, haiku) are supported today.

`slot:<alias>`

A named pointer you define on the platform side that maps to a fc: ref. Repoint slot:default-chat once and every caller picks up the new target on the next request, with no code change.

`dyn:<name>`

A dynamic profile that picks a model per request from a pool, based on the request shape (token count, tools, vision, json_schema, difficulty). Two identical-looking calls can resolve differently; read the resolved model from the response headers.

// four refs, four resolution strategies
{ "model": "fc:openai/gpt-4o-mini" }          // pinned, exact
{ "model": "match:anthropic/sonnet>=4" }      // newest Sonnet at v4+
{ "model": "slot:default-chat" }              // alias you repoint
{ "model": "dyn:cost-aware" }                 // profile picks per request

// rejected
{ "model": "gpt-4o" }                         // 400 invalid_model_ref

Resolution is server-side on every metered call (chat, runs, assistants, conversations) and always lands on a concrete fc:<provider>/<model> before a provider is touched. That concrete id, not your selector, is what gets metered, cached and capability-checked. The chat response reports what resolved: X-Ringside-Model-Resolved carries the concrete id for a match:/slot:/dyn: ref, and X-Ringside-Dynamic-Profile / X-Ringside-Dynamic-Reason explain a dyn: pick. The full grammar, the roll-forward rules and every resolution error live in the model references concept.

Region and data residency suffixes

Append @<region> to a fc: ref to pin where the call runs. The suffix attaches to fc: refs only, it is opt-in, and a ref without one routes normally with no residency guarantee. Residency changes where the call executes, not what it costs: billing stays on the canonical model price. An unknown suffix returns 400, and a suffix on a base that does not support it (an OpenAI suffix on a non-OpenAI model, or a Bedrock/Vertex suffix on a non-routable model) returns 400 unsupported_provider.

curl https://api.fightclub.pro/v1/chat/completions \
  -H "Authorization: Bearer $FC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "fc:anthropic/claude-opus-4.6@eu-bedrock",
    "messages": [{"role":"user","content":"Summarise this clause."}]
  }'

Embedding models

Embeddings power the /v1/embeddings endpoint and the embedding side of managed vector stores. When you create a vector store you fix its embedding_model at creation time. Changing it later means a blue-green re-embed via POST /v1/vector_stores/{id}/migrate, since a vector indexed under one model cannot be compared against vectors from another. The store accepts the bare model id from the set below.

Rerank models

Rerank is the second stage of two-pass retrieval. Vector search recalls a wide candidate set, then a reranker scores each candidate against the query and you keep the top few. The /v1/rerank endpoint mirrors the Cohere /v2/rerank wire shape and routes to one of two providers. Refs here are fc:-prefixed.

curl https://api.fightclub.pro/v1/rerank \
  -H "Authorization: Bearer $FC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "fc:cohere/rerank-v3.5",
    "query": "What is the capital of France?",
    "documents": [
      "Paris is the capital of France.",
      "Berlin is the capital of Germany."
    ],
    "top_n": 1,
    "return_documents": true
  }'

Image, audio and moderation models

The catalog is not only chat. Image generation routes to OpenAI (DALL-E), Stability AI and Replicate (Flux). Audio covers speech-to-text on OpenAI Whisper and Groq Whisper, and text-to-speech on OpenAI and ElevenLabs. Moderation runs through /v1/moderations, which meters at $0 so you can screen text inline before or after a chat call without paying for the check. These media refs are fc:-prefixed like any other (fc:openai/dall-e-3, fc:replicate/flux-pro, fc:elevenlabs/...). A media ref sent to /v1/chat/completions returns 400 invalid_model_for_chat; use the matching endpoint.

Failure modes

Most catalog errors are 400 invalid_request_error and carry a stable code you should branch on (never the human message). The request id is the X-Request-Id response header, not a body field.

When you want one model name that keeps working as the underlying model improves, reach for match:, slot: or dyn: on the production hot path and pin with fc: anywhere you measure. Watch X-Ringside-Model-Resolved in your logs to catch a roll-forward the moment a family advances.