When you build with AI, you face an early choice: use a closed model accessed through a company's API, or use an open model whose weights you can download and run yourself. Each route has real advantages and trade-offs. The right answer depends on your needs for quality, cost, privacy, control and effort.
Definitions
Closed (proprietary) models
The provider keeps the model weights private. You send requests to their servers and receive results. You pay per use or by subscription. Examples include the large commercial chat models.
Open-weight and open-source models
The provider publishes the model weights so anyone can download, run and often fine-tune them. Terms differ:
- Open-source in the strict sense means a licence that meets open-source definitions, including freedom to use, study, modify and share, ideally with training code and data details.
- Open-weight means the weights are available but the licence may restrict certain uses, require attribution, set size or revenue limits, or forbid some purposes. Many popular "open" models are really open-weight.
Always read the licence.
Advantages of closed models
- Top quality: the most capable models for hard reasoning, long context and multimodal tasks are often closed.
- Easy start: an API key and a few lines of code. No hardware needed.
- Managed service: scaling, updates, safety filters and uptime are handled for you.
- Continuous improvement: the provider upgrades the model.
- Support and tooling: documentation, enterprise contracts and ecosystem integrations.
Disadvantages of closed models
- Data leaves your environment. Even with strong contracts, sending sensitive data to a third party is a risk and may conflict with regulations.
- Cost at scale: pay-per-token can become expensive with heavy use.
- Vendor lock-in: changing providers requires re-testing prompts and workflows.
- Limited control: the model can change or be retired, altering behaviour; terms of use may restrict applications.
- Availability: outages, rate limits and regional restrictions can affect your product.
- No offline use.
Advantages of open models
- Privacy and control: run on your own servers or laptop. Sensitive data stays inside your network.
- Customisation: fine-tune on your data, change the system behaviour and inspect the weights.
- Predictable costs at scale: you pay for hardware or cloud GPUs rather than per token, which can be cheaper at high volume.
- No dependency on one vendor, and the model version stays fixed until you change it.
- Offline and edge use: smaller models run on laptops and even phones.
- Research and learning: you can study and experiment freely.
Disadvantages of open models
- Quality gap on the hardest tasks, although the gap has narrowed and varies by task.
- Operational effort: you must handle hosting, scaling, monitoring, updates and security.
- Hardware needs: larger models need powerful GPUs and a lot of memory.
- Safety and moderation are your responsibility.
- Licence complexity: terms vary and may restrict commercial use.
- Support: community help rather than a service-level agreement, unless you buy a managed offering.
Comparison table
| Factor | Closed (API) | Open (self-hosted) |
|---|---|---|
| Peak capability | Often highest | Close behind for many tasks |
| Time to first result | Minutes | Hours to days |
| Data privacy | Depends on provider terms | Full control |
| Cost for low usage | Low | Higher (hardware) |
| Cost for very high usage | Can be high | Often lower |
| Customisation | Limited fine-tuning options | Extensive |
| Maintenance | Provider | You |
| Offline use | No | Yes |
A hybrid approach
Many teams combine both. Use a closed model for complex tasks or prototypes, and an open model for high-volume, simple or sensitive tasks. Design your application with an abstraction layer so you can swap models easily.
from typing import Protocol
class TextModel(Protocol):
def complete(self, prompt: str) -> str: ...
class HostedModel:
def __init__(self, client):
self.client = client
def complete(self, prompt: str) -> str:
r = self.client.messages.create(model="claude-sonnet-5-5", max_tokens=300,
messages=[{"role": "user", "content": prompt}])
return r.content[0].text
class LocalModel:
def __init__(self, generator):
self.generator = generator # for example a transformers pipeline
def complete(self, prompt: str) -> str:
return self.generator(prompt, max_new_tokens=300)[0]["generated_text"]
def summarise(model: TextModel, text: str) -> str:
return model.complete(f"Summarise in three bullet points:\n{text}")This pattern lets you test the same task against both and switch based on cost, quality or privacy needs.
How to choose
- Data sensitivity: if you cannot send data outside your organisation, favour open models.
- Quality needs: run a test with your real examples on both kinds of models. Compare quality, not marketing.
- Volume: estimate monthly tokens and compare API cost with infrastructure cost.
- Team skills: do you have people who can run GPUs and monitor services?
- Time to market: closed APIs are faster to start.
- Licence: confirm that the licence allows your commercial use.
- Languages: test Nepali or other languages you need, as quality differs widely.
- Risk: plan for provider changes, outages and model retirements.
Frequently Asked Questions
Are open models free?
The weights may be free to download, but running them costs hardware, electricity and engineering time.
Are open models less safe?
They are not inherently less safe, but you are responsible for adding safeguards. Closed providers include built-in filters.
Can I fine-tune closed models?
Some providers offer fine-tuning with restrictions. Open models allow deeper customisation.
Will open models catch up completely?
The gap changes over time. For many practical tasks, open models are already good enough.
Conclusion
Closed models offer convenience and top performance; open models offer privacy, control and flexibility. Test on your real tasks, check licences and consider a hybrid design that lets you switch as needs and technology change.