Choosing an LLM for Business: Claude, GPT, Gemini, Mistral

Any answer to this question expires in about a quarter.

Choosing an LLM for business is a real decision with a short shelf life. The four families that matter to a European company are Claude, GPT, Gemini and Mistral, they leapfrog each other every few months, and any article naming a winner is naming the winner of a race that was rerun after it was published, including this one. So the useful deliverable is not the choice. It is the two things that survive the next release: fifty of your own examples with known correct answers, and an interface you own so that swapping the model behind it is a configuration change rather than a project. Build those and the question stops being strategic and becomes a Tuesday afternoon. Skip them and you will be having this argument again in March, from scratch.

Why the best LLM for business is the wrong thing to search for

Two things are worth saying before any comparison. Version numbers and prices in this market change monthly, so everything below is written at the level of what stays true: how the families are shaped, where each is structurally different, and which properties are worth checking on a provider’s own pricing page on the day you decide. Take the shape from here and the numbers from them.

The second thing matters more, because the best LLM for business is a title that only makes sense per task. Public leaderboards measure performance on somebody else’s task, and the gap between the top few models on those boards is now smaller than the gap between a good prompt and a careless one on your own data. A model that ranks third on a public benchmark and first on your fifty invoices is the correct choice, and you cannot learn that from any ranking. Building the test set takes an afternoon. It is the single highest return activity in this entire subject and almost nobody does it before committing.

An LLM comparison that stays true between releases

• Tier, not brand. All four families ship the same three rungs: a frontier model, a mid model, and a small fast one. The price spread between the top and bottom rung within a single family is larger than the spread between families at the same rung, so picking the tier is a bigger cost decision than picking the vendor. Most business workloads run happily on the middle rung.
• Cost per task, not per token. Headline token prices mislead because a chattier model that needs fewer retries can be cheaper in practice. Measure what one real unit of your work costs end to end. And check caching: the major providers bill the repeated part of a prompt at a steep discount, commonly around a tenth of the standard rate, which makes prompt structure a cost decision rather than a style one.
• Context window, and what it costs at the top of it. Very long context, around the million-token mark, is now available at the top of each family. Read the pricing carefully: several providers step the rate up beyond a threshold, so a workload that habitually fills a large window can cost multiples of what the headline figure implies.
• Latency, which is a product decision. A user waiting for a chat reply notices a second. A nightly batch job does not notice a minute. Reasoning-heavy modes trade seconds for quality, and choosing the slower setting for an interactive surface is one of the more common self-inflicted adoption problems.
• Where it will run. The structural differentiator for a European buyer, and the one that does not shift with each release. Mistral is EU-domiciled, which removes the transfer question at the vendor level. The others are reachable inside EU regions of the major clouds, which answers it a different way and at a different price. Which of those you need is set by your data class, and the reasoning is in GDPR and LLMs.
• Tool use and structured output. The dimension that decides whether a model can sit inside an automated pipeline at all. What matters is not whether it can call a tool but how often it returns output your code can parse without a retry, and how it behaves when it should decline to call anything. Families differ here more than they differ on general quality, and the difference is invisible in a chat window and obvious in a log. Test it with malformed and adversarial inputs, not with the happy path.

Nothing in that LLM comparison requires you to know which version is current. Every line is a property you can check on the day you decide, against the provider’s own documentation and your own test set.

Which tier each kind of work actually needs

Classification, tagging and routing: the small fast rung. Is this invoice or a contract, which of six queues does this ticket belong in, what language is this. The cheapest models handle this at a quality that is difficult to separate from the frontier ones on a blind test, and the cost difference at volume is the difference between a rounding error and a budget conversation.

Extraction from documents: small to middle. Clean, structured sources sit at the bottom rung. Poor scans, inconsistent layouts and tables that span pages move you up. This is the workload where your own test set pays for itself fastest, because the honest answer varies by document and not by vendor. The LexAlert monitoring platform ingests from three official gazettes with exactly this profile, and the useful lesson from that build is that the deduplication and routing around the extraction took more engineering than the model choice did. Our other case studies repeat the pattern.

Drafting in your voice: the middle rung, with work. The variable here is not model quality, it is the examples and constraints you give it. A mid-tier model with twenty good examples of your own writing beats a frontier model with none, at a fraction of the price.

Reasoning over long documents, and agents: the frontier rung. Where the differences between families are still wide enough to matter, and where they change most between releases. If your workload lives here, retest when a new version ships rather than assuming your choice from last year holds. Agent work in particular compounds small per-step differences into large per-task ones, for the reasons set out in agents versus chatbots versus automation.

Multi-model by default, and avoiding lock-in

Nobody should run one model for everything, and the reason is cost rather than ideology. A system that sends a routing decision to a frontier model is paying fifty times what the job needs. A multi-model arrangement puts each task on the cheapest rung that passes your test set, which typically means two or three models in one application, chosen per call.

Lock-in is mostly a self-inflicted problem and it is cheap to avoid if you do it at the start. Keep model calls behind one thin interface in your own code rather than scattered through the application. Keep prompts in files rather than embedded in logic. Keep the evaluation set in the repository. Do those three things and switching provider is a day of work and a re-run of the tests. Skip them and it is a rewrite, which is how companies end up staying with a model they have outgrown. The same portability argument applies to the open-weights branch of this decision, which we costed separately in self-hosted versus API, and the general build economics are in what a custom AI build costs.

One practical warning. Provider-specific features are convenient and they are the fastest route back into lock-in, because they rarely have equivalents elsewhere. Use them where they earn their place, and know as you do it that you have priced the exit up.

Three ways this decision gets made badly

Choosing from a benchmark table. The differences at the top are within the range that prompt quality moves, and the tasks measured are not yours. Use the table to build a shortlist of three, then decide on your own data.

Standardising on one provider for procurement neatness. Understandable, and it usually costs more than it saves, because it forces every task onto whichever rung that provider does well. If the policy is fixed, at least use the full range of tiers inside the family.

Revisiting the choice every time something is announced. The opposite failure. A model that passes your test set and runs in an acceptable region does not need replacing because a competitor published a better score. Set a review date, twice a year is plenty for most workloads, and re-run the test set then. Anything more often is a hobby.