A plain guide to the AI models, and what each one is actually good at

Ask five people which AI model your company should use and you will get five answers, most of them based on whichever one they happened to try first. The differences between them matter less than the marketing suggests and more than the sceptics claim. Here is how the main families break down, and where each one earns its place in real work.

The big ones

Claude, from Anthropic: Good with long documents, careful with instructions, and less prone to inventing things than most. It errs on the side of caution, which is exactly what you want when it is reading a contract and a mild nuisance when you just want it to make a guess. This is our usual starting point for document-heavy work.

GPT, from OpenAI: The widest ecosystem by some distance. More integrations, more tooling, more people who have already solved whatever problem you are about to hit. Very strong on code. If the priority is connecting to the twelve other systems you already run, this is normally the shortest route.

Gemini, from Google: Handles enormous amounts of context in one go, and deals with video and audio natively. If your company already lives inside Gmail, Drive and Sheets, the integration alone can decide it.

Llama, Mistral, Qwen and the other open models: These are the ones you can run on your own servers. Still a step behind the frontier on genuinely hard reasoning, though the gap keeps closing. Nobody picks them for raw capability. They get chosen when the data cannot leave the building, or when volume is high enough that the cost difference becomes the whole conversation.

The things nobody puts on the landing page

Bigger is not always better. Large models cost more and answer slower. For sorting an email or pulling a supplier name out of a PDF, a small fast model does the job for a fraction of the price. Most of the automations we build use two or three different models, each one handling the step it suits.

The reasoning models, the ones that think before answering, are worth it for problems with several steps. For everything else you are paying extra to wait longer.

All of them still make things up, and they do it with complete confidence. Any process where a wrong answer causes real damage needs a check built in, whether that means verifying against a source system or sending the odd cases to a person. This is not something you solve once. It is something you design around.

Benchmarks are close to useless for predicting your results. A model that tops a public leaderboard can fall apart on your invoices, in Portuguese, with your industry's vocabulary. The only test worth running is the one on your own data.

What we tell clients

The model is rarely the hard part. Choosing between them takes an afternoon. Understanding a process well enough to automate it properly takes considerably longer.

We normally decide on the model near the end of a project rather than at the start, once we know what the workflow has to do, what formats it will meet, how fast it needs to answer and where the data is allowed to sit.

And whatever you pick this year, assume you will swap it within eighteen months. Build the thing so that swap is a settings change and not a rewrite.