Open-Weight vs Closed AI Models: Plain-English Guide

For most small and mid-sized businesses a closed model over an API is the right starting point, but if your data must stay in-house or your volume is high and steady, an open-weight model can be the better fit.

If you run a business in Greater Manchester and you are weighing up which kind of AI to build on, this post is for you. By the end you will be able to tell open-weight and closed models apart, see them side by side, and decide which suits your constraints. It is part of the story of AI since ChatGPT.

We are a Manchester technology business that builds AI systems for clients, and we give independent, no-commission advice on this exact choice. The chatbot on this site runs on a closed model over an API, because that is the right fit for our own use.

Quick verdict: who should pick open, who should pick closed?

Pick a closed model if you want the best capability with no infrastructure to manage and pay-as-you-go costs; pick an open-weight model if data residency, high steady volume, deep customisation or offline operation are non-negotiable.

The plainer version

Most businesses, most of the time, should start with a closed model over an API. It is the lower-effort, faster route to a working system. Reach for open weights when a specific constraint, usually where your data is allowed to go, forces your hand.

It is not a tribal choice

A great deal of online debate treats “open” and “closed” as causes to defend. A business only cares whether the system does the job, keeps data where it is allowed, and costs what it should. This is a fit-to-constraint decision, and the right pick depends on your situation rather than your politics.

How do open-weight and closed models compare side by side?

The table below sets out the trade-off across the factors that actually move a decision.

What is the difference, in the terminology that matters?

A closed model lives on its maker’s servers; an open-weight model can be downloaded and run wherever you choose.

Closed models

A closed model (GPT-5, Claude, Gemini) lives on its maker’s infrastructure. You send your data to their API, pay per use, and get the best available capability with nothing to manage. You can see the major providers at openai.com and anthropic.com.

Open-weight models

An open-weight model (Meta’s Llama, Mistral’s models, Google’s Gemma, DeepSeek’s R1) can be downloaded and run on your own server, in a UK data centre, or even on a strong desktop for smaller models.

Why the exact word matters

Note the precise term: open weight, not open source. The downloadable file is the trained model itself. The training data and full recipe usually stay private, and licences vary considerably, so read the licence before you build a product on one. The wording matters when you make deployment decisions, and it matters more when a customer asks what you are running.

How did open-weight models get good enough to matter?

Open-weight models went from “noticeably worse” in mid-2023 to genuine contenders by 2025, driven by three releases.

Llama made open credible

Meta’s Llama 2, in July 2023, was the first heavyweight open-weight family cleared for commercial use, and later versions closed most of the quality gap. By 2025 the family had passed a billion downloads.

Mistral made open efficient

The French startup’s 7-billion-parameter model, in September 2023, outperformed models twice its size, and its Mixtral release in December 2023 brought sparse mixture-of-experts architecture (big-model quality at small-model running cost) into the open world.

DeepSeek made open frightening

In January 2025, DeepSeek-R1 delivered frontier-grade reasoning fully open, at a fraction of the expected training cost. It is the moment the industry stopped treating open weights as the second division. For why running these models got so cheap, see why AI got cheap.

By 2026, European players had taken it further, selling sovereign, self-hostable systems an organisation can run entirely inside its own walls.

What is the real business trade-off?

The real trade-off is capability and convenience versus control and data residency.

What closed models win on

Raw capability at the frontier, zero infrastructure burden, fastest access to new features, and pay-as-you-go economics that suit spiky or modest usage. For most SMEs, most of the time, a closed model over an API is the right answer. It is what we use for our own client chatbots.

What open-weight models win on

Data residency (nothing leaves your infrastructure, which is decisive in healthcare, legal and finance), predictable costs at high volume, deep customisation through fine-tuning, no vendor dependency, and offline or air-gapped operation.

Where data residency gets serious

If you handle personal data, where it goes is a legal question. The ICO’s guidance on artificial intelligence sets out what you must be able to answer, and the government’s data protection overview covers the underlying duties. Since obligations on general-purpose models began applying in 2025, those questions have only sharpened. Our Microsoft 365 and IT support service helps clients map this out without selling them a particular model.

The cost shape, not the cost

Headline prices mislead. A closed API charges per request, so a quiet month costs almost nothing and a busy month costs more. A self-hosted open model flips that: the server bill is fixed whether it runs flat out or sits idle. At low or unpredictable volume the API usually wins. At high, steady volume the dedicated server usually does, once you have added in the cost of the people who keep it running.

The cost businesses forget

That maintenance cost is the part businesses underestimate. A closed API needs nobody on your side; the provider patches, scales and secures it. A self-hosted model needs someone responsible for updates, security and uptime, and a self-hosted deployment is a snapshot in time. Closed frontiers improve almost monthly, so if you run your own model you have to decide, deliberately, when to upgrade. The NCSC’s guidance on AI and cyber security is worth reading before you take that responsibility on.

What should you ask before committing to either?

Whichever way you lean, these are the questions that decide whether the choice survives contact with reality.

1. Where is our data processed, and is it used for training? Get this in writing, not from a marketing page.
2. What happens if this provider disappears or triples its price? Portability is a real cost, so price it now.
3. Who patches it? If the answer is “us”, make sure that person exists and has time.
4. What does a busy month cost? Model your actual peak, not your average.
5. What must never leave the building? Decide this first. It usually settles the whole question.

The question that settles most decisions

Number five. In our experience the data-residency answer decides the architecture more often than capability or cost do, and businesses that start there waste far less time. If your answer is “nothing sensitive”, you are almost certainly a closed-API business and can stop reading here.

The mistake we see most often is answering it aspirationally. A business decides that everything is sensitive because that feels like the safe answer, commits to self-hosting, and then discovers it has bought a server, a maintenance burden and a weaker model in order to protect data that was never restricted in the first place. Be specific about which records genuinely cannot leave, and be equally specific about which ones can. That single distinction is usually worth more than any benchmark comparison.

When should you pick neither, and run a hybrid instead?

In practice the winning answer is often a hybrid: use both, matching each model to the task.

What a hybrid looks like

Sensitive document processing runs on an open model in-house. Customer-facing chat runs on a frontier closed model. Routine high-volume classification runs on a small, cheap model. Each job goes to the model that fits its constraints, rather than forcing one model to do everything. The same logic drives the automation work we build for clients.

Why it works

It handles the where-your-data-goes question cleanly, because the data that must stay in-house never leaves, while the work that benefits from frontier capability still gets it. It also softens the vendor-dependency worry, since no single provider holds your whole operation.

The catch

A hybrid means more moving parts to run, more places something can break, and a clear rule for which data is allowed to go where. That is worth it for a business with genuinely mixed needs, and overkill for one with a single, simple use case. For more on the rules shaping these choices, see our plain-English AI regulation timeline, and for the wider capability picture, our guide to AI agents.

There is rarely a universally right answer. But there is usually a clearly right answer for a specific business with specific constraints. Working that out is what our AI Opportunity Assessment does, and you are welcome to ask us directly. We will tell you straight if the boring option is the right one.