Choosing models
On Ringside the `model` field is more flexible than a single provider name. You can pin an exact model, or ask for the current best in a family and let Ringside resolve it. Same field, two grammars.
One field, many providers
The model value selects across providers, not just OpenAI. The format is <grammar>:<provider>/<model>. Anthropic, OpenAI, Google, Mistral and others sit behind the same call, so switching from one to another is a string change, not a new SDK or a new key.
fc: pins an exact model
A reference like fc:openai/gpt-4o-mini means exactly that model, every time. Use this when you want reproducible behaviour: the model will not change under you, so your prompts and evals stay valid until you decide to move. It is the safe default for production paths you have tuned.
{ "model": "fc:openai/gpt-4o-mini", "messages": [ ... ] }
{ "model": "fc:anthropic/claude-haiku-4-5", "messages": [ ... ] }
{ "model": "fc:google/gemini-2.5-flash", "messages": [ ... ] }match: rides upgrades
A reference like match:anthropic/sonnet>=4 means "the current best Sonnet at version 4 or newer". When the provider ships a newer one, Ringside resolves to it without you redeploying. Use this when you would rather track the frontier than pin a snapshot, for example a general assistant where newer is simply better.
Ringside tells you what it picked. The response carries headers like X-Ringside-Model-Resolved (the concrete model that ran) and a flag when a newer match is available, so a match: reference is never a black box.
{ "model": "match:anthropic/sonnet>=4", "messages": [ ... ] }
// resolves to whatever the best matching Sonnet is right now;
// X-Ringside-Model-Resolved in the response says which one ran.Which to use
A simple rule.
- ·
Tuned production path, fixed evals, you do not want surprises:
fc:(pin it). - ·
General-purpose, you want the newest capability automatically:
match:. - ·
Embeddings for a vector store: use the bare model name (for example
text-embedding-3-small), not a grammar prefix. The store pins it for you.
Access and fallback
Some providers need their access configured before a model will resolve; if one is not available you get a clear error rather than a silent swap. Pricing follows the underlying provider with a small, visible platform margin, so a cheaper model is cheaper here too. There is nothing to install per provider: once access is set up, every model is reachable from the same endpoint with the same key.
That is the platform core: a call that works, spend metered per customer, and models chosen by reference. From here, the RAG guide adds search-over-documents, the tutorials build whole things end to end, and the API reference has every endpoint with its options.