Open Weights Are Not Freedom

The argument for open-weights models is clean and, on its own terms, correct. When the weights live on your own GPUs, no vendor can change the price on you, deprecate the model on a Tuesday, throttle you at a peak hour, or read your prompts through a logging layer you do not control. For a category of buyer that has been burned by exactly those behaviours, the open-weights pitch lands as liberation. It is presented, often, as the answer to the lock-in problem the whole industry has been arguing about for two years.

On the narrow question it addresses, it works. You can run the model. You can fix the inference cost. You can keep running it for as long as you are willing to pay for the hardware. If a vendor shuts down tomorrow, your service stays up. These are real guarantees, and for some workloads they are the guarantees that matter, and this essay is not an argument against open weights. It is an argument that open weights solve the easy half of a problem whose hard half is still waiting.

The hard half is this. The goal was never to run a model. The goal was to ship an agent that does something useful, reliably, at a cost you can defend. Running the model is one ingredient in that agent. The other ingredients are the prompt that makes the model behave, the tool definitions the model calls, the retrieval and memory that feed the model, and the evaluation set that proves the whole thing works. Open weights replace one ingredient and leave the other four exactly where they were. The question is whether the lock-in you were trying to escape lived in the ingredient you replaced or in the ones you kept.

Lock-in is not a property of a component. It is a property of a seam. You are locked in to the degree that replacing one component forces you to rewrite the others. By that measure, the model weights are the least binding component in the stack, because they are the one everybody already expects to replace. The frontier model you shipped on last spring is not the one you are shipping on now, and the team has already built the muscle to migrate. Weights are the layer with the most migration practice and the most tooling. They were never the layer that held you.

The layers that hold you are the ones that were never built to be portable, because nobody framed them as components at all. A prompt is not written to be model-agnostic. It is written, iteratively, against one model's tendency to follow instruction format X, to need a system preamble of a certain length, to drift unless it is reminded of a rule every third turn. The prompt is a fitting of the model's quirks, and it is the artefact that carries the most tacit knowledge in the system. Swap the weights and the prompt is suddenly talking to a different personality, and the personality does not understand the same instructions the same way.

The tool schemas are the same story at a different altitude. Function calling conventions, argument serialisation, the way the model handles a missing field, the way it describes an error, all of these vary enough across model families that a tool layer written and debugged against one model produces silent failures on another. The retrieval and memory layer carries the same risk in a subtler form: the embeddings, the chunking, and the salience weighting were tuned to a model's notion of relevance, and a model with a different notion of relevance surfaces different chunks and changes the answer. Chapter 12Chapter 12 · 7 min LockedPortable Context: The Open Contract for AgentsContext is your IP — it must move across agents, models, and clouds through an open contract, not sit locked inside one runtime. on portable context exists precisely because this layer is where ownership is hardest to keep, and Chapter 23Chapter 23 · 5 min LockedOpen Formats, Open Interfaces, Open ThinkingWhy openness is a strategic moat. on open formats makes the same case for the interfaces between components.

So the migration cost of swapping the weights is not the cost of swapping the weights. It is the cost of re-fitting the prompt, the tools, the retrieval, and the evaluation to a model that reads them differently. Open weights removed the vendor from the inference bill and left every one of those seams exactly as binding as it was before. The door opened. The chains are one room over.

Run a simple experiment. Take the system prompt from your most-used agent and paste it, unchanged, into a different model family. Run the same five cases. The failure rate is usually a surprise, and the surprise is instructive. The prompt did not read as a set of instructions. It read as a set of instructions tuned to a particular listener, and the new listener misreads it in ways that are not bugs but dialect differences.

Instruction-tuned models disagree about tone, about how literally to take an imperative, about whether a numbered list is a constraint or a suggestion, about whether a rule restated three times is a rule or a nervous repetition. The prompt that holds a frontier model on task can let an open-weights model drift, not because the open model is weaker, but because the open model was not the listener the prompt was composed for. The cost of re-tuning the prompt is real engineering time, and it is time that has to be spent every time you migrate, because there is no prompt that is portable across model families the way a SQL query is portable across databases.

The teams that feel this least are the ones that never migrated, because they committed to one model early and have been optimising against it for a year. Their prompt is a year of fitting to one personality. Their illusion is that the prompt is a description of the task. It is not. It is a description of the task as understood by one specific model, and the description leaks the model's idiosyncrasies into every line. Chapter 4Chapter 4 · 7 min LockedThe 4 C's FrameworkA simple lens for designing trusted enterprise AI. frames meaning as the layer above retrieval, and the prompt is where meaning and model quirk are inseparably fused. That fusion is the lock-in nobody budgets for.

