Choosing a Model

Model selection should follow evidence from the workflow the model will actually run. Public benchmarks can narrow the field, but they cannot reproduce your prompts, tools, context, or failure costs.

Establish the workflow first

Start with a model capable enough to reveal whether the workflow itself is sound. Define the task, context, tools, and verification path before optimising inference cost. Otherwise, model weakness and system weakness become difficult to distinguish.

Once the workflow succeeds consistently, test cheaper models against the same evaluation set. Keep a downgrade only when quality remains above the requirement for that task class.

Match model capability to task risk

Fast, inexpensive models are useful for classification, extraction, routing, and broad research. More capable models earn their cost on ambiguity, architecture, synthesis, and critical review.

The relevant unit is not the price of one call. It is the expected cost of completing the task, including retries, corrections, review, and failures. A cheap model that repeats work can be more expensive than a strong model that finishes once.

This becomes a routing discipline at system scale, covered in Model Usage and Smart Routing.

Prefer operational stability

Models within one family often share behavioural patterns. Staying within a family can make fallbacks and downgrades less disruptive, although every model change still requires evaluation. Cross-family changes frequently require instruction and tool-description changes as well.

Pin exact production versions where the provider allows it. Treat every upgrade as a behavioural change, not a transparent infrastructure update.

Evaluate on your own work

Use representative tasks, previous failures, and high-risk edge cases. Measure completion, constraint violations, evidence quality, latency, and total cost. Published benchmarks are useful for discovery and comparison, but your private evaluation is the strongest predictor of production behaviour.

The Evaluation Harness develops this discipline at system scale. The deeper architectural role of models appears in Foundational AI Model.

With instructions and model selection established, the next chapter turns to the agent’s action surface: tools.