Open-weight vs proprietary LLMs: what should enterprises choose?

The choice between open-weight vs proprietary LLMs is a choice about control. A proprietary model is rented through an API: the vendor owns the weights, sets the price and decides when the model retires. An open-weight model publishes its weights, so you can run, fine-tune and keep it wherever you like, but you take on serving, evaluation and licence compliance.

Neither is better in general. The right answer depends on the task, the data, the volume and how long the workload has to live. This guide defines the terms, maps the late-2026 landscape and gives a decision framework you can apply to one workload at a time.

What do open-weight, open-source and proprietary actually mean?

Three terms get used interchangeably, and they shouldn’t be.

• Proprietary (closed) models are reachable only through the vendor’s API or products. You never see the weights. Examples are the frontier models from OpenAI, Anthropic and Google’s Gemini line.
• Open-weight models publish their trained parameters for download under a licence. You can run them on your own hardware or cloud account and usually fine-tune them. The licence may still restrict who can use them and how.
• Open-source AI has a stricter, formal meaning. The Open Source Initiative’s Open Source AI Definition 1.0 requires the freedom to use, study, modify and share the system “for any purpose”, and it requires the preferred form for modification: the parameters, the complete code used to train and run the system, and data information detailed enough that “a skilled person can build a substantially equivalent system.”

Most popular releases publish weights and inference code but not the full training data information and training pipeline. Some add field-of-use conditions, which conflict with “any purpose”. So the accurate label for Llama, Qwen, Kimi and most others is open-weight, not open source. The distinction matters in procurement: “open source” in a vendor deck does not tell you whether you may offer the model as a service, rename a derivative or ship it to a customer.

Which open-weight model families matter in late 2026, and what do their licences allow?

The table below lists the major families and the licence attached to a notable recent release. Licences now vary by model version, not just by family, which makes the licence a per-model check.

Family (publisher)	Release checked	Licence	Conditions worth flagging
Qwen (Alibaba)	Qwen3.8-27B	Apache 2.0	Standard Apache terms
Qwen (Alibaba)	Qwen3.8-Flash-Next	Qwen Community License 1.0	Separate licence needed for any model-as-a-service (MaaS) or “AI Work Assistant” business, with no revenue threshold; model name displayed above 100M MAU or $20M monthly revenue; internal use exempt
Qwen (Alibaba)	Qwen3.8-2.4T-A95B	Qwen3.8-Max License	Same structure, but the MaaS/AI Work Assistant clause applies only above $50M revenue in any 12 months
DeepSeek	DeepSeek-V4.1-Flash, DeepSeek-V4-Pro	MIT	Standard MIT terms
Kimi (Moonshot AI)	Kimi-K3.1-Pro	Custom (modified MIT)	MaaS businesses above $20M revenue in any 12 months need a separate agreement; “Kimi K3.1-Pro” displayed above 100M MAU or $20M monthly revenue; internal use exempt
GLM (Z.ai)	GLM-5.3	Custom (modified MIT)	MaaS businesses with over $10B combined revenue in any 12 months must pass a Z.ai security review
Mistral AI	Mistral-Large-4-1T-A52B	Mistral Ecosystem Open-Weight License (modified MIT)	Any MaaS business needs a separate commercial licence, with no revenue threshold; internal use exempt. Mistral Large 3 and Ministral 3 (Dec 2025) are Apache 2.0
Meta	Muse Glimmer 30B	Apache 2.0	Standard Apache terms
Meta	Muse Spark Open 816B-A42B	Muse Model License (gated)	“Built with Muse Spark Open” display, including for fine-tuned or distilled derivatives; MaaS businesses above $20M gross revenue in any 12 months must notify Meta and sign a separate agreement. Llama 4 (Apr 2025) remains under the Llama 4 Community License
Gemma (Google)	Gemma 4 (E2B to 31B)	Apache 2.0	Gemma 3 and earlier use the Gemma Terms of Use
gpt-oss (OpenAI)	gpt-oss-120b, gpt-oss-20b	Apache 2.0	Standard Apache terms

Three patterns stand out.

The “model as a service” clause is the new restriction. The Mistral, Kimi, GLM and Qwen custom licences all define MaaS as giving a third party inference or fine-tuning access (Mistral says “post-training”) in a way that lets it “exercise meaningful control over the inputs, parameters, or training data.” Mistral, Kimi and GLM explicitly exclude end-user products with model capabilities “solely embedded within specific features or harnesses.” The two Qwen licences have no such carve-out in their MaaS definition; their only exclusion is merely relaying requests to models hosted by others. Meta’s Muse Model License has its own MaaS clause with a $20M revenue trigger. If you build an internal tool or a product feature, most of these clauses do not bite. If you resell model access, several do.

