Every model you've encountered so far in this track can be split into one of two categories, and that split matters a lot more than it looks like from the outside. It's not about which model writes better prose or scores higher on a benchmark. It's about who controls the actual weights, the trained parameters that make the model work, and what that control lets you do.
The distinction
Open-weight models are ones where the trained model file itself is published and downloadable. Models like Qwen, DeepSeek, and Llama fall into this category. You can pull the weights, run them on your own hardware or cloud infrastructure, inspect how they behave, and fine-tune them on your own data. "Open" here refers specifically to the weights being available, not necessarily to the training data or code behind them, and not necessarily to a permissive license. Licensing terms vary a lot across open-weight models: some genuinely use permissive licenses like MIT or Apache, while others ship with usage restrictions (limits on commercial use at certain scale, or restrictions on using outputs to train competing models). Read the actual license before you assume you can do whatever you want with one.
Closed models are API or product-only. GPT-6, Claude, and Gemini all fall here. You send a request, you get a response, and you never touch the weights. You can't download them, inspect them, or run them on your own infrastructure under any circumstances. The vendor controls the compute, the updates, and the availability.
Neither category is "better." They're built for different tradeoffs, and which one makes sense depends entirely on what you're optimizing for.
The real tradeoffs
Data residency and privacy. If you're in a regulated industry, or a jurisdiction with strict data localization rules, sending sensitive data to a third-party API can be a nonstarter regardless of how good that API's model is. Self-hosting an open-weight model means your data never leaves infrastructure you control. That's frequently the deciding factor for healthcare, finance, and government use cases, well before model quality even enters the conversation.
Cost at scale. Closed models charge per token, and that adds up fast at high volume. Open-weight models shift the cost structure: instead of paying per request, you pay for the compute to run the model yourself, which can be cheaper at serious scale, but only if you actually have the infrastructure expertise to run it efficiently. A team without that expertise can easily spend more self-hosting a mediocre setup than they would have paid an API vendor.
Customization through fine-tuning. With an open-weight model, you can fine-tune it directly on your own data, your own domain vocabulary, your own edge cases. That's a level of customization closed models generally don't offer in the same way. If your use case is narrow and well-defined (classifying a specific kind of document, generating text in a very particular house style) a fine-tuned smaller open-weight model can outperform a much larger general-purpose closed model on that specific task.
Not having to manage infrastructure. This cuts the other way. Closed models mean you don't have to think about GPU provisioning, model serving infrastructure, scaling under load, or keeping up with new model releases. You call an API and it works. For a small team without dedicated ML infrastructure people, that operational simplicity is often worth more than any cost savings from self-hosting, and it's the reason most teams default to closed models even when an open-weight alternative exists.
When each makes sense
Reach for an open-weight model when data can't leave your environment, when you're running at a scale where per-token API costs become a real budget line item, or when you need deep fine-tuning on a narrow task that a general-purpose model handles poorly. Reach for a closed model when you want the strongest general-purpose capability without building infrastructure, when your volume doesn't justify the operational overhead of self-hosting, or when you need a model to just work reliably without a dedicated team maintaining it.
In practice, plenty of real systems use both: a closed model for the flexible, general-purpose parts of a product, and a fine-tuned open-weight model for one narrow, high-volume task where the economics clearly favor self-hosting.
The landscape moves fast
The specific roster of leading open-weight models changes quickly. As of this writing, notable ones include DeepSeek V4.1, Qwen3.8, Kimi K3, and GLM-5.3, alongside longer-standing families like Llama and Mistral/Gemma. Rather than memorize a list that will be outdated within months, treat this as a category to evaluate fresh each time you need it. For the fuller, more current survey of what's available and how the major options compare, see our open-weight models roundup.
You've completed the Models & Architectures track
You've now covered how model families differ, how to choose between them, reasoning models, multimodal capability, world models and JEPA, and the open-versus-closed-weights decision. That's the full picture of how today's models are built and what actually separates one from another. Head back to the Models & Architectures track to revisit any lesson, or move on to another part of the curriculum to keep building your prompting skills.