Pick the right AI model for the task

The most useful AI model is the one that does your job well, at a speed and cost that work for you. A quick email edit, a tricky software bug, and a research project ask for different things.

Use the graph above to build a shortlist. Then give those models a small piece of your actual work. This guide walks you through both steps, so your choice comes with a reason you can explain.

Read the graph before picking a winner

Each dot represents a model evaluation configuration. Select a dot to see its name, score, and weighted input price. Use the menu to switch between coding, intelligence, and agentic benchmarks.

• Higher on the graph: a higher score on the selected benchmark.
• Further left: a lower weighted input price.
• Best-value frontier: highlights a shortlist of competitive price/performance options among the plotted models.

A model near the upper-left corner can be worth testing. The chart shows 20 models for each metric, so a model outside this view may still suit your work. Check the retrieval date below the graph to see when this snapshot was collected.

The source is Artificial Analysis via OpenRouter’s benchmark comparison. OpenRouter’s usage rankings measure something different: how much models are used through its platform. Popularity and benchmark performance are separate signals.

Describe the task and what good looks like

Before you choose a model, finish this sentence:

I need AI to turn this input into this output, and I will check it by…

For a workshop brief, that might mean turning a client conversation into an agenda with timings and practical exercises. For software, it might mean fixing a bug while the existing tests continue passing. For customer support, it might mean assigning the correct category and flagging uncertain cases.

Write down three things: the result you need, the inputs the model must use, and how you will judge the answer. This gives your comparison a purpose.

Match the starting model to the work

The table below is my practical starting framework. Use it to choose candidates for your own tests.

For a well-defined, repetitive task, I would try an efficient option early. For a demanding project with several dependencies, I would first establish that a more capable option can do the job, then see whether a lighter one performs well enough. Anthropic describes both approaches in its model-selection guide.

Check the tool as well as the model

You are usually choosing a whole working setup. A model inside a chat app can have different tools and access from the same model in an API or coding agent.

For example, a website task may require reading several files, editing code, running a preview, and checking the result in a browser. The setup needs to support those steps. A high benchmark score alone does not give a model access to your repository.

Check the capabilities offered by your chosen product and model version. These can differ across products, as OpenAI’s model-selection guidance explains. Explore the tools page if you also need to choose where you will use the model.

Run a small comparison on your real work

Shortlist two or three candidates. Use the same brief, inputs, and success criteria for each. Record the exact model and settings, because changing the reasoning effort or enabling tools changes the comparison.

My suggested starter test has five examples:

1. A typical task you do often.
2. A slightly messy version of that task.
3. An example with missing information.
4. A harder case that needs careful judgement.
5. An example where the correct response is to ask a question or flag uncertainty.

Score the useful outcome. How much did you need to fix? Did a citation support the claim? Did the code run? Would the structured output work in your next step? Keep the test small enough that you will actually do it.

Task:
Inputs or source material:
Required output:
What counts as a successful result:
Important constraints:
Tools or media needed:

Run the same five examples with each candidate.

For each model, record:
- Exact model and settings
- Correctness: 1–5
- Following the brief: 1–5
- Editing or checking time required
- Time to a usable result
- Cost, if available
- Any failure that would prevent using it

Choose the option that meets the quality bar with an acceptable amount of time, cost, and review.

Provider guidance also recommends testing with your actual prompts and data. See Anthropic’s evaluation steps and OpenAI’s advice on comparing the same inputs.

Compare the cost of getting a useful result

The price of one million input tokens gives you one part of the picture. Output length, reasoning tokens, caching, and repeated attempts can change the full cost. Artificial Analysis distinguishes input price, output price, and cost per completed benchmark task in its methodology.

Here is a hypothetical example: a cheaper model produces a draft that takes 20 minutes to correct. Another costs a little more and produces a draft you can finish in five minutes. Depending on how often you do the task, that difference may matter more than the token-price gap.

For an occasional chat, compare the time and effort you spend getting a usable answer. For an automation, measure cost per successful run, including retries and any human review. Keep subscription pricing separate from API pricing; the graph’s input-token prices are not a prediction of your chat subscription bill.

Adjust the settings, then revisit your choice

Some models let you choose how much reasoning effort they use. A different setting may improve a difficult result, or make a simpler task faster. Compare the settings available in your tool before assuming you need a different model. OpenAI’s guidance discusses this quality, cost, and latency trade-off.

Keep a short note explaining your choice: “We use this model for this task because it passed these examples within our time and cost limits.” Revisit that note when your task changes, a new candidate becomes available, or failures start to appear.

You can use more than one model across your work. A fast option might handle routine extraction, while a stronger option handles ambiguous cases. Add that complexity only when it solves a problem you can observe.

Ready to put the choice into practice? Try the process while building a website with AI, or bring a real workflow to a team workshop.