Choosing a model for a task

A practical framework for matching a job to a model family and price point, instead of defaulting to the biggest model available.

The most common mistake teams make on a multi-model gateway is picking one "good" model and sending everything to it. That's simpler to write, but it's rarely the cheapest or fastest way to get the job done.

Start from the job, not the model

Ask three questions about the task before picking a model:

1. Does it need reasoning, or does it need recall? Classification, extraction, and formatting tasks rarely need a frontier model — a small, fast model gets the same answer for a fraction of the cost.
2. Is the output checked by a human, or consumed by code? If a downstream step validates the output (a schema, a test, a second model pass), you can afford a cheaper first attempt and only escalate on failure.
3. What's the cost of being wrong? Customer-facing writing and irreversible actions (sending an email, executing a trade) justify a stronger model even at higher cost; internal drafts and low-stakes summaries don't.

A rough starting map

• Cheap and fast — classification, tagging, short extraction, simple rewrites. Route here by default.
• Mid-tier — summarization, multi-step instructions, most agent tool-calling.
• Frontier — long-context reasoning, ambiguous judgment calls, anything customer-facing where quality is the product.

See Supported models for the current catalog and pricing, and Model routing for how to encode this map as a declarative rule instead of an if/else in your app.