Open Models

“Open” is used loosely in AI, and the distinctions have real legal and practical weight. Start with precise terms.

”Open weights” vs. “open source”

Open weights — the trained model parameters are downloadable. You can run, fine-tune, and host the model. This is what most “open” models actually are.
Open source (in the fullest sense) — weights plus training code, plus the training data, all under a license permitting reuse. Genuinely full openness is rarer; training data especially is often undisclosed.

For day-to-day engineering, open weights is what matters: you have the model and can deploy it. Just don’t assume “open” means you can see how it was built.

Closed (proprietary) models

The other end: accessed only through an API. You don’t get the weights, can’t self-host, and can’t inspect the internals. You’re buying a capability and a service. Frontier closed models often lead on raw capability — but you trade away control.

Licenses matter — read them

An open-weights model still ships with a license, and licenses are not uniform. Always check before building on a model:

Permissive (e.g. Apache 2.0, MIT) — broad commercial use, few strings.
Custom community licenses — some popular models add their own terms: use-case restrictions, scale thresholds, or naming/attribution rules.
Non-commercial / research-only — fine for prototypes, not for a product.

The model families

The specific leaders shift constantly, so think in families rather than version numbers. Across the open-weights landscape you’ll find families from several major labs and communities, and they typically span:

Sizes — from a few billion parameters (laptop-friendly) up to very large models needing serious GPUs. Many families ship multiple sizes from one recipe.
Variants — a base model (raw, for fine-tuning) and an instruct/chat model (post-trained to follow instructions). Use the instruct variant unless you’re fine-tuning.
Specializations — general chat, code-focused, reasoning-focused, embedding models, vision-capable, and more.

Pick by task fit and size, verified on your evaluation set — not by leaderboard rank. The best general model is often not the best model for your specific job.

Open vs. closed: the trade-off

Factor	Open-weights model	Closed API model
Peak capability	Strong; trails the very frontier	Often leads
Data control	Runs in your environment	Data leaves to the provider
Cost shape	GPU/hosting cost; cheap at high steady volume	Per-token; cheap at low volume
Customization	Full — fine-tune, modify, quantize	Limited to what the API offers
Operational burden	Yours — you host and scale it	Provider’s
Offline / air-gapped use	Possible	Impossible
Version stability	You pin a checkpoint; it never changes under you	Provider can deprecate or change it
Setup time	Slower — infrastructure required	Minutes

When to choose open

Lean open when you have hard data-residency or compliance needs, want full control and customization, run high steady volume where self-hosting math wins, need offline operation, or require a model that won’t change underneath you.

Lean closed when you want the highest capability with zero ops, your volume is low or spiky, or you need to move fast.

Many production systems use both — closed APIs for frontier reasoning and burst traffic, open models self-hosted for steady, sensitive, or high-volume paths. It’s not an all-or-nothing choice.

Key takeaways

“Open weights” (downloadable parameters — the common case) is distinct from full “open source” (weights, code, and data). Closed models trade control for peak capability and zero ops. Always treat the license as a real dependency and confirm it permits your commercial use. Think in model families and pick by task fit and size, verified on your own evals. Open wins for control, compliance, customization, and steady scale; closed wins for frontier capability and speed — and using both is common.