What is an Open-weight model?

What the term covers, and what it leaves out

Open-weight is a statement about a specific artefact: the numbers. If a trained model's parameters are downloadable, anyone can load them into a runtime, run inference locally, inspect what the model does to your input, and modify the weights for their own purpose without a commercial relationship with whoever trained it.

That is the whole of the claim, and the confusion starts immediately after it. The label says nothing about the training data, which is usually the part with legal exposure. It says nothing about the training code, the recipe, the data curation or the evaluation. It does not promise the model is good at anything, or that the developer will fix a bug, or that a second version will arrive. And it does not promise the licence is one your organisation has approved: an open-weight model can be published under Apache-2.0, under a custom licence with use conditions, or under a research-only agreement that forbids commercial deployment.

The reason the term exists at all is that the alternative is a model reachable only through a hosted endpoint. That is a different thing, and it has different properties: someone else chooses the model, the API version, the sampling defaults and the uptime, and changing any of them is a negotiation. An open-weight model moves those decisions to the reader.

So the reliable check is short. Are the weights downloadable, in which format, under which licence, and what does that licence permit for your use? A model card that answers those four questions is useful; a blog post that uses the words open model is not.

What you can do once you have the weights

The capabilities that follow from having the parameters are the reason people take this route, and they are worth separating from the ones that do not.

Running it yourself. The model executes on hardware you control, so prompts and outputs stay inside your network. That is the first thing a compliance review asks about and the first thing an open-weight model answers.

Adapting it. Fine-tuning, distillation, quantization, continued pretraining and pruning all need weights, and all of them are impossible through an API. A domain corpus, an internal style, a small model that inherits a larger one's behaviour: none of these are reachable without the parameters.

Inspecting it. With the weights locally you can look at the outputs for inputs you care about, log what the model does with your data, and reproduce a result months later on the same code.

Independence from a vendor's roadmap. An API can be deprecated, re-priced, or silently changed. A downloaded checkpoint does not do that.

What does not follow is capability parity. An open-weight model is not automatically as good as the best hosted one, and the gap on a given task can be large. Nor does the hardware disappear: running a large open-weight model means buying the accelerators, and the memory requirement is a hard constraint rather than a budget line.

The tooling is what makes this practical rather than theoretical. Serving layers turn a model name into an endpoint, training CLIs wrap the fine-tuning loop behind a config file, and model libraries give a consistent API across families so that swapping one for another is a change of string.

When an open-weight model earns its place

The decision is less about philosophy than about which constraint is binding.

It fits when data cannot leave. Regulated workloads, internal code, unreleased product plans: anything where a prompt is a liability is a case for running the model yourself.

It fits when the task needs the model to become yours. Fine-tuning on your own corpus, a house style, a private evaluation set, a small model that behaves like a large one. Every one of those is a weights operation.

It fits at sustained volume, where paying per token on a hosted endpoint for a predictable workload is a line item that a dedicated machine can replace. The arithmetic is straightforward and the answer depends on utilisation, which is why this is a conversation with the infrastructure team rather than a technical decision.

It fits when reproducibility matters, since a fixed checkpoint plus a fixed runtime gives a result you can re-run.

It does not fit when the task needs the best available capability and no open-weight model is close enough. It does not fit when nobody will own the operations: an endpoint that needs GPUs, patches and monitoring is a liability in the hands of a team that does not run infrastructure. It does not fit when the licence forbids your use, and that check is cheaper to do now than after the integration.

The traps, in the order people fall into them

Five of them cause most of the disappointment.

Assuming the licence is permissive. Open-weight is not a licence category. Read it. Some releases are Apache-2.0 or MIT, some add acceptable-use conditions, some restrict commercial use or require agreement, and the difference decides whether you can ship.

Confusing weights with a system. A checkpoint on its own produces different output from the same weights under a different chat template, a different tokenizer configuration, or different sampling defaults. Most reports of a model getting worse after a switch are template mismatches, and the fix is a configuration detail rather than a different model.

Treating it as satisfying a compliance review by itself. The weights being downloadable says nothing about the provenance of the training data, which is what most review processes actually ask about. An open-weight model can move an open question rather than close it.

Loading an unsafe format. Some checkpoint formats execute code during loading, and loading a model from an untrusted source is a code execution decision. Formats that store plain tensors rather than a program are the ones to prefer for anything you did not produce.

Expecting the model family to be maintained. A checkpoint is a fixed artefact. If you depend on it, you inherit the maintenance question, and the practical move is to pin a version and keep the ability to fall back to something else.

What the projects here add

Almost none of these projects is a model. They are the layers that make an open-weight model usable, and the group a project belongs to tells you what problem it solves.

The model families themselves. openai/gpt-oss is two models, gpt-oss-120b and gpt-oss-20b, which our analysis describes as Apache-2.0 licensed open-weight models trained on the harmony response format, and it is worth noting that the openai/gpt-oss repository holds reference inference implementations rather than the weights. google-deepmind/gemma is Google DeepMind's JAX implementation of the Gemma family, and our analysis is explicit that it is a library rather than a chat app: a Python API for sampling, multi-modal prompting and fine-tuning, with the expectation that you bring your own JAX setup and weights. salesforce/CodeGen is the older shape of the same thing, a family of models for program synthesis where our analysis records three generations, CodeGen1, CodeGen2 and CodeGen2.5, released as weights loadable with the transformers library.

The training and evaluation layer. oumi-ai/oumi wraps data preparation, SFT, DPO and GRPO training, evaluation and inference behind one config-driven CLI, and our analysis describes it as Apache-2.0 and Python-only, which is the shape you want when the fine-tuning recipe is the thing you are iterating on.

The serving layer. bentoml/OpenLLM turns a model name into a running OpenAI-compatible endpoint, with a chat UI and a CLI chat mode, and our analysis is clear that it is a serving layer for teams that already have GPUs rather than a desktop model runner. That is the point: it exists so that application code does not change when the model does.

Composed local stacks. huggingface/speech-to-speech wires Silero VAD, an interchangeable speech-to-text model, an OpenAI-compatible LLM and a local text-to-speech model into one server speaking the OpenAI Realtime event set. Our analysis calls it a good fit when the whole loop has to run on your own hardware and a poor one when you want a hosted drop-in. TencentCloudADP/youtu-agent is a Python agent framework built on openai-agents with Hydra configs, automated agent generation and a training-free GRPO practice module, aimed at developers who want agent evaluation and training loops without depending on closed-model APIs. OpenMOSS/MOSS-TTS is a model family rather than a tool, and our analysis describes it as covering long-form narration, multi-speaker dialogue, voice design, sound effects and real-time streaming.

The pattern is consistent: the weights come from one place, the tooling that runs and adapts them comes from another, and nothing on this list promises that either will be there next year.

In practice

An open-weight model hands you the parameters and nothing else, which is exactly what makes it useful for data sovereignty, fine-tuning and independence from an API, and exactly why the licence, the training data provenance and the chat template deserve the attention people give to the benchmark table. Start with the model family itself, use a serving layer such as bentoml/OpenLLM so your application code does not depend on which model is loaded, and use a config-driven training tool such as oumi-ai/oumi when the recipe is what you are changing. Before committing, read the licence rather than the term, prefer plain-tensor checkpoint formats over ones that execute code on load, and pin a version so that a family which stops being updated does not stop your product.