Open and closed models

docs.scrimba.com

Underneath, a model is a large pile of trained weights (the numbers it learned during training) that predicts the next token. This chapter is about the two ways those weights reach you, closed models you rent through an API and open-weight models you can run yourself, and about where each one actually runs. The default everyone is pointed toward is a hosted closed model, and providers have little reason to highlight the alternatives, so it is worth knowing the full menu and when each part of it matters.

Open weights, closed weights

There are two ways you can get your hands on an AI model, and the difference comes down to where the model actually lives.

The first way is a closed model, sometimes called proprietary. You reach it only through the company's API, which is a kind of online doorway: you send in text, you get text back, and that is the whole arrangement. The model's weights, the giant pile of trained numbers that make it work, stay locked away on the company's servers. You are renting access, not owning anything.

The second way is an open-weight model. Here the company publishes those weights, so you can download your own copy and run it on hardware you control. Think of it as renting an apartment whose wiring you will never be allowed to see, versus owning a copy of the building's plans.

Most people start with a closed API because it is the easiest front door to walk through, and that is a fine place to begin. The open option is real and worth knowing about, so you understand that renting is a choice and not the only path.

JunoOpen weights, closed weights A closed model lives on the company's servers and you reach it through their API, so you are renting access. An open-weight model has its numbers published, so you can download a copy and run it yourself. Starting with a closed API is perfectly fine, but it helps to know the other door exists.

The whole distinction comes down to one question: who holds the weights? With a closed or proprietary model, the weights never leave the provider and you talk to the model only through an API. With an open-weight model, the weights are published under a license you can download and run wherever you want.

Be careful here, because "open-weight" is not the same as "open source." Almost every "open" LLM releases the trained weights but keeps back the training data and the training code, so you cannot fully reproduce the model from scratch. Some licenses also carry usage restrictions, things like a cap on the size of company that may use it commercially, or limits on allowed uses. Read the license before you commit; "open" is a spectrum, not a binary.

On capability, frontier closed models (the most capable models available at any given time) often lead the public benchmarks. But strong open-weight models are close enough for a large share of real tasks, and the gap keeps narrowing over time. The practical move is to not assume you need the absolute top model. Many jobs are served fine by an open one, and you find out by testing against your own task rather than a leaderboard.

JunoOpen weights, closed weights Closed means API-only with the weights staying at the provider; open-weight means published weights you can download and run. Open-weight is not open source, since the training data and code usually stay private and the license can restrict use, so read it. Frontier closed models lead benchmarks, but a strong open-weight model handles plenty of real work, so pick on the task.

What "open" actually buys you is control and the end of lock-in. You can pin the exact weights so the model never changes silently under you, inspect its behaviour, and run it anywhere you have hardware. That is a real advantage when reproducibility or data residency matters.

What it does not buy you is a free lunch. Open-weight almost always means weights-plus-license rather than open-source: no training data, often non-trivial license terms. So compliance and licensing review become actual work on your plate, and a permissive-sounding model can still restrict commercial use or redistribution in ways that surface late if you skip the reading.

The frontier capability gap is also real for the hardest tasks, even as it shrinks. So choose on the task in front of you, not on the label. For the bulk of routine work an open-weight model is plenty; for the edge of difficulty the closed frontier may still win.

The thing I have to keep reminding myself: treat "open" as a property of the weights and the license together, and read both. "I can download it" is not the same sentence as "I can do anything with it," and the gap between those two has bitten me before.

JunoOpen weights, closed weights Open weights buy you control and an escape from lock-in: pinned versions, inspectable behaviour, run-anywhere. They do not buy you open source, so budget for the license and compliance review, because a friendly-looking license can still bar commercial use. Choose on the task, not the label, and never read "I can download it" as "I can do anything with it."

Where the model runs

There is a belief floating around that picking an open model means you have to set up your own servers and run the thing yourself. That is not true, and it is worth clearing up early.

A model can run in one of two places. With a hosted model, some company runs it on their machines and you reach it over the web with an API call, which is a small request your code sends out and gets an answer back from. You never touch the computer it runs on. With self-hosting, you run the model yourself, on your own computer or your own server.

Here is the part people miss. An open model does not force you into self-hosting. You can use an open model through a hosting company the same comfortable way you use a closed one: you send a request, you get an answer, and someone else keeps the machine running. Self-hosting is an option you can take, not a rule you have to follow.

JunoWhere the model runs A model either runs on someone else's machine that you reach over the web, or on a machine you run yourself. Open models can go either way, so choosing one does not mean you suddenly have to manage servers. You can let a hosting company run an open model for you, exactly like you would a closed one.

It helps to drop the two-box mental model, because where a model runs is really a spectrum. At one end, a closed model called through its provider's API. In the middle, an open-weight model run for you by a third-party host. At the other end, an open-weight model you run yourself, which is self-hosting: you supply the machine and run the program that serves the model.

The reason moving along that spectrum is cheap: a widely adopted chat-message API shape has become a de-facto standard, and many open-model hosts and self-hosted servers expose that same shape. So switching providers is often mostly a change of base URL and model name rather than a rewrite (see calling models from code). Nothing you learn about calling a model is locked to one vendor.