The tool-calling surface looks standardised, and the function-call JSON looks portable, and neither is true in the way that matters. The schema is portable. The behaviour around the schema is a dialect. One model fills optional fields reliably; another omits them silently and the downstream parser breaks. One model returns a structured error when a tool fails; another free-texts an apology into the return value and the agent loop treats it as success. One model respects a max-results constraint in the description; another ignores it unless it is repeated in the argument type. These are not edge cases. They are the everyday friction that turns a swap from a config change into a debugging week.

The practical consequence is that the tool layer accumulates model-specific workarounds the same way the prompt does. A guard clause that exists because model A mis-handles nulls. A retry wrapper that exists because model B occasionally returns the schema with an extra wrapper key. A normalisation step that exists because model C lowercases enum values. Each workaround is small and defensible in isolation. Together they are a body of code that is correct for one model and subtly wrong for every other, and nobody labelled any of it as model-specific, because at the time it was written it just looked like fixing a bug.

This is the seam that Chapter 29Chapter 29 · 6 min LockedCareer Roadmap for the Agentic EraLearning paths for beginners, intermediates, and senior professionals. on patterns and Chapter 34Chapter 34 · 7 min LockedDesigning Multi-Agent Systems That Actually WorkWhen one agent is not enough — and how to make many cooperate without chaos. on multi-agent design both touch, and the lesson generalises beyond tools. Any layer that sits between the model and the business logic will accumulate model-specific accommodations, and the only defence is to make those accommodations explicit, named, and isolated, so that a migration can find and re-test them rather than discovering them in production.

There is one asset that decides whether a model swap is survivable, and it is the one most teams treat as an afterthought. The evaluation set is the leash. It is the encoded statement of what good looks like in your business, and it is the only instrument that can tell you, before you commit, whether the new model is worse than the old one. Without a real eval set, a migration is a prayer. With one, it is a measurement.

The catch is that an eval set built against one model is itself a source of hidden binding. If the golden cases were chosen because they were the cases the old model got wrong, the set is biased toward the old model's failure modes and may flatter a new model that fails differently. If the rubric was written in the old model's idiom, a new model that answers correctly but in a different register may score poorly on a judge that expects the old register. The eval set has to be written against the task, not the model, and that discipline is rare, because the easiest way to build a golden set is to look at what the current model produces and label it. Chapter 35Chapter 35 · 11 min LockedRetrieval Mechanics: Chunking, Hybrid Search, and RerankingThe engineering layer under every context strategy — chunking, hybrid search, reranking, and how to prove it works. on retrieval mechanics and Chapter 36Chapter 36 · 10 min LockedCompaction and the Token BudgetBudget tokens like money, compact history without dropping commitments, and detect degradation before a user does. on compaction both depend on a model-agnostic eval loop, and the portability argument is the same argument from a different direction.

So the freedom to swap models is not granted by the licence on the weights. It is granted by the quality and model-neutrality of the eval set. The team that owns a model-agnostic golden set can try a new model on Friday morning and know by Friday afternoon whether it is safe. The team that owns only a prompt tuned to the old model is guessing, and the guess is usually optimistic until the first week of production traffic. The eval set is the asset that turns open weights from a symbolic gesture into an operational freedom, and it is the asset that is most often missing when a migration goes wrong.

The damage of mistaking open weights for freedom is not theoretical. It shows up as the migration that was budgeted as two weeks and consumed two quarters, because nobody costed the prompt re-tuning, the tool-layer debugging, and the eval-set rebuilding. It shows up as the team that chose a weaker open model for sovereignty reasons and then spent a year fitting their agent to its quirks, ending up more locked to that model than they would have been to a vendor they could at least pressure. And it shows up as the architecture that cannot use a better model when one appears, because the whole agent is a fitting of the old one.

There is a budget version of the same trap. A team decides that, because they own the weights, they do not need to invest in portability elsewhere. The eval set stays thin. The prompt stays model-specific. The tool layer accumulates workarounds. Then a model lands that is materially better on their task, and the cost of trying it is high enough that the team talks itself out of the experiment. Owning the weights made them feel free, and the feeling cost them the option to improve. Chapter 22Chapter 22 · 5 min LockedThe Danger of AI Lock-InHow yesterday's choices limit tomorrow's options. on the danger of lock-in and Chapter 24Chapter 24 · 5 min LockedBuild for ChangeDesigning for change you can't predict. on building for change make the case that the valuable kind of independence is the kind that survives a change you did not predict, and open weights buy you the cheaper kind.

