Proprietary vs open-weight models

Every team building with LLMs makes this choice early, often without realising it is a choice. Call a model you can never see through someone else's API, or download a model's weights and run it on hardware you control. The decision affects your costs, where your data goes, what quality you get, and how many people you need to keep it running.

Two ways to get a model

Recall from Article 4 that a trained model is, physically, a large file of numbers: its weights. Who holds that file is the whole difference.

A proprietary model keeps its weights private. The company that trained it runs it on its own servers, and you send requests over an API. You never see the weights, cannot run the model elsewhere, and get whatever version the provider currently serves. Anthropic's Claude, OpenAI's GPT models and Google's Gemini models are proprietary.

An open-weight model publishes its weights for download. You can run it on your own GPUs, on a cloud provider's rented GPUs, on a laptop (Article 12), or through a third-party host that serves it for you. Meta's Llama family and several models from Mistral, Alibaba's Qwen team and DeepSeek are well-known examples.

The diagram shows where the weights live in each case, using our bug-fix agent as the client.

flowchart TD
    A["Bug-fix agent"]:::io --> P["Provider's API"]:::infra
    P --> M1["Proprietary model"]:::model
    A --> S["Your own servers"]:::infra
    S --> M2["Open-weight model"]:::model
    M1 -.- W1["Weights stay with vendor"]:::warn
    M2 -.- W2["Weights in your hands"]:::warn
    classDef model fill:#2a2140,stroke:#a78bfa,color:#ece5ff
    classDef infra fill:#12302d,stroke:#2dd4bf,color:#d5fbf5
    classDef io fill:#1f1d1a,stroke:#8a8275,color:#ece5d8
    classDef warn fill:#3a1d18,stroke:#fb7a5e,color:#ffe1d9

Figure 11.1: The same agent can call a proprietary model through an API, or an open-weight model it runs itself. The difference is who holds the weights.

Open weight is not open source

These two terms get mixed up constantly, and the difference matters if your legal team is asking.

Open weight means the trained weights can be downloaded. That is all it guarantees. The training data is usually not released, the training code often is not either, and the licence may restrict how you use the model.

Open source has a stricter meaning. In software, the Open Source Initiative's definition requires that anyone can use, study, modify and share the work for any purpose. In October 2024 the OSI published an Open Source AI Definition that applies the same idea to models: to qualify, a model must come with the weights, the complete code used to train and run it, and enough detail about the training data that a skilled person could build a substantially equivalent model, all under terms that grant those freedoms.

By that standard, most popular "open" models are open weight, not open source. A few projects do release weights, code and training data together, such as the Allen Institute for AI's OLMo models. The practical point: when someone says a model is "open source", check what was actually released and what the licence says.

The chart shows the main levels of openness, from most closed to most open.

Figure 11.2: "Open" covers a range. Most popular downloadable models sit in the middle two rows, not the bottom one.

What the licence lets you do

Model licences fall into roughly three groups. I am simplifying, and the exact terms of any model you use are worth reading in full.

• Permissive licences such as Apache 2.0 and MIT, the same ones used for ordinary open source software. You can use the model commercially, modify it and redistribute it, mostly with attribution and notice requirements. OpenAI's gpt-oss models and DeepSeek's R1 weights, for example, were released under Apache 2.0 and MIT respectively.
• Custom "community" licences written by the model's maker. These usually allow commercial use but add conditions. Meta's Llama licences, for instance, include an acceptable use policy and require companies with more than 700 million monthly active users to get a separate licence from Meta. Some custom licences have also restricted using the model's outputs to train other models, so read the current terms for any model you choose.
• Non-commercial or research licences, which rule out using the model in a paid product at all.

Licence terms can change between model versions, even within one family. As of October 2026, check the licence of the exact version you deploy, not the family's reputation.

The trade-offs

Here is how the two options compare on the things that usually decide it.

The quality row is the one most likely to change. As of October 2026, a commonly held view is that the best open-weight models trail the best proprietary models on the most demanding reasoning and coding tasks, while matching them on many routine tasks. Independent trackers in 2026 put the leading open-weight models a few months behind the leading proprietary ones. That gap has moved in both directions over time, so check current results rather than relying on any article, including this one.

Worked example: when does self-hosting pay off?

All prices here are illustrative round numbers chosen to show the method, not quotes from any provider.

Suppose your team's bug-fix agent handles 1,000 tickets a month. Each ticket uses about 300,000 input tokens and 10,000 output tokens (agents re-send their context often, so input dominates).

API cost, at an illustrative $3 per million input tokens and $15 per million output tokens:

