Skip to Content

How to Choose an AI Model for the Job

Five questions that outlive every model generation. The sixth — "which one is best?" — is the one not worth asking.
September 11, 2026 by
How to Choose an AI Model for the Job
Krisztian Eyssen, Krisztian Eyssen

Why is "which is best" the wrong question?

Because there is no answer that stays true for more than a month, and because "best" is not a single property. A model can be the most accurate and twenty times more expensive at the same time; it can be the fastest and the weakest in your language.

In practice, choosing a model is filtering, not ranking. Five questions, and among whatever is left it no longer matters much which one you take.

1. Where is the data allowed to run?

This comes first because it excludes rather than ranks. If customer data, health data or contracts pass through it, the question is not which model is better but which provider you have an agreement with that permits it.

If the answer is "it must not leave the EU" or "it must not leave the company", the field shrinks to a fraction at once — and within what remains, the quality difference is typically smaller than the compliance risk. European AI Options covers this in detail.

2. How big is the task, and how often does it run?

There are two extremes, and they call for completely different models.

Rarely, but it matters a lot. A contract review, a strategy document, a proposal. Ten of those a month. Here even the most expensive model is cheap — the difference is a few euros, while the cost of a wrong answer is not a few euros.

Often, with small stakes. Categorising five thousand incoming emails a day. Here the model price is your total cost, and the cheapest tier is usually enough. Fast and Cheap or Slow and Smart? works through that decision with numbers.

Most teams do it the other way round: they run the everyday bulk work on the top model and drop the important decision into a chat window.

3. Does it need thinking or only transformation?

This question settles the model tier, and it sorts tasks into three groups:

  • Transformation. Summarising, translating, rephrasing, extracting data. Even the cheapest tier does this well.
  • Judgement. "Which of these two?", "What is missing from this?", "Is this objection valid?" Here the model starts to matter.
  • Derivation. Multi-step calculation, debugging code, reasoning from sources that contradict each other. This needs reasoning mode, and this is where the more expensive tier earns its price.

The trap: transformation looks simple, and it is — but when it runs on twenty thousand rows, that is where the model choice matters most.

4. In which language?

English goes well on every model. In every other language two things get worse: the quality and the price.

Hungarian text breaks into 2.71 times as many tokens as English of the same length; Spanish 1.46 times. That multiplier lands directly on your bill, and it eats your context window by the same factor. Quality varies enormously between models — that has to be measured, not guessed, and Which Models Handle Smaller Languages Well shows how to do it in five minutes.

5. Does it need tools or only text?

If at the end of the task the model has to do something — search the web, read a file, call an API, run code — then you are not choosing a model but a system. That is a different decision, and Chatbot, API or App? is where it gets settled.

Same thing if it has to process images, audio or video: that narrows the field — not every model is multimodal, and the ones that are are not equally good at all of it.

The practical order

Those five questions do not carry equal weight. This is the order to work through them:

  1. Data — this excludes. What is not allowed is not allowed.
  2. Capability — language, modality, tool use. Whatever cannot do it drops out.
  3. Tier — transformation, judgement or derivation.
  4. Price — only within what is left, and only if it runs often.
  5. Measurement — decide between the remaining two or three on your own tasks.

The fifth step is the one almost everyone skips, and it is the only one that answers your situation. Twenty real tasks, two models, one afternoon — Run a Two-Week Model Bake-Off sets that out as a recipe.

What not to weigh

The leaderboard. It does not lie, it just does not measure your task. The most-used models are regularly not at the top of the list — that is what Leaderboards vs Real Use is about.

The announcements. A new model is not better on your task merely by being new. The only thing that tells you is your own test set.

The vendor's name. Within one vendor the gap between tiers is bigger than the gap between vendors at the same tier. Knowing the big model families is useful, but it is not what makes the decision.

One decision, worked through

The task: from incoming customer complaints, produce a category, an urgency and a one-sentence summary. 300 a day, in Hungarian.

  1. Data: it contains customer names and email addresses → an EU endpoint or a data-processing agreement is required. That excludes part of the field.
  2. Capability: Hungarian text, no images, no tools. A text model will do.
  3. Tier: this is classification, so transformation plus a pinch of judgement. No derivation needed.
  4. Price: 300 a day × 30 days = 9,000 runs a month. Here the gap between the cheapest tier and the top model is tenfold — that now matters.
  5. Measurement: take 40 real complaints, run them on the two cheapest candidates, and count how many get categorised wrong.

The decision is made on those 40 complaints, not on the leaderboard. And when a new model arrives in six months, those same 40 complaints will tell you whether switching is worth it.

What to take away

Filter first, choose second. Data and capability exclude, tier and price rank — and the final decision comes from measurement on your own tasks, not from a ranking. These five questions still work when every model has a new name tomorrow.

How to Choose an AI Model for the Job
Krisztian Eyssen, Krisztian Eyssen September 11, 2026
Share this post
Archive