Commercial vs. Open-Weight Models: What the Distinction Actually Is

Status: Context and orientation — not a workshop topic in itself, but a distinction researchers increasingly hear about ("just use an open-source model") without a clear sense of what changes and what doesn't. A.adjacent.tools already covers the infrastructure side (Ollama, e-INFRA CZ, harness compatibility). This document covers the conceptual side: what "open-weight" means, how it differs from "open-source," and where the real trade-offs are — and are not.

1. "Open-weight" is not "open-source"

The two terms get used interchangeably, and the difference matters.

Open-weight means the trained model's parameters (the "weights" — the numbers that define what the model does) are published and downloadable. Anyone can run the model on their own hardware, inspect its outputs, fine-tune it, or redistribute it, subject to whatever license the publisher attaches.

Open-source, in the traditional software sense, would additionally mean the training code, the training data, and the training process are published — so the model could in principle be reproduced from scratch, not just re-run.

Almost no widely-used "open" model is open-source in this fuller sense. Llama, Mistral, Qwen, DeepSeek — all publish weights; none publish the full training data. You can run the model, adapt it, inspect what it does — but you cannot verify what it was trained on, in what proportions, with what filtering, or with what licensing status for the underlying content. This is worth knowing because "open" carries a strong transparency connotation that only partially applies here.

Commercial models (Claude, GPT, Gemini) publish neither weights nor training data. You interact with the model only through an API or an interface; the parameters never leave the vendor's infrastructure.

2. Licensing: "open" often has real restrictions

Open-weight licenses are not uniform, and several carry conditions researchers should not assume away:

The practical takeaway: "It's open-weight" does not automatically mean "no legal terms apply" or "I can do anything with it." Read the specific model's license before assuming a use case (institutional redistribution, embedding in a product, training-data reuse) is covered.

3. The capability gap — real, and narrowing

As of this writing, frontier commercial models (Claude, GPT, Gemini's top tiers) generally lead on long-context reasoning, multi-step agentic tasks, and reliability on complex instructions — the kind of work this book's Claude Code workflows depend on. The best open-weight models (DeepSeek, Qwen, Kimi, GLM, Mistral's larger releases) are closing that gap quickly and are already strong for many single-turn tasks: summarisation, translation, extraction, code generation on bounded problems.

Where the gap is still most visible for a researcher's actual workflows:

This is a moving target, not a fixed fact — see A.adjacent.tools for the same caveat about hardware and capability claims going stale fast. The direction of travel is toward convergence, not divergence.

4. Cost model: metered API vs. compute you own or rent

Commercial models are metered — you pay per token (API) or a flat subscription (Claude Pro/Max) with usage limits. No hardware to manage; cost scales directly with use. See A.issue.costs-quotas for the mechanics.

Open-weight models, run yourself, shift the cost from per-use metering to infrastructure: buying or renting a GPU, or (the realistic option for most researchers, per A.adjacent.tools) using a shared research infrastructure service like e-INFRA CZ's Chat AI, where the institution absorbs the compute cost. The trade-off is not "free vs. paid" — it is "pay per request" vs. "pay for capacity, whether or not you use all of it" (or, in e-INFRA CZ's case, pay nothing yourself because your institution already provisioned it).

At small individual scale, commercial subscriptions are usually cheaper and simpler than provisioning your own compute. At large, sustained institutional scale, self-hosted or institutionally-hosted open-weight inference can be cheaper — this is a genuine consideration for a research group running high-volume batch processing, not for an individual researcher's day-to-day use.

5. Data handling: this is the axis that actually matters most for DISSINET

This is covered in full in A.issue.privacy-security, so only the summary belongs here: the commercial/open-weight distinction is the clearest lever a researcher has over where sensitive data goes. A commercial API call always leaves your machine and reaches the vendor's servers, regardless of what the vendor's policy says about training or retention. A locally-run, or institutionally-hosted-and-contained, open-weight model is the only setup where research data does not leave a controlled environment. For personal data of living subjects or identifiable interview material, this is not a preference — see the decision flowchart in A.issue.privacy-security.

6. Training data transparency: less clear-cut than "open" suggests

A common assumption is that open-weight models are more transparent about what they were trained on. In practice this varies enormously and is often not true in any meaningful sense:

The practical point: do not choose open-weight specifically for training-data transparency or copyright-provenance assurance — that expectation is mostly not met by current open-weight releases either. Choose it for the reasons in §5 and §7 (data control, customisation), not for an assumed transparency advantage that mostly doesn't exist yet at the frontier.

7. Customisation and longevity

Two structural advantages of open-weight that have nothing to do with cost or privacy:

Fine-tuning and adaptation. An open-weight model's parameters can be further trained on your own data — a specialised vocabulary, a particular document genre, a language variety underserved by general training data. This is not possible with a commercial model beyond prompt-level customisation (CLAUDE.md, system prompts) — you can shape how Claude behaves, never what its underlying weights are.

Longevity independent of a vendor. A downloaded model's weights keep working even if the company that released them shuts down, changes its API, or deprecates the model version. A workflow built entirely on a commercial API is exposed to the vendor's business decisions — pricing changes, model deprecation, policy shifts. This matters for reproducibility of a described research method: a paper that says "processed with Llama-3-70B, weights available at [X]" describes something a reader can rerun years later; a paper that says "processed with Claude" describes something dependent on whether that exact model version is still served.

This second point is a genuine, under-discussed reproducibility argument for open-weight models in research methodology sections — distinct from the cost and privacy arguments usually made.

8. When the distinction actually matters for a DISSINET researcher

It rarely matters for day-to-day work. Reading sources, drafting, extracting data, iterating on a project with Claude Code — the commercial/open-weight choice is not the live question; the live question is whether you should be sending this specific data anywhere at all (→ A.issue.privacy-security).

It matters when:

It does not, currently, matter for:

Related