fabricioIA

Tools Jun 25, 2026

Open source AI or proprietary AI: which one to choose?

The capability gap shrank to the point where the choice became, for most cases, a decision about control and cost — not about quality.

FabricioIA poster for the article "Open source AI or proprietary AI" — two doors side by side: the proprietary one where the data leaves and the answer comes back, and the open one where everything stays inside the house
FabricioIA poster for the article "Open source AI or proprietary AI" — two doors side by side: the proprietary one where the data leaves and the answer comes back, and the open one where everything stays inside the house

First, the term is wrong

Almost no "open source" model is open source in the classic sense. What gets published are the weights — the result of the training — under licences that range from quite permissive to fairly restrictive. The training data and the process rarely come along.

The more honest term is open weights model. That is not pedantry: it changes what you can do. You can download, run, tune and inspect the behaviour. You cannot reproduce the training or audit what went into it.

What changed in the last two years

The capability gap shrank considerably. Open models started to deliver, in reasoning and code, performance that had been at the absolute top a short time earlier — at a drastically lower cost.

The frontier still belongs to the closed ones: the most capable models on hard tasks, the most complete product ecosystem, the most mature multimodal work. But the relevant question stopped being "can the open one handle it?" and became "does my case need the frontier?".

For most company tasks — classifying, extracting, summarising, answering from a document, applying a rule — it does not.

Where open wins

Data that cannot leave. Health, legal, financial, defence, trade secrets. Running on your own infrastructure, the question "where did that data go?" has a simple answer. No contract clause matches it.

Cost at high volume. Above a certain level of use, paying per token gets more expensive than maintaining your own infrastructure. Exactly where that point sits depends on your volume — but it exists, and on repetitive workloads it arrives sooner than people expect.

Predictability. The model you downloaded today behaves the same a year from now. A third-party model is updated, tuned and sometimes discontinued — and your carefully calibrated prompt starts producing something else without warning.

Real fine-tuning. Specialising in a domain, a jargon, a format. A small, well-tuned model beats a big generic one at the specific task, at a fraction of the cost and latency.

Working without internet. Factory floor, embedded, field work, isolated environments.

Where closed wins

Maximum capability. When the task is genuinely hard and an error is expensive, frontier models still deliver more.

Total cost of ownership. The open model is free; the operation is not. GPUs, monitoring, updates, someone to look after it. For low and medium volume, the API is cheaper once you count the salary of whoever maintains it.

Time to start. From idea to running: hours against weeks.

Ecosystem. Integrated tooling, multimodal, image and voice generation, applications, ready-made integrations. It is a product, not just a model.

Somebody to hold accountable. A contract, a service level agreement, a data handling clause. In a regulated sector, that is worth more than it looks.

The choice, in four questions

1. Can the data leave your infrastructure? If it cannot, the path is decided: open and local.

2. Do you have someone to operate it? Without a person who understands GPUs, inference and monitoring, the open model becomes a stalled project. No one? Start closed.

3. What is the volume? Low or irregular → closed API, no doubt about it. High and steady → run the numbers against the cost of infrastructure plus person.

4. Does the task demand the frontier? Test with a small open model before assuming you need the best in the world. You will be surprised how often you do not.

The mature answer is almost always "both". Closed where capability decides; open where volume, secrecy or predictability decide.

The mistake of treating this as ideology

There is an organised cheering section on both sides, and it gets in the way of the decision.

Whoever defends open on principle sometimes spends months of engineering to save the equivalent of two subscriptions. Whoever defends closed out of convenience sometimes builds the entire product tied to one vendor and discovers the price of that when the usage policy changes.

The practical path: design the swap in from the start. Call the model behind a layer of your own, keep prompts versioned outside the application code, have an evaluation set that runs against any model. That costs little at the beginning and turns the choice into configuration — which is the only sensible stance in a market that changes leader every six months.

Get the next articles

No spam. One message when a new article is out, with an unsubscribe link in every one.

Keep reading