Who holds the weights decides who holds the leverage.
Serving an open-weights model you control and calling a hosted proprietary API are different operating models, not just different price points. The trade-off is convenience against control — over data, versions, cost curve and exit.
Hosted APIs are the faster path to a first working prototype. Open weights win when data residency is a hard requirement, when a pinned, reproducible model version matters, or when volume is high enough that per-token pricing dominates your costs. Prototyping on an API and moving to open weights once the shape of the problem is clear is a reasonable sequence.
| Dimension | Open Weights | Hosted API |
|---|---|---|
| Where data goes | Your infrastructure | The provider's infrastructure |
| Version stability | Pinned by hash; changes only when you change it | Provider may deprecate or update the model |
| Cost shape | Fixed compute cost you provision | Per-token, scales with usage |
| Time to first result | Slower — you own the serving stack | Fast — an API key and a request |
| Fine-tuning control | Any method, any layer, full checkpoints | Whatever the provider exposes |
| Air-gapped deployment | Supported | Not possible |
| Operational burden | You run inference, scaling and upgrades | Provider runs it |
| Reproducibility | Same weights produce the same result later | Hard to guarantee across model updates |
No. Below a certain volume, a hosted API is cheaper because you are not paying for idle capacity. The crossover depends on your traffic pattern — bursty low volume favours APIs.
That you can download and run the parameters. It is not the same as open-source training data or an unrestricted licence — always read the specific model licence for commercial terms.
Migrating prompts is easy; migrating fine-tuned behaviour is not, because a provider-hosted fine-tune generally cannot be exported. That asymmetry is worth weighing before you invest heavily in a hosted fine-tune.