The uncomfortable reading is that some teams that adopted open weights to escape vendor lock-in rebuilt the same lock-in one layer up, and did it more thoroughly, because there was no vendor to push back against. A vendor can be pressured, negotiated with, and replaced. A year of model-specific prompt fitting that nobody documented cannot. The cage did not disappear. It moved from the layer with the most migration tooling to the layer with the least.

Before committing to any model, open or closed, run the portability test on the agent you intend to build on it. The test is not whether you can run the model. It is whether you can replace it. If you cannot, you are about to build lock-in, and the licence on the weights will not save you from it.

Take the current system prompt and run it, unmodified, against one other model family, on the five most important cases. Measure the drop. If the drop is large, the prompt is a fitting, not a description, and the fitting is your switching cost made visible. The fix is not to make the prompt portable in the abstract. It is to separate the task description from the model accommodation, so that the part that says what to do survives a swap and the part that says how to say it to this model is isolated and re-tunable.

Do the same with the tool layer. Count the model-specific workarounds, the ones that exist because of how one model handles nulls, errors, or enums. Each one is a seam that will reopen on a swap. The fix is to name them, isolate them, and add a test case for each, so a migration re-validates them instead of inheriting them silently. And run the eval set against the alternate model. If the eval set only passes on the model it was built for, the eval set is part of the lock-in, and it needs to be rebuilt against the task before it can protect you.

This test costs a week and it is the single highest-leverage week in any agent programme, because it tells you the truth about your switching cost before you have spent a year deepening it. The teams that skip it are the teams that discover, at migration time, that the freedom they thought they bought was a freedom to run the model and nothing more.

Real freedom is not the absence of a vendor. It is the presence of a swap. A system you can migrate in a measured week, with an eval set that tells you the new model is not worse, is a free system, regardless of whether it runs on open weights or a paid API. A system you cannot migrate at all is a captive system, regardless of how sovereign the inference looks. The metric is not the licence. The metric is the measured cost of the next swap, and that cost is set by the layers above the weights.

The four clauses of a portable agent are simple to state and rare to find in the wild. The prompt separates task description from model accommodation. The tools are described in an open schema with model-specific workarounds isolated and tested. The eval set is written against the task and runs against any model. The context and memory live in a store you operate, in a shape you designed, as Chapter 12Chapter 12 · 7 min LockedPortable Context: The Open Contract for AgentsContext is your IP — it must move across agents, models, and clouds through an open contract, not sit locked inside one runtime. and the portability contract both insist. A team that satisfies those four clauses can treat the model, open or closed, as the line item it should be, and treat the layers above it as the asset they actually are.

Notice what is not on the list. Running your own hardware is not on the list. Choosing an open-weights model is not on the list. Both can be good decisions for other reasons, but neither is what makes you free. Freedom is a property of the seams, and the seams are where you do the work or do not. The vendor scorecard in the AI vendor scorecard essay turns the same clauses into questions for a buying decision, and the exit test turns them into a drill. Both work equally well against an open-weights model, which is the point.

If you are choosing a model this quarter, the question is not open versus closed. That question answers itself based on your sovereignty, latency, and cost constraints, and it is the easy question. The question that decides your freedom is whether you are about to build an agent that can be swapped, and that question is answered by the prompt, the tools, the evals, and the context store, none of which care about the licence on the weights.

Spend the week. Run the portability test on the agent you are about to commit to. The drop you measure is the switching cost you are about to sign up for, and it is the only number that tells you whether the freedom you are buying is real or symbolic. Then invest in the four clauses before you invest in more model. The model will improve on someone else's schedule. The portability of your agent is the one part of the system that improves only if you build it, and it is the part that compounds the longest, because every quarter of operation without it deepens the lock-in you will eventually have to pay to escape.

Open weights opened a door. Walk through it, but understand that the room on the other side has the same chains, and they are made of the work you do at the layers above the model. The teams that stay free are the teams that build those layers to be swappable, and they stay free whether their inference runs on a vendor's API or on their own GPUs. The weights were never the cage. The cage is the agent you built on top of them, and whether you built it to move.