Open vs. closed

“Open-source AI” gets headlines, government inquiries, and a lot of strong opinions. The label covers several different things in practice. Sorting them out is the useful work; once that’s done, the actual trade-off between open and closed becomes a lot less mythical.

What “open” actually means here

In AI, “open” is a spectrum, not a binary.

Fully open. Model weights are public, training data is described or released, training code is public. Anyone can download, run, modify, and in principle reproduce the model from scratch. Very few major models clear this bar.

Open weights. The trained model file is downloadable. It can be run on company-controlled hardware, fine-tuned, embedded inside a product, redistributed (within the licence terms). Reproducing it from scratch is usually not possible — the training data and most of the training code stay private. Meta’s Llama, Mistral’s open releases, DeepSeek, and Alibaba’s Qwen mostly live here.

Closed. The model is hosted by the lab. Access is through an API or a product. The weights never leave the lab’s infrastructure. OpenAI’s GPT, Anthropic’s Claude, Google’s Gemini all sit here.

When the discourse says “open-source AI is closing the gap on closed models,” it almost always means open-weights — not fully open in the classical software sense. That’s a meaningful difference. An open-weights model is runnable, but generally not auditable in how it was trained, and not recreatable from scratch.

What closed models trade in

Pay per use, per token. The lab runs the infrastructure, scales it, updates it, deprecates older versions on their schedule. The customer gets the latest model — sometimes whether they wanted to update or not (model drift becomes its own management problem; more on that in Where your data goes). The frontier of capability — hard reasoning, long context, the smartest multimodal — sits at this layer.

The data path is the other side of the same coin. Inputs flow through the lab’s servers. Enterprise plans typically include commitments that data won’t be used for training and won’t be retained beyond short operational windows, but the exact terms vary lab to lab and tier to tier and are worth reading rather than assuming. The lab is in the loop, technically and contractually.

What open-weights models trade in

The model runs on infrastructure the company controls — own hardware, own cloud account, on-prem. Data never has to leave that perimeter. The model can be fine-tuned on proprietary data, modified, stripped of features, or wrapped in custom safety layers. There is no vendor in the data path, no API price hike to react to, no policy change to absorb mid-deployment.

The trade is operational. GPUs are expensive and have to be procured, run, and kept warm. Latency, uptime, and version management become problems the business owns rather than the lab. Updates only happen when somebody downloads and deploys the new version. And on raw capability, open-weights models still trail the closed frontier — by roughly six to eighteen months on the hardest tasks, less on routine ones. That gap is closing meaningfully each release cycle, but it is still real today.

Where the two genuinely differ

A few axes where the difference is real, not rhetorical:

• Capability ceiling. Closed leads at the hardest end — multi-step reasoning, very long context, frontier multimodal. The difference is smaller than it used to be and shrinking.
• Data path. Closed routes through the lab. Open-weights stays inside the company’s perimeter. For regulated data, IP-sensitive content, or anything covered by data-residency rules, this isn’t a preference, it’s a constraint.
• Unit economics at volume. Closed is pay-per-token; the bill scales linearly with usage. Open-weights front-loads infrastructure cost and then runs cheap per call. At low volume, closed is cheaper. At very high volume — millions of calls a day on simple tasks — open-weights wins by a wide margin.
• Modifiability. Closed offers prompts, system instructions, sometimes light fine-tuning. Open-weights allows deep fine-tuning, distillation, architectural surgery — a different category of customisation.
• Lock-in shape. Closed binds the operation to a vendor relationship. Open-weights binds it to its own infrastructure. Both are lock-in; they just go in different directions.
• Update cadence. Closed updates on the lab’s clock. Open-weights updates on the team’s — which is sometimes a feature (stability) and sometimes a bug (the deployment falls behind unless someone actively keeps it current).

The mixed picture in practice

Most operations that use both end up with a mix. Closed at the frontier for the work that genuinely benefits from the best model — research, complex drafting, hard reasoning, exploratory product work. Open-weights for the workloads where running it yourself pays off — high-volume classification or extraction, anything inside a regulated data perimeter, internal tools where the data path matters more than the last few percentage points of capability. A team that has tried both tends to develop intuition for which side a given workload belongs on.

The honest position on the gap: at the frontier, closed is still ahead, and for the hardest tasks that lead is meaningful. For everyday business work — drafting, summarising, extraction, classification, structured output — the better open-weights models are at the point where the distinction is more about data path and economics than capability.