Open vs Closed AI Models: What's the Difference?

The first time I tried to run an AI model on my own laptop, I expected something dramatic. A download bar, sure, but then maybe a setup wizard, a license key, a phone-home check. Instead I got a single large file sitting in a folder, and a small program that read it. No internet required. No company watching. Just numbers on my disk, doing their thing. It felt strangely intimate after years of typing into a website and waiting for a server somewhere to answer.

That moment is the whole story of "open versus closed" AI models in miniature. On one side, you have models you rent through a website or an interface you don't control. On the other, you have models you can hold in your hand, more or less, as a file. Both are useful. Neither is morally superior. But the difference shapes your cost, your privacy, your control, and what you're allowed to do, so it's worth understanding clearly and without the usual ideological heat.

What a "closed" model actually is

A closed, or proprietary, model is one you access without ever touching the model itself. Think of GPT from OpenAI, Gemini from Google, or Claude from Anthropic. You type into an app or send a request to an API, your words travel to the company's servers, the model runs there, and the answer comes back. You never see the model's actual weights, the enormous grid of numbers that is the trained model. (If the word "weights" is fuzzy, my piece on how large language models actually work walks through what they are.)

The mental model I find useful is renting. You don't own the car; you call it when you need it, you pay per trip, and someone else handles the maintenance, the fuel, and the upgrades. When the company improves the model overnight, your next ride is quietly better and you did nothing. That convenience is real, and it's the main reason closed models dominate everyday use.

What an "open" model actually is

An open-weight model is one whose weights you can download. Llama from Meta, Mistral's models, and a growing list of others fall here. Once you have the file, you can run it on your own machine or your own server, feed it private data without that data leaving your building, fine-tune it on your specific domain, and keep using the exact version you downloaded for as long as you like, even if the original maker disappears tomorrow.

Back to the analogy: this is buying the car. There's an upfront cost in hardware and know-how, you handle the maintenance, but it sits in your garage, it goes where you tell it, and nobody can repossess it or change how it drives without your say-so.

"Open" is a spectrum, not a switch

Here's the part the marketing tends to blur. When people say a model is "open," they almost always mean open weights: you can download and run the finished model. That is genuinely useful, but it is not the same as the model being fully open in the way open-source software usually is.

Truly open would also mean the training data is published, the training code and recipe are shared, and the license lets you do essentially anything. Most "open" models give you the weights but keep the training data and full recipe private, and some attach licenses with real restrictions, for example limits on commercial use at very large scale. So it helps to picture a slider rather than two boxes:

• Fully closed: you only get to use it through someone else's interface.
• Open weights, restricted license: you can download and run it, within stated limits.
• Open weights, permissive license: download, run, modify, and ship commercially with few strings.
• Fully open: weights, data, code, and recipe all public, so you could in principle rebuild it from scratch.

When someone tells you a model is "open," the honest follow-up question is always: open in which sense, and under what license? The answer changes what you're actually allowed to do.

The real tradeoffs

Once you strip away the ideology, the decision comes down to a handful of practical tensions. Closed models tend to win on convenience, raw capability, and support. Open models tend to win on control, privacy, cost at scale, and customization. Let me make each of those concrete.

Convenience and capability (closed). The most capable, most polished models at any given moment are usually closed, and they take seconds to start using: sign up, get a key, send a request. There's no hardware to buy, no model to host, no infrastructure to babysit. If something breaks, there's a company with documentation and a support channel. For a small team that wants results this week, that's enormous.

Control and privacy (open). With a closed model, your prompts leave your premises and land on someone else's servers, governed by their policies, which can change. With an open model running on hardware you control, sensitive data, patient records, legal documents, customer details, never has to leave the building. For regulated industries or anyone handling confidential information, that alone can be the deciding factor.

Cost (it depends). Closed models charge per use. For light or unpredictable usage, that's cheap and you pay only for what you touch. But if you're processing millions of requests a day, those per-use fees add up fast, and a self-hosted open model on your own hardware can become dramatically cheaper at volume. The crossover point depends entirely on your scale, so the honest answer is "do the arithmetic for your situation."

