A team building a support chatbot picks a closed model’s API, ships the integration in an afternoon, and never once thinks about GPU memory, quantization tiers, or whether a graphics card can hold the weights. Six months later the provider announces that the exact model version the product was built on will stop responding to requests in thirty days, replaced by a newer one with slightly different behavior on the prompts that took weeks to tune. Nobody on the team asked for this migration. Nobody on the team can stop it. The bill for skipping the hardware problem entirely comes due later, and it comes due on somebody else’s calendar.

What you no longer manage

This is the real and considerable upside, so it is worth stating plainly. There is no GPU to buy, no VRAM tier to plan around, no quantization tradeoff to weigh, no server to patch, no inference engine to configure, no capacity planning for traffic spikes. A request goes out over the network and an answer comes back. The provider is handling racks of hardware, cooling, redundancy, and model updates behind an interface that looks the same on a slow Tuesday and a record-traffic Friday. For a small team without infrastructure staff, this is often the only realistic way to use a frontier-capability model at all. The piece on hardware for open models covers the version of this problem that closed models remove entirely: the question of what a given machine can actually hold in memory. With a closed model, that question simply does not arise.

What you take on instead

Removing a problem does not make it disappear, it moves it to someone else’s desk, and their priorities are not the same as yours. Uptime is the most immediate form of this: if the provider’s service degrades or goes down, there is no local fallback, because there is no local anything. The product’s roadmap is no longer fully yours either, since the provider decides which capabilities get added, which get deprecated, and on what timeline, and a business built around a particular quirk of a particular model version can find that quirk gone in the next release. Pricing sits outside your control in the same way: a per-token rate that made a feature profitable can change with a pricing update, and there is no lower tier to fall back to except a different provider entirely. Usage policies add another layer, since the provider can restrict what the model may be used for, and a use case that was acceptable at signup can become a policy violation after a quiet terms update. Underneath all of this sits the data question: every request carries some version of your users’ input through a third party’s servers, subject to that party’s retention practices and security posture, not yours.

The mirror of the same tradeoff

Think of it the way a car owner and a ride-hailing rider face the same need to get somewhere, but carry entirely different risks. The owner deals with oil changes, tire wear, and a driveway that has to fit the thing. The rider deals with none of that, right up until the app raises its prices during a storm, changes its service area, or simply has no cars available at the moment one is needed, and there is no garage to walk into instead. Neither arrangement is free of cost. Open source hands you a hardware problem: real, upfront, and yours to size. Closed models hand you a sovereignty problem instead: quieter, deferred, and someone else’s to resolve on their schedule. There is no cost-free choice between the two, only a choice of which specific headache you would rather carry, and the closing piece of this sub-series goes further into a sharper version of that risk, the case when that dependence stops being hypothetical and the model you depend on is switched off entirely for reasons that have nothing to do with how you used it.