At a glance, self-hosting means you provide the hardware (a capable GPU, or a rented GPU server) and run a serving program in front of the model. Treat that as real work you are signing up for. We stay at the decision level here and do not go deeper into the setup.

JunoWhere the model runs Think of a spectrum: closed via the provider, open via a third-party host, or open self-hosted. Because so many endpoints share one chat-message API shape, hopping between them is usually a base_url and model-name swap, not a rewrite. Self-hosting is the far end where you own the hardware and the serving, so reach for it on purpose, not by default.

Self-hosting is infrastructure, not a side quest. The moment you run the model yourself you own capacity planning, scaling under load, uptime, security patching, and model updates. "It runs on my laptop" is a demo; production is a different bill.

The middle path most teams skip is a managed open-model host. You get the open-model upside (lower cost than frontier closed, the ability to pin a specific model version, options for where your data sits, no single-vendor lock-in) without standing up GPUs yourself. The de-facto chat API shape is your insurance: keep your code to that interface and switching hosts, or pulling a model in-house later, stays a config change instead of a migration.

I have watched a "quick self-host" eat a quarter, so I reserve true self-hosting for when a specific pressure actually demands it: data residency rules, scale economics that flip in your favour, or a model you must control end to end. Absent one of those, managed open or hosted closed is the answer.

JunoWhere the model runs Running your own model means owning capacity, uptime, patching, and updates, so do not wander into it. The path teams overlook is a managed open-model host: open-model economics and control without the GPU babysitting. Code to the standard chat API and provider changes stay config, not migration. Save real self-hosting for a concrete reason like data residency, scale math, or hard model control.

When each one makes sense

Here is a simple way to hold the whole choice. A closed, hosted model is renting: there is nothing to set up, you get the best quality available, and you pay a little each time you use it. An open model that you run yourself is closer to owning: you get more control and more privacy, and there is no per-use bill going to a provider, but you take on the work of keeping it running.

Most people are right to start by renting through an API, and most never need anything more than that. Renting first is the normal, sensible path.

The point of this chapter was not that you should switch to running your own. It was only that you should know the choice is yours, so that if your needs change one day, you will recognise the option for what it is.

With a model chosen, the next question is how you talk to it. The next chapter, Prompting, is about steering whatever model you land on so it gives you what you actually want.

JunoWhen each one makes sense Think of it as renting versus owning: a hosted closed model is renting, an open model you run yourself is closer to owning. Renting through an API is the right place to start, and most people happily stay there. You now know the other door exists, which is the whole point. Next up is Prompting, where we learn to steer the model you picked.

When you actually have to choose, weigh the factors in roughly this order. First, capability: does a hosted frontier model earn its keep on this task, or is a strong open-weight model already good enough? Second, data sensitivity: can this data leave your boundary under a provider's terms, or does data residency (rules about where data is allowed to physically live and be processed) rule that out?

Third, the cost curve. A per-token API is cheap to start and stays cheap at low volume, but it can get expensive at steady high volume, which is where fixed-cost self-hosting can win. Fourth, control: do you need to pin exact behaviour across versions, or avoid being locked to one vendor?

The move is the same most of the time. Start with a hosted API, because it is the fastest path to something working. Then revisit only when a specific pressure actually shows up: cost at scale, a privacy or compliance requirement, or a real capability or control need.

Decide on evidence, not on defaults or ideology. Once your model is settled, Prompting is how you get reliable output from it.

JunoWhen each one makes sense Weigh four things in order: capability needed, data sensitivity, the cost curve, and control. Start on a hosted API because it gets you working fastest, then revisit only when a concrete pressure appears, like cost at high volume or a data residency rule. Switch on evidence, not on a hunch. Then head to Prompting to make whatever you picked behave.

The plain version. For most teams a hosted closed API is the correct default, and self-hosting an open-weight model is a cost-and-control decision, not a badge of seriousness. It pays off past a certain scale, or under a compliance or data-residency constraint, and not much before that.

So know roughly where the cost curve crosses for your volume, because that crossing point is the whole financial argument. Know what your data rules actually require, not what they vaguely feel like they require, which is where safety and limits and the question of what you send come in. And know that open weights are also what let you fine-tune freely on your own terms without asking a provider's permission (see fine-tuning). Avoiding vendor lock-in, being tied to one provider's prices, terms, and model lifecycle, is part of the same calculation.

The reason to learn all of this is not so you go and self-host. I have watched people stand up their own stack to prove a point and regret it by the second on-call week. It is that the default path is the hosted closed model, and the providers have little reason to point you at the alternatives, so an engineer who knows the full menu makes a deliberate choice instead of an inherited one.

With the model question handled on its merits, Prompting is where the day-to-day work of getting good output begins.

JunoWhen each one makes sense For most teams the hosted closed API is the right default, and self-hosting an open-weight model is a cost-and-control call that pays off past a certain scale or under a compliance constraint, not a personality trait. Know where your cost curve crosses, know what your data rules really demand, and remember open weights buy you free fine-tuning and an exit from vendor lock-in. I have seen the prove-a-point self-host, and the regret is real. Learn the full menu so you choose on purpose, then carry on to Prompting.