Open weights remove one kind of lock-in, not all of it

• 5 October: Reflection AI introduced Beam, a 501-billion-parameter open-weight model.
• 10 October: the Financial Times reported that Nvidia was in talks to invest more in the lab, or buy it.
• 16 October: Beam’s weights went up on Hugging Face under Apache 2.0.

I am not making a claim about what will happen to Reflection AI. The caveats in the reporting are real. The talks are at an early stage and could still fall apart, according to the FT. Reuters could not verify the report, and neither company commented. The FT also says Nvidia has already invested $800 million. I use the episode as an illustration of a general structure, not as a prediction.

Apache 2.0’s copyright licence is perpetual and irrevocable. Whatever happens to the lab, the licence on the version you downloaded does not lapse. If you have the weights, you have the right to keep using them. That is a real protection, and it is the reason open weights appeal to firms that have been burned by a vendor changing terms or retiring a model.

It also means the usual closed-model risks are different. You are not exposed to a change in an API’s price, a deprecation notice or a rate limit, because you run the model yourself.

It gives you nothing about what comes next. Reflection’s own release post promises training recipes “in the coming days” and more tool support “over time”. Those are promises about the future, and the future belongs to the lab. Fixes, updates and the next version are the lab’s decisions, and a new owner could change them.

So the dependency has moved. With a closed model, you depend on a vendor’s API. With an open model, you depend on a lab’s roadmap. The second dependency is gentler, because you can keep running what you have, but it is still a dependency. Think of it as the difference between a service that can be switched off and a product that can stop being improved.

A model is not a finished object. The surrounding tooling, the inference libraries, the quantised builds, the fine-tuning recipes and the bug fixes all arrive over time, mostly from the people who made the model. If that stream stops, the weights still run, but you are on your own for everything around them.

For a team that has built a workflow on one model, the cost shows up later and in small pieces: a library update that no longer supports your version, a security issue nobody patches, a new capability you cannot get without migrating. None of these is a crisis. Together they are a slow loss of footing.

I would add two questions to any checklist for building on an open model.

Who funds the lab, and who could end up owning it? A lab with one large investor, or a visible acquirer, has a different future from one with diversified backing. This is not a judgement on the investor. It tells you where decisions about the roadmap could come from.

Could we run this exact version for two years if nothing new ever shipped? This is the stress test. Suppose the lab stopped tomorrow. Would the model still do the job you need? Would you have the weights, the tokenizer, the configuration and the serving stack saved somewhere you control? If the answer is yes, a change of ownership is an inconvenience. If it is no, you have built on something more fragile than you thought.

Before committing a workflow to an open-weight model, I would want to see:

1. The licence text, read by someone who can interpret it, and noted in the project file.
2. A local copy of the exact weights and every file needed to run them, with a record of the version.
3. A named person responsible for the serving stack, so that updates do not depend on goodwill.
4. A fallback: a second model that could take over the task, tested on the same examples.
5. A regular check on the lab’s funding and ownership, as part of the quarterly review rather than a one-off.
6. A test set of your own tasks, so that moving to another model is a measurement and not an argument.

The last item is the one that turns lock-in from a worry into a manageable cost. If you can score any candidate model on your own examples, switching is work, not a leap.

This matters particularly if you are moving routine work to smaller models to control cost. The appeal is that you pay a fixed cost and a maintenance cost, not a running cost per query. That is a real advantage, but the maintenance cost is the part that depends on the lab’s future. Budget for it, and do not treat “free to run” as “free to own”.

Has a change of ownership ever left a tool your team relied on stuck at its last version? If so, you already know what this looks like. If not, it is cheaper to ask the two questions now than to learn the answer after the fact.