Skip to content
ResetData Docs

Choosing a model

If you don’t yet have a reason to prefer a particular model, start here. The catalog has the full list; this page is about picking one.

Start here

Section titled “Start here”

General chat, reasoning and agentic work — zai/glm-5.2. Our flagship. A large reasoning model with a very long context window and strong tool use, so it handles long documents and multi-step work that smaller models lose track of. It is the most capable option we serve, and priced accordingly — start here to establish what “good” looks like, then decide whether something cheaper is sufficient.

Code — qwen/qwen3-coder-30b-a3b-instruct. Trained specifically for code generation and editing, with a long context so it can hold a substantial amount of a codebase at once. For code tasks it is generally the better value than a general model of similar size.

High volume, cost-sensitive — meta/llama-3.1-8b-instruct. The cheapest text model we serve by a wide margin, and the fastest. For classification, routing, extraction, short summaries and other high-volume work where the task is well defined, a small model is frequently indistinguishable from a large one at a fraction of the cost.

A balanced middle — google/gemma-4-26b-a4b-it. More capable than the 8B option, far cheaper than the flagship, with a long context. A sensible default when the small model isn’t quite good enough but the flagship is more than you need.

Transcription — openai/whisper-large-v3-turbo. Speech to text, billed per minute. See Audio.

Images — black-forest-labs/flux-1-schnell. Fast image generation, billed per image. See Image generation.

How to decide

Section titled “How to decide”

Work down these in order — the first one that rules a model out saves you evaluating it.

  1. Modality. Text, image, audio and embedding models are not interchangeable. Start from the category, not the name.
  2. Capability. If you need tool calling, confirm the model declares it — several capable text models don’t. See Tool calling.
  3. Context. Sum your worst-case system prompt, history, retrieved documents and expected output. Context windows vary by more than an order of magnitude.
  4. Quality. Only your own task can settle this. Public benchmarks are a weak proxy for whether a model does your job.
  5. Cost. Input and output are priced separately, and the ratio matters: summarisation is input-heavy, generation is output-heavy. Estimate with your real token mix, not an average.
  6. Latency. Larger models are slower, and reasoning models slower still. If a user is waiting, this may outrank quality.

A sensible method

Section titled “A sensible method”

Start with the strongest model, then move down. It is much easier to tell whether a cheaper model is still good enough than to work out whether a weak result means the model is wrong or your prompt is. Establish quality first, then optimise cost.

Route by difficulty. Many production systems use a small model for the bulk of traffic and escalate only hard cases. This is usually a bigger saving than any prompt-level optimisation.

Evaluate on your own data. Assemble twenty or thirty real examples with known good answers and run candidates against them. A morning spent on this beats any amount of benchmark reading.

Re-check when you switch. Sampling parameters, tool support and output caps all differ between models — see Model parameters before swapping one in.