The right model for each request
Classify with a light model, reason with a strong one. How to choose the model per task, and test your way to the lightest one that does the job.
2 min read
Not every request deserves your strongest model, and not every request can get by with your cheapest. Agent200 lets you choose the model per request, so the choice can follow the task instead of being fixed for the whole application.
One application, several models
Picture a support agent. It classifies incoming messages, looks up the customer, drafts a reply and occasionally writes a long summary of a difficult case. Those are four tasks with very different needs:
| Task | What matters most |
|---|---|
| Classify a message | Speed and cost |
| Look up and combine context | Reliable tool use |
| Draft a reply | Tone and accuracy |
| Summarize a long case | Reasoning over a lot of material |
Choosing in code
The model is a field in the request, so each task picks its own.
Conceptual example.
const label = await agent200.run({
model: "openai/gpt-5.6-sol",
input: message,
instructions: "Classify this message as billing, technical or other.",
});Swap the model string for a different task, and that request runs on a different model. The model you choose is the one that drives the request’s tool-calling loop.
A simple way to decide
- Start strong. Build the task on a capable model until the output is right.
- Write a small test set. Ten to twenty real inputs with the answers you expect.
- Step down. Try a lighter model on the same set.
- Keep the lightest model that passes. Re-run the set when you change instructions or tools.
No new accounts to try one
The catalog includes models from providers such as OpenAI, Anthropic, Google Gemini, Meta, Mistral, Cohere and xAI. Trying a model from another provider does not mean opening an account, adding a key or wiring a new SDK: it is the same Agent200 key and the same statement.
The cheapest model that does the job well is the right model for that job.
Keep the choice visible
Put the model for each task in one place in your configuration rather than scattered through your code. When a better or cheaper model fits a task, you change one value and run your test set.
See every supported model in the integrations catalog, and what you pay for on the Pricing page.