Customization (open). You can prompt a closed model cleverly, but you can't reach inside it. With open weights you can fine-tune the model on your own data so it speaks your industry's language, follows your formats, or knows your domain deeply. (Fine-tuning isn't the only way to give a model your knowledge, though. For many cases, retrieval-augmented generation is simpler and works with closed models too.)

When each one makes sense

Rather than declare a winner, let me walk through who tends to land where, because the right answer really does depend on who's asking.

A solo hobbyist or learner. If you're tinkering, learning how these systems behave, or want to run things offline for the sheer joy of it, open weights are a gift. You can poke at the model, run it without a bill ticking, and understand it from the inside. The capability ceiling is lower than the best closed models, but for learning that hardly matters.

A small startup shipping fast. Early on, a closed API is usually the pragmatic call. You get top-tier capability instantly, you don't sink money into hardware or hiring infrastructure people, and you can validate your idea before committing. Many startups begin closed and migrate specific workloads to open models later, once volume and privacy needs justify it.

A privacy-sensitive organization. A hospital, a law firm, a bank, a government office: anyone who legally cannot let data leave their control. For them, an open model running on owned infrastructure isn't a preference, it's often a requirement. The extra engineering cost is simply the price of compliance.

A large enterprise. Bigger organizations frequently run both. Closed models for general productivity where capability matters most, and open models for high-volume, sensitive, or customized workloads where control and cost dominate. It's a portfolio, not a religion.

Why this matters for Africa

This isn't an abstract debate where I live and work. Three things make the open-versus-closed question especially pointed across much of Africa.

Data sovereignty. When your data must travel to servers on another continent to be useful, you've handed control of it to jurisdictions and companies far outside your own. Open models that run locally let organizations, and eventually nations, keep their data and their decisions at home. That's not nationalism; it's basic prudence about who holds your information.

Cost. Per-use API fees are priced in strong foreign currencies and add up quickly against local budgets. For a business in Dar es Salaam or Lagos, a self-hosted open model, once the upfront hardware is sorted, can turn an unpredictable recurring expense into a fixed, ownable asset. At scale, that math matters enormously.

Offline and unreliable connectivity. Closed models need a steady internet connection to the provider's servers. In places where connectivity is intermittent or expensive, a model that runs locally on a machine, no round trip required, isn't a luxury. It's the difference between a tool that works and one that doesn't.

None of this makes closed models the enemy. They're often the fastest, most capable choice, and pretending otherwise would be its own kind of hype. But the existence of capable open models gives builders here real options, and options are exactly what a developing tech ecosystem needs most.

Frequently asked questions

Are open models worse than closed ones?

Not categorically. At the very top of capability, the best closed models usually lead. But strong open models are good enough for a huge range of real tasks, and the gap narrows constantly. The right question is not which is better in the abstract, but which is good enough for your specific job at a cost and with a level of control you can live with.

Is an open-weight model the same as open source?

Often no. Open weights mean you can download and run the model. True open source would also include the training data, training code, and a permissive license. Many popular open models share only the weights and keep the data and full recipe private, sometimes with license restrictions. Always check what 'open' means for the specific model.

Do I need a powerful computer to run an open model?

It depends on the model's size. Smaller open models run comfortably on a decent laptop or a modest server. The largest ones need serious hardware, often specialized graphics cards. A practical path is to start with a smaller model that fits your hardware and scale up only if you genuinely need more capability.

Is my data safer with an open model?

It can be, because a self-hosted open model means your prompts never leave your own infrastructure. With a closed model, your data travels to the provider's servers under their policies. That said, safety also depends on how well you secure your own systems. Self-hosting moves the responsibility to you; it doesn't remove it.

Can I switch from a closed model to an open one later?

Usually yes, and many teams do. A common pattern is to start with a closed API to move fast, then migrate specific high-volume or privacy-sensitive workloads to a self-hosted open model once the need is clear. Writing your code so the model is easy to swap out makes this much smoother.

The honest bottom line

I keep both kinds within reach. When I want the strongest possible answer with zero setup, I reach for a closed model. When I'm handling something private, working offline, or doing the same task at high volume, I reach for an open one. The choice isn't about loyalty to a camp. It's about matching the tool to the job, the budget, the data, and the constraints in front of you.

What's genuinely good about this moment is that the choice exists at all. A few years ago, capable AI meant renting from a handful of large companies, full stop. Today you can download a serious model and run it on your own terms. That doesn't make closed models obsolete, and it doesn't make open models a cure-all. It just means you have real options, and understanding the difference is how you pick well.

Further reading on this site

• How Large Language Models Actually Work
• What Is RAG (Retrieval-Augmented Generation)?
• Browse Technology

If explainers like this one are useful to you, subscribe to the newsletter and I'll send the next one straight to your inbox.