Older licences carry older restrictions. The Llama 4 Community License requires a separate licence from Meta for companies that had more than 700 million monthly active users in the calendar month before the Llama 4 release date, a prominent “Built with Llama” notice, and that any distributed derived model name begin with “Llama”. The Gemma Terms of Use that cover Gemma 3 and earlier treat models trained by distillation or on Gemma-generated synthetic data as derivatives, and Google reserves the right to restrict usage it believes violates the terms. Gemma 4 moved to Apache 2.0.

Permissive options exist at every size. If your legal team wants no surprises, Apache 2.0 and MIT models cover small (Gemma 4, Qwen3.8-27B, Muse Glimmer), medium (gpt-oss-120b) and frontier-scale MoE (DeepSeek V4.x) needs.

Mapping the Open Model Landscape in 2025 - Nathan Lambert, Ai2Nathan Lambert (Ai2) · PyTorch Foundation · YouTube · 2025

How big is the quality gap between open and closed models?

Smaller than the marketing on either side suggests, and it moves.

• Epoch AI’s May 2026 analysis found that from January to late May 2026 the most capable open-weight model lagged the frontier closed model by an average of about four months, and by an average of 8 points (90% confidence interval 7 to 11) on its Epoch Capabilities Index, an aggregate capability measure built from public benchmarks. Epoch notes the lag grows to six months under a stricter test, and that it may understate the gap because only models with enough public benchmark coverage get a score and open models may do worse on private benchmarks.
• Stanford’s AI Index 2026 reports that, as of March 2026, the top closed model led the top open model by 3.3% in Arena leaderboard score (a rating from crowdsourced head-to-head human preference votes; 1,503 vs 1,454), up from 0.5% in August 2024: “the open model performance gap reopened in 2025 after briefly closing in 2024.”

Two cautions. First, aggregate indexes measure broad capability. Your task is narrow, and a narrow task can sit far from the average. Second, a fine-tuned mid-size open-weight model is a different object from the same model prompted zero-shot. The only number that settles your decision is the score of each candidate on a held-out set built from your own traffic, which is what a custom evaluation framework is for.

Can Open Models Keep Up With OpenAI and Anthropic? | Nathan LambertNathan Lambert · a16z · YouTube · 2026

How do open-weight and proprietary models compare for enterprises?

Dimension	Proprietary API	Open-weight (self-hosted)	Open-weight (hosted endpoint)
Peak capability	Highest today	Months behind on broad indexes	Same as self-hosted
Data boundary	Vendor terms and regions	Your account or data center	Provider’s terms and regions
Customization	Prompting; fine-tuning only where the vendor offers it	Full: SFT, LoRA, preference tuning, distillation	Usually LoRA or SFT
Cost shape	Per token, scales linearly	Per GPU-hour, flat while busy	Per token or per GPU-hour
Ops burden	Lowest	Highest	Low to moderate
Lifecycle control	Vendor retires models	You keep the weights forever	You keep the weights; endpoint may change

The third column is often missed. You can use open weights without running GPUs yourself: hosted inference providers serve popular open-weight models and your own fine-tuned adapters. You keep the portability of open weights, since you can move the same weights to another provider or in-house later, without carrying the full ops burden from day one.

What decision framework should enterprises use?

Score each workload, not the company. One organization will reasonably use both.

Control and customization

If the task needs a specific output format, house style, domain vocabulary or behavior that prompting can’t hold reliably, you need to change the weights. With open weights, supervised fine-tuning with LoRA is the standard route; see the post-training guide. With proprietary models, check whether tuning is still offered for the model you need, and on what terms.

Data governance and residency

Ask where prompts, outputs and training data are stored and processed, for how long, and who can access them. Proprietary vendors offer enterprise terms such as data-retention controls and regional processing, and you should read them for each product. Self-hosted open weights let you answer every question yourself, which is decisive for some regulated workloads and contractual data-residency commitments.

Cost at volume

API cost scales with tokens. Self-hosted cost scales with GPU-hours, so it depends on utilization. Use this formula rather than anyone’s headline claim:

• API monthly cost = requests × (input tokens × input price + output tokens × output price)
• Self-hosted monthly cost = GPUs × hourly rate × 730 hours + engineering and on-call time + evaluation and upgrade work

