Which AI Model for Which Job: Our Practical Matrix

"Which model do you use?" is the question I hear most often. It is almost always the wrong one.

The answer is: several, depending on the task. Across our three brands, four different model classes run side by side on a normal day. There is a reason for that. A model that files an email correctly is too blunt for a product description. And the model that writes the product description would be twenty times too expensive for the filing.

So I am not writing about version numbers. They go stale faster than this article takes to read. I am writing about types of task, and which kind of model fits each one.

Model classes instead of model names

There are roughly three classes, and the difference is the price per task, not the brand.

• Small and fast. Answers in under a second, costs almost nothing, follows simple instructions reliably. It falls apart as soon as several rules apply at once.
• Medium and balanced. The workhorse range. Understands context, sticks to format rules, writes usable text. Costs a multiple of the small class and is still cheap.
• Large and thorough. Thinks across several steps, weighs things up, spots contradictions. Takes noticeably longer and costs a lot more. Wasteful for most tasks, irreplaceable for a few.

This split survives every change of provider. The names underneath change every few months, the classes stay.

Task type 1: Classifying

One input goes in, one of a few categories comes out. Filing a support email, detecting the language, judging urgency, sorting out spam.

Recommendation: small and fast. This is the simplest task there is, and the results are nearly as good as with large models. Our entire support triage runs this way. How it is built is described in Pre-sorting support emails with AI.

Two things matter more than the choice of model. First: define the categories yourself, no more than ten, each with an example. Second: explicitly allow a category called "unclear". Without it, the model guesses and gets it wrong.

Classifying is also the task where you save the most money. At a thousand requests a month, the difference between small and large is the difference between a coffee and a restaurant bill.

Task type 2: Summarising and extracting

A long text goes in, the essentials or a few fields come out. Cutting a customer email down to the core, pulling invoice data from a PDF, building a weekly report from numbers.

Recommendation: small to medium. As long as the original text comes along, small models work cleanly too. They invent little because they do not have to invent anything.

Medium becomes necessary when the text is unstructured or mixes several languages. At MUSTAX, a medium model pulls line items out of supplier invoices, because every supplier has its own layout. The reporting around it used to take 2 days and now takes 2 hours.

Rule of thumb: the more predictable the input format, the smaller the model can be.

Task type 3: Writing

Text a customer will read gets created from a brief. A reply email, a product description, a newsletter paragraph.

Recommendation: medium. This is where the small class gets noticeably worse. The text becomes clunky, repeats itself, misses the tone. The large class in turn barely writes better and costs a multiple.

The bigger lever is not in the model anyway. It is in what you hand over. Three example texts in your tone improve the result more than any change of model. We keep a short style brief for each brand, plus five sample replies.

And: text containing facts always needs a checking step before it goes out. What holds up in customer contact and what does not is covered in AI in customer service, what actually works.

Task type 4: Deciding

Several rules, exceptions, and a judgement at the end. Is this goodwill case defensible? Does this return fit the policy? Should we reorder from this supplier?

Recommendation: large and thorough, plus human approval. This is the only task type where the large class genuinely pays off. It holds several conditions in mind at once and notices when two rules contradict each other.

Even so, it decides nothing on its own here. Where money, rights or trouble are involved, a human clicks. Why that line is fixed is explained in the guide to customer service automation.

One addition: many supposed decision tasks are not decisions at all. If you can write the rules down, they belong in code. Code is cheaper, faster and always the same. You only need a model once the rules are written in prose and come with exceptions.

The matrix

The last row is the one that saves the most trouble. Percentages, deadlines and amounts never belong in a language model.

Cost and speed, thought through concretely

I deliberately avoid naming absolute prices here, they change too often. The ratios are more stable.

Between the small and the large class we see roughly a factor of 20 to 50 per call. On speed, the difference is between under a second and several seconds.

What that means in practice: at ten calls a day, the choice of model is irrelevant. Take the good one. At ten thousand calls a day, it is your second largest cost item after hosting.

On speed, one trap that often gets missed. A chat on your website needs an answer in under two seconds, otherwise the customer clicks away. A nightly report may take ten minutes. Same task, two completely different model decisions. More on that in AI chatbot for your website.

Build so that you can switch

This is where most setups suffer. If the model name sits in the code twenty times, every switch becomes a project.

Here it sits in one place. Every workflow asks for a tier rather than a model: fast, normal or thorough. Which model sits behind it is defined in a single configuration. A change of provider is then one line, not a rebuild.

There is a second building block that goes with it: a handful of saved test cases per task. Twenty real support emails with the correct category next to them, ten product texts with the desired result. Before every switch, those run through. It takes minutes and answers the question "is the new model better here" with data instead of gut feeling.

Without those test cases, every model decision is a matter of taste. With them, it is a measurement.

The limits of this matrix

It is our practice, not a law of nature. Four places where it does not hold:

• Very specialised terminology. In medicine, law or chemistry, model classes behave differently from what is described here. Only testing helps there.
• Languages other than German and English. Small models drop off far more sharply on rarer languages than large ones do. Our recommendations apply to German.
• Very long inputs. Beyond a certain volume, small models lose the middle of the text. If you are processing whole contracts, the table does not apply.
• Data protection beats quality. If personal data is not allowed to leave the building, you decide by the hosting question, not by task type. A smaller self-hosted model can then be the only option, even if a larger one would be better. The same trade-off as with n8n self-hosting versus cloud.

And one caveat at the end: we measure quality against our test cases, not against leaderboards. What wins here can lose at your place.

Conclusion

Do not look for the best model. For each task, look for the smallest one that still solves the task cleanly. That is cheaper, faster and usually just as good.

The rest is craft. Cut tasks small, hand over examples, maintain test cases, keep the model choice in one place. Whoever has that can meet any new model in half an hour instead of in a sprint.

If you want to know which tier is enough for your tasks: get in touch with Flowhouse. We will work through it with you, even if no model turns out to be necessary.