Open-weight and closed models represent two visions for AI. Here's what the terms really mean, the trade-offs in cost, control and safety, and how to choose.
One of the defining splits in AI is between open and closed models. It shapes who can build with the technology, where the value accrues, and how safety is handled. But the labels are muddier than they sound, and “open” rarely means what people assume. This guide clarifies the terms and the trade-offs.
A closed model is accessed through an API. You send a prompt, you get a response, and you never see the model’s internals. OpenAI’s GPT and Anthropic’s Claude are the familiar examples — the weights stay on the provider’s servers.
An open-weight model is one whose trained parameters you can download and run yourself. Meta’s Llama and several others fall here. You can host it, fine-tune it, and inspect its behaviour offline.
“Open weights” is not the same as “open source.” Truly open source would include the training data, the training code and a permissive licence. Most “open” models release only the weights, often under licences with restrictions. Read the licence before assuming you can do anything you like.
The cost is dependence: you inherit the provider’s pricing, rules and availability, and your data flows through their systems.
The cost is responsibility: infrastructure, scaling and safety all become your problem.
This is where the argument gets heated.
Open models can’t be recalled. Once weights are public, they’re public forever.
Proponents argue openness improves safety: thousands of researchers can find flaws, and no single company controls a critical technology. Critics argue that releasing capable weights hands the same power to bad actors, with no off switch. Both points are partly right, which is why regulators haven’t settled it — and why it surfaces in nearly every AI-policy discussion.
The decision usually comes down to a few practical factors.
| Factor | Lean closed | Lean open |
|---|---|---|
| Need top capability | Yes | Sometimes |
| Sensitive data must stay in-house | No | Yes |
| Very high, steady volume | Maybe | Often cheaper |
| Small team, little infra | Yes | Harder |
| Want deep customisation | Limited | Yes |
Many teams don’t pick a side. They prototype on a closed API for speed, then move high-volume or sensitive workloads to an open model they host. Others use a closed model for hard tasks and a cheaper open one for routine ones. The frontier moves fast, and today’s gap between the best closed and best open models has been narrowing.
The takeaway: “open vs closed” is a spectrum and a set of trade-offs, not a moral choice. Match the model to the job — capability, privacy, cost and control — and revisit the decision as both sides keep improving.