Example (all prices assumed for illustration, not quotes): suppose 2M requests a month at 1,500 input and 300 output tokens. That is 3.0B input and 0.6B output tokens. At an assumed $1.00 per million input and $4.00 per million output tokens, the API bill is $3,000 + $2,400 = $5,400 a month. The same traffic averages about 1,400 tokens a second, most of them input tokens, so a small model on two GPUs at an assumed $3.00 an hour could carry it if peaks are modest: $4,380 a month before anyone’s time. At this volume the two are close, and engineering time decides. At ten times the volume the API bill grows tenfold, while two GPUs that sit mostly idle today can absorb much of that growth, so self-hosted cost rises far less and self-hosting starts to pay. A smaller fine-tuned model shifts the line further, which is the logic behind reducing LLM costs through specialization.

Latency

A small model on dedicated hardware near your users can give low, predictable latency. Shared APIs vary with load and region. If you have a strict latency budget, measure p50 and p95 for each option under realistic concurrency.

Operational burden

Self-hosting means capacity planning, autoscaling, GPU availability, serving-stack upgrades (vLLM, SGLang and similar), monitoring and an on-call rotation. If you don’t have that team, start with an API or hosted endpoint and keep the option to move.

Vendor and lifecycle risk

Proprietary models retire on the vendor’s schedule. Anthropic, for example, commits to at least 60 days’ notice before retiring a publicly released model, and requests to retired models fail. Fine-tuning access can disappear too: OpenAI’s deprecations page records that from May 7, 2026, organizations that had not previously run fine-tuning could no longer create jobs, from July 2, 2026, the same applied to organizations that had not run inference on a fine-tuned model in the previous 60 days, and from January 6, 2027, “active existing customers will no longer be able to create new fine-tuning jobs.” Fine-tuned models there follow their base model’s shutdown schedule. If a workload must run unchanged for years, or if you have invested in tuning data, owning open weights removes that dependency.

Security

Open weights give you control and also responsibility. You patch the serving stack, scan model artifacts, avoid executing untrusted model code and keep the weights from leaking. Both kinds of model can lose safety behavior through fine-tuning: Qi et al. (2023) broke GPT-3.5 Turbo’s guardrails by fine-tuning it on 10 adversarial examples through the vendor’s API and found benign fine-tuning also degraded safety, to a lesser extent. Whatever you tune, re-run safety and refusal tests before shipping.

When does a hybrid architecture make sense?

For most enterprises, the answer is “both, routed by task.” A typical split:

• Frontier proprietary API: open-ended analysis, complex multi-step agents, low-volume high-stakes reasoning, and new use cases still being discovered.
• Tuned open-weight model: extraction, classification, routing, summarization in a fixed format, domain-specific drafting, anything with millions of similar calls a month.
• Retrieval for both: facts that change go in a retrieval index, not in the weights. Fine-tuning vs RAG vs prompt engineering covers that split.

Routing can be as simple as a rule per endpoint or as involved as a classifier that picks a model per request. Keep a fallback: if the specialized model’s confidence or validation check fails, escalate to the frontier model. Evaluate the system end to end on the same test set you used to justify the split.

A common progression is to prove value on a frontier API, log real traffic, then use that traffic to build a domain-specific model for the high-volume slice. This is the work Attempts does: tune an open-weight model on a client’s data, measure it against what they run today, and recommend against training when prompting or retrieval is already enough.

What do teams most often get wrong?

• Treating “open” as one thing. Apache 2.0, MIT, community licences and MaaS-restricted licences are not interchangeable. Record the licence per model version in your model registry.
• Comparing a tuned proprietary demo to an untuned open model, or the reverse. Compare candidates under equal effort on the same held-out set.
• Ignoring the cost of people. GPU prices are visible; the engineer who maintains the serving stack is not, and often costs more.
• Assuming the leaderboard ranks your task. Narrow tasks often favor a smaller tuned model over a larger general one. Measure.
• Forgetting exit plans. For every proprietary dependency, know which replacement you would test and how long migration would take.

Checklist: choosing for one workload

1. Define the task, the success metric and the minimum acceptable score.
2. Build a held-out evaluation set from real, representative inputs.
3. Measure your current baseline (today’s prompt and model).
4. Estimate monthly tokens now and in 12 months; compute API and self-hosted cost with the formulas above.
5. List data constraints: residency, retention, PII, contractual terms.
6. Shortlist two or three open-weight models whose licences fit your use, including any MaaS, attribution or naming clauses.
7. Test prompting and retrieval first; fine-tune only if a measured gap remains.
8. Compare candidates on quality, p95 latency, cost per 1,000 requests and safety tests.
9. Decide who operates the model: you, a hosted endpoint or the vendor.
10. Write down the exit plan: model retirement, licence change or price change.

If you want a second opinion on a specific workload, see the models we work with or describe your use case.