Open Source vs Proprietary AI Strategy

Open-weight or proprietary? Self-host or call an API? These decisions shape your costs, your control and your risk. There is no universal answer — only a framework for deciding based on your priorities. This tutorial provides that framework, building on foundation models deep dive.

The two models of the two models#

Total cost of ownership#

The per-call price of a hosted API is visible; the cost of self-hosting is not, and is routinely underestimated.

Vendor lock-in: more manageable than it feels#

Lock-in is a real risk but largely a design choice. The ChatModel abstraction means your application code does not depend on a provider — switching is a configuration change. The genuine lock-in risks are narrower:

• Prompts tuned to one model's quirks — mitigate by testing prompts across models occasionally, and by not over-fitting to one model's idiosyncrasies.
• Provider-unique features — a capability only one provider has creates dependence; weigh whether it is worth the coupling.
• Fine-tuned models — a fine-tune is provider-specific; it ties you more than prompting does.

// Portability by design: your code depends on the interface, so provider is a
// config decision, not an architectural commitment. This is your best defense
// against lock-in.
public class Assistant {
    private final ChatModel model;   // not OpenAiChatModel
    public Assistant(ChatModel model) { this.model = model; }
}

The hybrid strategy#

Many mature teams use both, routing each task to the model that suits it:

This captures the strengths of each: proprietary capability where it matters, open-weight economics and privacy where they do. It also reduces dependence on any single provider. The cost is running two paths — see small language models and model routing.

A decision framework#

Weigh the factors by your priorities:

1. Capability need — does your hardest task require a frontier model, or is a good open model enough? Measure, do not assume.
2. Volume and pattern — high steady volume favours self-hosting; bursty or low favours hosted.
3. Data sensitivity — data that cannot leave your boundary points to self-hosted or in-region.
4. Operational capacity — do you have the team to run inference infrastructure well?
5. Lock-in tolerance — how much does independence from any one provider matter to you?
6. Time to market — hosted APIs start in minutes; self-hosting is a project.

For most teams starting out, the answer is: begin with a hosted API (fast, capable, no infrastructure), design for portability (depend on the abstraction), and add self-hosted open models later for the specific tasks — high volume, sensitive data — where they earn their operational cost. That path keeps your options open without paying for complexity before you need it.

The strategy is not permanent#

Model capabilities, prices and the open-vs-proprietary gap all move quickly. A strategy that is right today may not be in a year. Designing for portability is what lets you revisit the decision cheaply — which is the real point. Do not agonise over a permanent choice; make a sensible one now, keep your code portable, and re-evaluate as the landscape shifts.

Next#

• Future of AI & career roadmap
• Small language models
• Foundation models deep dive