TL;DR. Most mid-sized companies ask “Which AI model is the best?” and mean the top of a benchmark table. That is the question that almost never decides their day-to-day work. The right question is not which model, but what you are optimising for: raw peak capability, or control, portability, customisation and running costs. At the top, closed frontier models lead clearly, at the end of October by 59 to 32 points in the Artificial Analysis index. But most operational work does not need that peak. The mature answer is usually not a camp but a switch: routine work runs on an open or small model, the rare hard request goes to the top.
The uncomfortable thesis first
Many companies buy a Formula 1 engine to drive to the bakery. They optimise for the top of the benchmark and solve a problem they do not have. Most AI tasks in a normal company look like this: sorting emails, summarising quotes, reading fields from invoices, routing tickets, answering questions from their own documents. None of these tasks needs a frontier genius. They need reliability. And reliability is not a property of the model but of your control over the model.
That is why “open or closed” is the wrong question. The real question is one of optimisation. Let us sort it honestly, in both directions.
Capability: honest, without camps
Two things are true at once, and you have to live with both.
First half, for the friends of open models: at the top, the closed frontier models lead. In multi-step reasoning, demanding coding across large codebases and very long, coherent contexts, GPT, Claude and Gemini are ahead. That is measurable, not marketing. In the Artificial Analysis Intelligence Index at the end of October, Gemini 4 Carbon scored 59 and Claude Opus 5.5 58 points. The best open models reached 32, Mistral Large 4 as the strongest Western one 26.
Artificial Analysis Intelligence Index, as of October 30, 2026
closedopen weights
Second half, for the frontier optimists: the gap matters less for everyday tasks than the leaderboard suggests, and open models keep getting stronger. DeepSeek has shown that strong reasoning does not have to live behind a closed API. Qwen is a serious option for extraction and tool use. Mistral, Llama and Gemma are robust workhorses for classification, summarisation and RAG. And with Teuken there is a model from Germany trained for the 24 official languages of the EU.
The non-obvious insight in between: the benchmark top and your actual workload are two different distributions. Quality rarely comes from the model’s last percent of capability. It comes from everything around it: the data, the prompt, the retrieval. A well-connected open model with clean retrieval beats a frontier model with poor context every day. For the bulk of tasks in a mid-sized company, the top is simply oversized.
That settles the capability question, and that is exactly why it was never the real question. Let us look at the axes that really decide.
Axis 1: control and data
A closed frontier model is someone else’s API. You rent intelligence per token, without your own engine room, brilliant from day one. A model with open weights such as Mistral, Llama, Qwen, Gemma, DeepSeek or Teuken reverses the relationship. The weights are with you, the model runs in-house or at a host of your choice, the data never leaves the premises.
This is not about casting US vendors as villains. An API from OpenAI is not “evil”. It is a sober matter of choice. If you process patient data, design drawings or client files, you may not want to give up control. Pro-EU here means data sovereignty, not isolation. With open weights, you decide where the data lives. What that costs in concrete terms is calculated in our post on running Mistral in-house.
Axis 2: lock-in and portability
The often underestimated and actually strategic point: a closed model can change underneath you. A silent update, and a prompt that ran cleanly yesterday gives different results today. Sometimes the model disappears altogether. Google routes requests for Gemini 2.5 Pro and Flash to newer models from December 1, 2026. Anthropic has removed Claude Opus 4, Sonnet 4 and Haiku 3.5, among others, from its own API. That is no conspiracy, it is product maintenance. Only your product is built on it. Without tests and monitoring, you notice the regression only when a customer reports it.
A downloaded model with open weights is frozen. Today’s Qwen3 is the Qwen3 of two years from now. It ages, but it does not tip over overnight. You decide when to switch, not the vendor.
And now the insight that carries the whole thing: lock-in is not a pricing problem but an architecture problem. The dependency that really hurts does not come from the bill. It comes when your prompts, your tool definitions and all your logic have grown around one vendor’s quirks. Then switching vendors is not a toggle but a rebuild. Open standards such as the Model Context Protocol are exactly the insurance against that. They decouple tools and data from the specific model, so the model becomes a replaceable component rather than the foundation.
Axis 3: customisation
Open weights allow real fine-tuning and distillation. You can trim a small Qwen to your domain until it hits your jargon better than any general model. Or you distil a large model into a lean, specialised one that does your one task better. With a closed API, your customisation usually ends at the prompt, limited to what the vendor allows. When the task is narrow and the volume high, a small, specialised model often pays off more than constantly reaching for the top. Where small models belong is shown in our test of Haiku 5.5 (in German).
Axis 4: cost structure
Closed models bill by usage: you pay per token, without your own operating effort, conveniently from day one. Open weights shift costs from usage to operations and, depending on the setup, to hardware. On rented GPUs this remains running cost for compute and staff. Real capital expenditure only arises with your own hardware.
One assumption from the first version of this post no longer survives the numbers: that your own model pays for itself from a five- to six-figure number of daily calls. API prices have fallen too far for that. A worked example with 100,000 requests a day of 2,000 tokens each, about 6 billion tokens a month:
Small model, 6B tokens a month
Even at high volume, the API is about three times cheaper in this example, and that is without the staff and operating costs of your own model. To avoid any misunderstanding: this is not an argument against open models. It only shifts the reasoning. If you choose open weights today, you do it for control, data sovereignty and customisation, rarely for price. Frontier APIs are the honest right choice if you want to start fast or have no operations team.
The mature answer: a router, not a camp
The answer is rarely “either or”. Usually it is a switch. The mass of simple, data-sensitive, high-volume tasks runs on a small or open model, in-house if the data demands it, otherwise through an inexpensive API. The rare top-tier request that demonstrably needs more capability goes to a frontier model. That way you pay frontier prices only where they earn the premium, instead of across the board for every triviality. How much this mix saves is shown in our price comparison of frontier providers.
Your decision framework
To take away, no frills:
- Frontier API, if you want to start fast, have no operations team, volumes are manageable and real peak performance occasionally matters. The capability is there at once, without infrastructure.
- Open weights, if data sovereignty is critical, customisation is needed or you want to keep control and portability in the long run.
- Router or hybrid, as soon as you have both: lots of routine and rare hard cases. For most established companies, that is the normal case.
Two things belong in both worlds, whichever you choose. First, tests and monitoring are mandatory. The closed model can change underneath you; the open one you run yourself. Without measurement you will not notice a regression in time in either case. Second, if you let a model operate tools, you have to secure it. Control over acting agents is not an add-on but part of the architecture.
The point
Nobody runs their entire logistics with a racing car. You have a fleet: vans for the volume, the racing car for the one route where it counts. The question was never “open or closed”. It is: which horse do I harness for which route?
The one thing you should not outsource is exactly this decision, the clarity about what you are actually optimising for. The model is replaceable. The reason you choose it is not. If you would like to sort these axes for your company, we are happy to talk.
