Choose a model by the work it must complete, then measure quality, latency, and cost on representative requests. The catalog owns the current model inventory and capabilities; use it instead of copying a fixed list into your application.
Start with required capabilities
| Workload | Check before choosing |
|---|---|
| Text chat or summarization | Context limit, output limit, answer quality, and price. |
| Coding or security agent | Tool calling, tool-choice modes, complete argument generation, and multi-turn reliability. |
| Classification or extraction | Response-format capability and validation success on your schema. |
| Screenshot or diagram inspection | Explicit image-input capability and adequate visual accuracy. |
| Repeated long-context work | Context fit, reported cache usage, uncached cost, and reservation headroom. |
red-cyber-1 is a text-only Beta model aimed at authorized security work, with tools and structured output. Choose a model advertising image support for visual work. Related names do not imply identical capabilities, checkpoints, or behavior. Review Compatibility before assuming a client's preferred wire format supplies its usual hosted tools.
Separate context from output
A large context lets a model receive more material. It does not enlarge RedRouter's 8,192-token output cap. Reserve room for the complete answer, reasoning where reported, and tool arguments. An agent can need a larger output budget than a short chat even when the visible final answer is brief.
Set an explicit per-request output limit. Low limits can truncate tool calls; very high limits increase the credit reservation. For long answers, split the task into independently useful sections rather than assuming one request can produce an unlimited document. Token counting supplies a conservative preflight estimate, not an exact context-fit test.
Compare on a small evaluation set
Build examples from your actual workload, including easy cases, ambiguous inputs, and failure cases. Keep the instructions and evaluation criteria fixed while changing only the model. Record the exact public model ID, request settings, terminal status, reported usage, and whether the result passed your application checks.
Useful measurements include:
- Answer correctness or reviewer acceptance, with a clear rubric.
- Schema-validation success and complete tool arguments.
- Time to first useful output and time to terminal completion.
- Total reported input/output tokens, reported cache reads, and final cost.
- Failures requiring a retry, repair, or human review.
Evaluate a whole tool workflow rather than only its first reply. A lower per-token rate can cost more if it needs repeated repairs. Cache-dependent savings should be measured separately from a no-hit budget. See Dataset generation for a bounded evaluation queue.
Make the choice explicit
Send the selected public ID on every request. RedRouter can route the same model between configured hosts, but it does not automatically pick another model for your application. A requested unavailable model fails; your application decides whether a different model is an acceptable fallback.
If you implement application-level fallback, record which model produced each result and validate both against the same requirements. Do not silently fall back from a required capability to prompt-only behavior. This matters for Messages structured output, which can accept a schema as an instruction on models without format support.
Roll out a measured change
Keep the previous model configuration available in your application, run a small representative sample, and compare completed results before increasing traffic. Set a bounded retry policy and concurrency limit; avoid treating a timeout as proof that no billable generation occurred. Pin your SDK version and rerun compatibility checks when upgrading it.
Use Models & pricing, Production, Prompt caching, and Troubleshooting to turn the selection into a predictable deployment.