Open weights means the large pile of parameter files produced by training is published, and anyone can download it, run it on their own hardware, fine-tune it, and redistribute it. Llama, Qwen, DeepSeek, Mistral, and Gemma — models you can pull straight off Hugging Face — all fall into this category.
The opposite is closed weights, or proprietary models: the weights aren't published and you reach the model only through the vendor's API. GPT, Claude, and Gemini belong here.
One thing to settle up front: in casual usage people call open-weight models "open source models," but strictly the two terms are not equivalent. More on that below.
Grab It in One Sentence First
Open weights hands you the finished model, not the recipe for making it.
Think of cooking. Traditional open source software is a full recipe: ingredient list, timings, temperatures — anyone can reproduce and improve it. Open weights is more like being handed the finished dish. You can eat it, plate it differently, add your own seasoning and serve it on — but nobody told you where the ingredients came from or how it was seasoned.
The Difference Between "Open Weights" and "Open Source"
A genuinely open source AI model, under the Open Source Initiative's 2024 Open Source AI Definition, must provide enough information for someone to rebuild the system from scratch: the training data (or a sufficient description of it), complete training and inference code, and the weights — under a license that restricts neither field of use nor who may use it.
Measured against that bar, the vast majority of "open source models" satisfy only the last item:
| Element | Typical open-weight model | Full open source AI |
|---|---|---|
| Weight files | ✅ Published | ✅ Published |
| Inference code | ✅ Usually published | ✅ Published |
| Training code | ⚠️ Often incomplete | ✅ Published |
| Training data | ❌ Rarely published | ✅ Published or fully described |
| License restrictions | ⚠️ May limit commercial or specific uses | ❌ May not restrict |
This isn't wordplay. The difference shows up in real decisions: you can't audit whether the training data contains material you must not touch, you can't reproduce the training run, and you can't be sure a license clause — say, one requiring separate terms above a monthly-active-user threshold — won't become a problem as your business grows.
What It Buys You
Deployment freedom. With the weights in hand you can put the model on an internal network, on a local device, or in an edge setting, and the data never leaves your premises. For healthcare, legal, and government work, this is often not a cost question but a feasibility one.
A different cost structure. An API is variable cost billed per token; self-hosting is fixed cost for compute. APIs win at low volume, and self-hosting only becomes cheaper past a certain scale — but operations, GPU utilization, and peak-capacity headroom all belong in that calculation, and are routinely underestimated.
Modifiability. LoRA fine-tuning, quantization, distillation, swapping inference frameworks, even architectural surgery all require the weights. The open-weight ecosystem has such a rich toolchain precisely because people can get their hands on the model.
No single-vendor lock-in. When a model is deprecated, repriced, or restricted by policy, local weights are your fallback.
What It Costs
Total cost of ownership gets underestimated. Buying or renting GPUs, operating an inference service, keeping up with model updates, and hardening it all require people. Many teams do the arithmetic and find the API is cheaper unless volume is genuinely high or compliance forces the issue.
Security responsibility shifts to you. Closed vendors do a great deal of filtering and abuse prevention server-side. Self-hosting means all of that is yours to build: guardrails, content filtering, and prompt injection defenses.
A capability gap remains. Open-weight models have closed distance fast and are more than adequate for many tasks, but on frontier complex reasoning and long-horizon agent work they typically still trail the closed flagships. That gap moves over time, so base your choice on your own evals rather than a leaderboard from a few months ago.
Where People Get It Wrong
"Open weights means free." The download is free; the compute isn't. Actual running cost can exceed API pricing, especially at low utilization.
"Open source models can be used commercially however I like." Check each license individually. Some are standard Apache 2.0 or MIT and safe to build on; others are vendor-specific licenses with user-scale thresholds, prohibited-use clauses, or attribution requirements. This belongs on the pre-launch checklist.
"Published weights mean auditable models." What you can audit is behavior, not provenance. You can test outputs, but you can't infer training data from weights, so data-compliance risk doesn't disappear because the weights are open.
How to Choose
Ask three questions: can the data leave (if not, self-hosting is nearly the only option); how large is the call volume (which way the cost balance tips); and how hard is the task (frontier problems may only be handled reliably by a closed flagship).
Hybrid setups are increasingly common: the main path runs on a closed flagship for quality, while high-frequency fixed subtasks run on self-hosted open-weight small models, all scheduled behind an AI gateway with model routing. That captures the cost and data-control benefits without giving up the capability ceiling.