“Open weights versus closed APIs” gets debated like a moral question. For a normal builder, it isn’t one — it’s a practical trade-off with a pretty clear default answer. Let me save you the ideology and give you the version that actually helps you decide.
First, what the terms actually mean
Quick plain-English version. A closed API (think ChatGPT, Claude, Gemini) is a model you access over the internet — you send a request, you get an answer, someone else runs the infrastructure. Open weights (think many of the Chinese models, plus various open releases) means you can download the model itself and run it on your own hardware.
That single difference — who runs the machine — drives every trade-off that follows.
What closed APIs are great at
For most people, most of the time, closed APIs win, and it’s not close.
- Zero setup: sign up and you’re working in minutes. No servers, no GPUs, no DevOps.
- Top-tier capability and reliability: you get frontier models maintained by big teams, with uptime you don’t have to babysit.
- Support and safety: documentation, guardrails, and someone to call when things break.
The cost: you pay per use, your data goes to a third party (within their terms), and you’re subject to their pricing and policy changes. For a huge amount of work, that’s a perfectly fine trade.
What open weights are great at
Open weights shine when control is the priority.
- Data stays home: run it on your own infrastructure and sensitive data never leaves your environment — often the deciding factor in regulated or privacy-critical work.
- No lock-in: a model you host can’t be discontinued, deprecated, or price-hiked out from under you.
- Cost at scale: once you’re running very high volume, self-hosting can be cheaper per token than paying an API forever.
- Customization: you can fine-tune and modify it in ways a closed API won’t allow.
The honest default: start closed, earn open
Here’s my actual advice for normal builders. Start with a closed API. Only take on the complexity of self-hosting open weights when a real force pushes you there — genuine data-sensitivity requirements, or volume so high that API costs actually hurt.
Why? Because self-hosting is not free just because the weights are. You’re now responsible for hardware (often expensive, server-class GPUs), setup, scaling, security, and maintenance. That’s a real job. Taking it on before you need to is a great way to spend weeks on infrastructure instead of shipping your actual product.
You don’t have to choose just one
The false part of the debate is that it’s either/or. Mixing is not just allowed — it’s usually the smart move. Use a closed API for convenience and for your best-quality work, and reach for an open model when data must stay in-house or when cheap, high-volume grunt work makes it worth it.
The one rule: write your policy down. Which data goes where. Which model owns which job. Secrets and sensitive work local; everyday drafts on a hosted API. A written rule beats re-deciding under pressure every time.
The bottom line
Open versus closed isn’t a identity to adopt — it’s a decision to make per job. For most builders, closed APIs are the right starting point, open weights are the tool you graduate to when control or scale demands it, and a deliberate mix is where most serious operations end up. Pick by the job in front of you, not by which camp is loudest this week — and get back to building.
The three triggers to actually go open
Since “start closed, earn open” is the rule, here are the specific signals that mean you’ve earned it — self-host an open model only when at least one is clearly true. One: a compliance or data-residency requirement forbids sending your data to a third-party API. Two: your monthly API bill for a stable, high-volume task has grown large enough that hosting hardware would genuinely pay for itself. Three: you need to fine-tune or modify the model in ways a closed API won’t allow. If none is true, you’re paying in complexity for control you don’t need yet. Stay closed and keep shipping.
Are you running any open-weight models yourself yet, or still all-in on APIs? Tell me what pushed your decision in the comments.
