Skip to navigation

Chat Models

View as Markdown

Use chat models for text generation, coding help, reasoning, extraction, and multi-turn assistant workflows. This page helps you choose a chat model. To send requests, use the canonical Chat Completions API guide.

Choose a model

Start from the Models table and compare these fields:

FieldWhy it matters
Model IDThe exact value to pass in the model field
Input priceCost of prompt, conversation history, tool definitions, and retrieved context
Output priceCost of generated tokens
ContextMaximum working window for prompts, files, history, and tool results
RoutesAvailable provider supply for the model
SupplyWhether the route is verified
StatusWhether the model is currently live

For initial testing, pick a low-cost live model such as qwen3.5-flash. For coding-heavy workloads, start with a coding-oriented model such as kimi-k2.7-code. For long documents or agent workflows, choose a model with enough context for the full prompt and expected tool output.

Common selection patterns

NeedPrefer
Fast smoke testsLow input and output price, live status, moderate context
Coding assistanceCoding-capable chat model, enough context for repository snippets
Long-context analysisHigh context window and predictable output cost
Multi-turn assistantsLow input price, because history is resent with each request
Tool callingA model that supports function calling; see Function Calling
Production trafficVerified supply, live status, and enough fallback capacity

Context planning

Chat requests include everything you send in messages: system instructions, user input, previous turns, retrieved documents, and tool results. Larger context is useful, but it also increases input-token spend.

Before launching a workload:

  • Estimate the largest realistic prompt.
  • Include conversation history and retrieved context in that estimate.
  • Leave room for tool outputs if the model calls functions.
  • Set max_tokens low enough to control runaway output cost.
  • Use summarization or retrieval instead of sending unbounded history.

Pricing notes

Chat model pricing is usually split between input and output tokens. Compare both columns before choosing a model.

  • For short prompts with long answers, output price matters more.
  • For agents, RAG, and multi-turn chat, input price often dominates.
  • For coding tasks, context size can matter more than raw token price.
  • For production, re-check the Models page before routing new traffic because model availability and pricing can change.

Routing

By default, omit route and let OpenModels use the default available route for the selected model. Pin a provider route only when you need a specific provider for testing, compliance, latency, or deterministic cost comparison.

See Chat Completions for the request shape and route.provider syntax.

Production checklist

Before moving a chat workload to production:

  • Confirm the model is live in the Models table.
  • Confirm the selected model has enough context.
  • Check input and output prices against your expected usage.
  • Add credits and configure monthly spend limits for the API key.
  • Decide whether the workload needs streaming or function calling.
  • Log model ID, token usage, request ID, and gateway errors.

Next steps