• Input: 1,000 × 300,000 = 300 million tokens. 300 × $3 = $900.
• Output: 1,000 × 10,000 = 10 million tokens. 10 × $15 = $150.
• Total: $1,050 a month.

Self-hosted cost, renting one GPU server at an illustrative $2.50 per hour, running all month:

• 730 hours × $2.50 = $1,825 a month, before anyone's time to run it.

At this volume the API is cheaper, even before counting engineering time. Now suppose usage grows tenfold to 10,000 tickets. The API bill grows to $10,500. If one GPU server can still handle the load thanks to batching (Article 10), self-hosting costs about the same $1,825 plus operations time, and becomes clearly cheaper. The break-even depends on how busy you can keep the hardware. An idle GPU still costs money every hour.

Choosing in practice

Most teams do not pick one forever. A simple way to think about it:

The flowchart shows a first-pass decision for a single use case.

flowchart TD
    Q1["Can the data leave your network?"]:::io -->|"no"| O["Open-weight, self-hosted"]:::infra
    Q1 -->|"yes"| Q2["Need the very best quality?"]:::io
    Q2 -->|"yes"| P["Proprietary API"]:::infra
    Q2 -->|"no"| Q3["High, steady volume?"]:::io
    Q3 -->|"yes"| O
    Q3 -->|"no"| P
    classDef infra fill:#12302d,stroke:#2dd4bf,color:#d5fbf5
    classDef io fill:#1f1d1a,stroke:#8a8275,color:#ece5d8

Figure 11.3: A rough first decision. Real choices also weigh licences, team skills and latency needs.

Many organisations end up hybrid: a proprietary model for the hardest work and open-weight models for high-volume or sensitive tasks, with an LLM gateway (Article 17) routing between them.

Where this shows up in our bug-fix agent

The agent reads source code, and source code is often a company's most sensitive asset. That makes the choice concrete.

• If code may leave the network under a provider's data processing terms, the agent can call a proprietary model for the hard parts: understanding BUG-1423, finding the cause in auth/login.py, and writing email = email.strip().lower() plus the new test.
• If it may not, the whole agent runs against an open-weight model on company GPUs. The fix for this bug is simple enough that a mid-sized open-weight model would very likely manage it. Harder bugs are where a quality gap would show.
• A hybrid split is common: a small open-weight model summarises long pytest output and log files cheaply, and a stronger model writes the code and the pull request "Normalise email case on login (BUG-1423)".
• Version pinning matters for agents. When a proprietary provider updates a model, your agent's behaviour can shift overnight. With open weights, the exact model you tested is the one you run until you decide to change it. Article 18 covers how evals catch these shifts.

Common misconceptions

"Open weight means open source." It means the weights are downloadable. Open source, as the OSI defines it for AI, also requires training code and enough information about the data to rebuild the model, under terms granting full freedoms.

"Open-weight models are free." The download is free. The GPUs, electricity, and engineers to run serving, scaling and security are not. At low volume, an API is often cheaper.

"Using an API means the provider trains on my data." That depends on the provider's terms, which often differ between consumer apps and business API plans. Read the data processing terms for your plan rather than assuming either way.

"Self-hosting makes it private automatically." It removes one third party. You still have to secure the servers, the logs that may contain prompts, and who can access them (Article 19).

Key takeaways

• Proprietary models are used through an API and their weights stay private. Open-weight models publish their weights so you can run them yourself.
• Open weight is not open source. True open source AI also releases training code and data information under terms that grant full freedoms.
• Licences range from permissive (Apache 2.0, MIT) to custom licences with conditions to non-commercial only. Check the exact version you deploy.
• APIs win on convenience and top-end quality at low volume. Self-hosting wins on data control, version stability and cost at high, steady volume.
• Many teams run both and route each task to the right model.

Glossary

• Proprietary model: a model whose weights are kept private and which is accessed through the owner's API.
• Open-weight model: a model whose trained weights are published for download.
• Open source AI: a model released with weights, training code and sufficient training data information, under terms allowing anyone to use, study, modify and share it.
• Licence: the legal terms that set what you may do with a model.
• Permissive licence: a licence such as Apache 2.0 or MIT with few conditions beyond attribution.
• Acceptable use policy: a list of uses a model's licence forbids.
• Self-hosting: running a model on infrastructure you control rather than through a provider's API.
• Version pinning: keeping a system on one exact model version so its behaviour does not change unexpectedly.

Next up

If you go the open-weight route, the next question is what hardware you need. In Article 12: Running models locally, we do the memory arithmetic for real model sizes, explain how quantization shrinks a model to fit, and compare tools like Ollama and llama.cpp with production serving.