Picking a model is the single biggest lever you have over the cost, speed, and quality of an LLM feature. With Model Database you can reach hundreds of models through one OpenAI-compatible endpoint, so the choice is no longer locked in by your SDK or vendor. That freedom is great, but it also means you need a mental framework for deciding which model to point a given request at.
This guide walks through a practical decision process you can apply to any task, plus how to switch models with a single field.
Start with the four constraints
Every model decision is a trade-off across four axes. Write down where your task sits on each before you look at model names:
- Capability — how hard is the reasoning, instruction-following, or coding involved? A legal-contract analysis needs more than a tweet classifier.
- Cost — how many requests per day, and what is each one worth to you? High-volume background jobs reward cheaper models.
- Latency — is a human waiting on the response, or is this an offline batch? Interactive UX favors faster, smaller models.
- Context — how much text must the model read at once? Long documents and big codebases push you toward large-context models.
Most poor model choices come from optimizing one axis and ignoring the others, such as paying for a frontier model on a task a mid-tier model handles perfectly.
Map task types to model tiers
As a rough starting point:
- Frontier tier (
anthropic/claude-opus-4-8,openai/gpt-4o) — complex reasoning, agentic workflows, hard code generation, ambiguous instructions. - Balanced tier (
anthropic/claude-sonnet-4-6) — most production work: drafting, structured extraction, everyday coding, RAG answers. - Fast/cheap tier (
openai/gpt-4o-mini,google/gemini-2.0-flash) — classification, routing, short summaries, high-volume background tasks. - Open-weight tier (
meta-llama/llama-3.3-70b-instruct,qwen/qwen-2.5-72b-instruct,mistralai/mistral-large) — strong general capability where you want open models or cost control.
These are illustrative groupings, not a strict ranking. Always validate on your own task.
Switching models is one field
Because Model Database is OpenAI-compatible, trying a different model means changing the model string. Nothing else in your code moves.
curl https://modeldatabase.com/v1/chat/completions \
-H "Authorization: Bearer mdb_live_..." \
-H "Content-Type: application/json" \
-d '{
"model": "anthropic/claude-sonnet-4-6",
"messages": [{"role": "user", "content": "Summarize this ticket in one line."}]
}'Using the OpenAI SDK, point the base URL at Model Database and swap models freely:
from openai import OpenAI
client = OpenAI(
base_url="https://modeldatabase.com/v1",
api_key="mdb_live_...",
)
for model in ["openai/gpt-4o-mini", "anthropic/claude-sonnet-4-6"]:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Classify sentiment: 'shipping was slow'"}],
)
print(model, resp.choices[0].message.content)Measure cost and quality empirically
Don't guess which model wins, measure it. Every billable response from Model Database includes X-MDB-Charged-USD and X-MDB-Balance-USD headers, so you can log the exact cost of each model on a representative sample of your traffic.
A simple evaluation loop: take 50 real inputs, run them through two or three candidate models, and compare output quality (a quick human review or an LLM-as-judge) against the charged cost. You'll often find a cheaper model meets your bar, freeing budget for the few requests that genuinely need a frontier model.
Build a fallback ladder
In production, you rarely want a single model. A common pattern is a ladder: try a fast model first, and escalate to a stronger one only when the cheap model is unsure or the task is flagged as high-stakes. Because every model lives behind the same endpoint, escalation is just a second call with a different model value, no new client, no new credentials.
Call GET /v1/models to see everything currently available so your routing logic can stay current as new models land.
Ready to experiment? Grab a key and add credit from your dashboard, then skim the docs for the full parameter reference. Start with a balanced model, measure, and adjust from there.