A closed model is one you rent through an API. The model lives on the provider's machines, you send your text over the wire, and the answer comes back the same way. You never touch the model itself. You buy its output, the way you buy electricity without owning the plant.
What renting buys you is strength. The closed frontier models are usually the strongest available, and through an API you get that capability almost immediately: no hardware, no hosting, no specialist team, and improvements arriving without you lifting anything. For the hardest tasks, the ones where quality is the difference between useful and useless, the frontier is often simply where the answer is.
The price is the other half of the trade: your data makes a round trip through someone else's building, and you live inside someone else's terms, pricing, and roadmap. None of that is disqualifying. It is a dependency, and dependencies deserve to be weighed in the open, not discovered later. The twin page, open models, is the argument for keeping everything in your own custody.
For an operator, closed models are usually the right way to start and often the right way to stay: prototype on rented frontier strength, learn what the job actually requires, and move specific workloads to an open model only when custody or cost demands it. A concrete example: a team building a document drafting assistant starts on a closed frontier model and finds out within days whether the idea clears the quality bar that matters. That speed to an honest answer is what the rent is for.
“Do we actually need frontier quality here, or is an open model on our own hardware the safer call?”
// this page is the full text. the packaged PDF, all fifteen terms, comes with the free library.