Open vs Closed

"Open source" stopped meaning just Llama long ago. Four forces worth knowing by name.

Five situations where open weights are the correct answer, not a compromise. Data sovereignty: medical records, bank secrecy, classified material — anything legally barred from leaving your perimeter is served only by your own hardware; no zero-retention clause equals the physical absence of transmission. Predictability: an open model will not change under you — closed APIs get silently updated, and prompts that worked yesterday start behaving differently. Continuity: summer 2026 added an argument no textbook had — an open model cannot be put on a government pause and your access to it cannot be restricted (details in our regulation analysis). Customization: fine-tuning for a narrow domain on your own data requires the weights in hand. And mass volume: on millions of cheap uniform requests, price per token beats quality — open models via inference providers offer the market's best economics there.

The honest list in the other direction. The quality ceiling: on the hardest work — long autonomous projects, fine reasoning — Fable 5, Opus 5 and GPT-5.6 remain ahead, and months of gap matter when mistakes are expensive. Zero engineering: an API is zero DevOps; your own inference is vLLM, quantization, monitoring, on-call and at least one engineer who enjoys all of it. Speed to start: an API pilot launches in a day; a private perimeter takes weeks. And the features around the core: prompt caching discounted up to 90%, built-in tools, batch modes — closed platforms' scaffolding is more mature, and you would be rebuilding it yourself.

A word about the illusion of free. In one engineering team's public measurement, an open 70B model on two rented H100s via vLLM delivered p95 latency of 1,200 ms at $3.80/hour — against 480 ms and roughly half the effective cost for a mid-tier closed model on the same workload. The author's conclusion was honest: open source won on data sovereignty, not on price or speed. Our case files agree: below a few million tokens a day, the API is almost always cheaper — your own hardware pays off on large stable volumes or where the law leaves no choice.

Myth one: open means free. Weights are free; ownership is not — GPUs, vLLM engineering, quantization, monitoring, on-call and quarterly model refreshes put the full cost of a mid-size team's own perimeter at thousands of dollars a month, versus hundreds on APIs at the same volume. Pick open for control; picking it for savings usually means the math was wrong. Myth two: open means insecure. For the top corporate risk — data leakage — it is the opposite: a request inside your perimeter physically goes nowhere, which beats any cloud contract. The real weakness lies elsewhere: open weights carry no vendor guardrails, so filters, audit and abuse-handling are entirely on you. Open-source security is a job, not a property. Myth three: closed is always smarter. True only at the top slice of difficulty: on routine summarization, classification, extraction and boilerplate code your users will not tell GLM-5.2 from a flagship, and a domain-tuned open model regularly beats a generalist one on its home turf. Closed wins on the ceiling; open wins on fit — and the measurement, not the brand, decides. The inference-provider layer makes the first step easy: open-model economics as an API, no hardware, migration to your own metal later if the lawyers insist.

In mature teams the open-vs-closed argument ended with "both." The typical architecture from our case files: a closed flagship on the 5–10% of hard requests where the quality ceiling matters; an open model on volume and on everything containing sensitive data; a task-type router between them with a simple escalation rule. One scheme solves three problems at once: the bill (the expensive model fires rarely), compliance (personal data stays inside), and resilience (any single vendor's pause or change does not stop the product).

The one-day decision checklist — four questions. Is there data legally barred from leaving the perimeter? (Yes → an open component is mandatory.) Are there tasks where an error costs more than $50 per million tokens? (Yes → a closed flagship on escalation.) Do you have an inference engineer? (No → run the open component via a provider, not your own metal.) Does stable volume exceed a few million tokens a day? (No → start entirely on APIs.) Four answers give you your configuration — then a week of testing on real tasks, per the method from our rankings.

Sources: open-model surveys and GLM-5.2/Fable 5 comparisons (summer 2026), DeepSeek's transparency center (V4, Apr 24, 2026), Meta's Llama 4 documentation (Scout 10M, Maverick), a public vLLM/H100 engineering measurement, our case files. Recommendations are the editors' own.