On a Tuesday, someone asks a chatbot to summarize a contract clause and gets a terse, three-line answer. On the following Friday, they ask the same question again, worded almost identically, and get four paragraphs with a different tone, a different structure, and a slightly different reading of the clause. Nothing about their account changed. What changed, invisibly, is that an internal router sent the first request to one model variant and the second to another, and the person asking has no way to know that happened. That is what it means to use a closed model: you are not talking to a fixed thing, you are talking to a service, and the service can shift under you between two questions asked four days apart.

no weights, only an api

With an open-weight model, whatever else is hidden, you can download a file, load it into memory, and run it yourself. There is a concrete artifact: a set of parameters you can point to, version, and keep running exactly as it was, forever, on your own hardware if you choose. A closed model offers none of that. There is no file to download, because none is released. What you get is an endpoint: send text in, get text out, billed per token. You never touch a copy of the model, and you never can, because the entire product is designed so that the model stays on the provider’s servers at all times. You don’t know the parameter count, beyond whatever marketing figure the company chooses to publish or imply. You don’t know the training data, which is true of open-weight models too, but here the opacity goes further: you don’t know the architecture, the context window implementation, or the exact set of safety filters sitting between your prompt and the raw model. All of it is behind the API, and the API is the only thing you’re actually renting.

the version you can’t pin down

The deeper problem is that “the model” is not even a single stable thing on the other end of that API. Providers increasingly route requests through an internal system that picks among several variants of a model depending on load, cost, query type, or A/B tests running that week. Two calls with the same model name in the request can be answered by different underlying weights, and the provider is under no obligation to tell you when that happens. New versions roll out gradually too: a capability that appears in a colleague’s session on Monday might not reach yours until Thursday, or might never reach it if you’re on an older API tier. There is no changelog you can check before sending a prompt, no version pin that guarantees identical behavior tomorrow to what you got today. You are calling a name, not a fixed artifact, and the name can point to something subtly different every time you use it.

a service that updates without asking

This is close to what happens when an app updates itself overnight without asking you first. You sign in the next morning and the layout has moved, a button you relied on now does something else, and a feature you built a habit around behaves differently, all without any notice that an update happened at all. A closed model works the same way, except the update can touch not just the interface but the actual judgment behind every answer, and there is rarely even a changelog to explain what shifted. With an open model, as Open Source vs Open Weight lays out, you don’t know what it was trained on, but at least the weights you’re running today are the weights you’ll be running next month, unchanged, because you hold the file. With a closed model you don’t even have that. You don’t know how big it is, you don’t know exactly which variant answered your last request, and you don’t know when the version underneath you will change, only that at some point, quietly, it will. The next piece in this series looks at what that arrangement costs beyond the invoice: what you take on in exchange for not managing any of it yourself.