Every AI architecture discussion eventually arrives at the same fork: do we call a proprietary frontier model through an API, or run an open-weight model we control? The debate attracts zealots on both sides — 'never send data to a vendor' versus 'never run your own GPUs' — and both camps are selling a slogan, not a decision. The honest answer depends on constraints you can name: your volume, your data rules, your team, and your latency budget. Name them, and the choice mostly makes itself.
#The two doors, defined
Proprietary models — the frontier offerings from the major labs — are used through an API: you send a request, pay per token, and never touch the machinery. Open-weight models publish the trained model itself; you can download it, run it on your own hardware (or a host you choose), fine-tune it, and nobody meters your usage. 'Open' doesn't automatically mean free or fully open-source — licenses vary — but it means the weights are yours to run.
Proprietary (API)
- Frontier capability the day it launches
- Zero infrastructure — an API key and you're live
- Costs scale with usage: cheap to start, real money at volume
- Data leaves your walls under a contract
- You inherit vendor pricing, limits, and deprecations
Open-weight (self-hosted)
- Full control: your hardware, your rules, your data
- Flat-ish cost — can win big at high, steady volume
- Deep customization: fine-tune, distill, quantize
- You own the ops: GPUs, scaling, patching, on-call
- Capability trails the frontier, but the gap keeps closing
#When each side clearly wins
- Proprietary wins when capability is the bottleneck — complex reasoning, agentic work, anything where the best model visibly outperforms. And when you're early: proving value fast matters more than unit cost.
- Open weights win when data can't leave — regulated industries, sovereignty requirements, air-gapped environments where an external API is a non-starter.
- Open weights win at sustained scale — millions of similar calls a day on a narrow task can make self-hosting (or hosted open models) dramatically cheaper.
- Proprietary wins when your team is small — every hour spent managing GPU clusters is an hour not spent on your product.
- Open weights win on latency at the edge — on-device or on-premise inference beats a network round trip.
#The migration path that actually works
Prototype on a frontier API — eliminate capability risk first.
Cost at scale? Data residency? Latency? Customization? Be specific.
Run open-weight candidates on your test set — not on public benchmarks.
Route each workload to the cheapest model that passes its eval.
“Proprietary versus open isn't a religion — it's a procurement decision. Buy capability where you need it, own control where it pays, and keep the switch cheap enough that you can change your mind.”
Whatever you pick today, protect tomorrow: route all model calls through one abstraction layer, keep your prompts and eval suites in your own repo, and re-run the comparison a couple of times a year — the landscape shifts fast enough that last year's answer may be this year's overspend. The teams that treat model choice as a routing decision, not an identity, are the ones getting frontier quality and commodity prices at the same time.
