The open-versus-closed debate in AI attracts a lot of ideology and very little arithmetic. One side treats open weights as a moral position. The other treats frontier closed models as self-evidently correct. Both framings are useless if you are trying to decide what to actually run next quarter.

Here is the practical version: what the distinction really means, the four dimensions where it matters, and the specific situations where each choice is right.

What the terms actually mean

Closed models are accessible only through the provider’s API or application. You send input, you get output, you never touch the weights. The provider controls capability, pricing, availability, and deprecation.

Open-weight models publish their trained parameters for download. You can run them on your own hardware or through any provider that hosts them. You control deployment, and in most cases you can fine-tune.

One clarification worth making, because it causes constant confusion: open-weight is not the same as open-source. Most “open” models publish weights under a licence with restrictions — commercial-use limits, acceptable-use clauses, or attribution requirements — while withholding training data and training code. That is meaningfully different from open-source software, and the licence text matters if you are building a product on top.

The four dimensions that decide it

1. Capability

Frontier closed models still lead on the hardest reasoning, maths, and coding tasks. The gap has narrowed considerably — open-weight models now handle the large middle of everyday work perfectly well — but at the top end it remains real.

The question is not “which is better in the abstract” but “is the gap material for my tasks”. For summarisation, extraction, classification, drafting, and routine code, frequently it is not. For novel architectural reasoning or hard multi-step problems, frequently it is.

Check the current position rather than assuming, because it moves every few months. Side-by-side comparison tools that put open and closed models on the same benchmark axes make the gap concrete rather than rhetorical — and reading it yourself is more reliable than reading either camp’s summary of it.

2. Cost

The cost comparison is frequently misunderstood in both directions.

Closed models cost per token, with zero fixed cost. Cheap at low volume, expensive at scale, entirely predictable per unit.

Open-weight models are free to licence and expensive to serve. Self-hosting means GPU capacity, engineering time, and utilisation risk. Rented inference from a hosting provider sits between the two: no infrastructure, per-token rates typically well below frontier closed models.

The break-even for genuine self-hosting is higher than enthusiasm suggests. You need enough sustained volume to keep expensive hardware busy, plus staff who can operate it. Below that, you are paying for idle GPUs and someone’s weekends. Most teams that “should self-host” are actually better served by rented open-weight inference, which captures most of the cost advantage with none of the operational burden.

3. Control and data residency

This is the dimension where open weights win decisively, and it is often the real reason rather than cost.

Running a model on infrastructure you control means:

• Data never leaves your boundary
• No dependency on a provider’s retention policy
• No deprecation risk — the weights you have keep working
• Fine-tuning on proprietary data without sending it anywhere

For regulated industries, for jurisdictions with strict residency requirements, and for anyone whose customer contracts prohibit third-party processing, this is not a preference. It is a requirement, and it settles the question before cost enters the discussion.

4. Operational burden

Closed models have effectively none. You call an API.

Open-weight self-hosting has a lot: capacity planning, model updates, monitoring, scaling, security patching, and someone on call. This is the cost that gets omitted from comparisons most often, and it is the one that sinks the most projects.

Rented open-weight inference splits the difference — you get open weights without operating them, at the price of trusting another provider.

The decision, by situation

You are a small team with mixed general-purpose work. Closed models, or a multi-model platform. Volume is too low for self-hosting to pay, and capability breadth matters more than unit cost. Do not build infrastructure for a problem you do not have.

You process regulated or contractually restricted data. Open-weight, self-hosted, or a provider with contractual guarantees that actually satisfy your obligations. Cost is secondary; compliance is not negotiable.

You have high, steady volume on a narrow task. Open-weight rented inference, possibly fine-tuned. This is the clearest economic case: a smaller specialised model often matches a frontier model on one narrow task at a fraction of the cost.

You need frontier reasoning on hard problems. Closed frontier models, for now. The gap at the top is real.

You are not sure yet. Start closed, measure, then move the high-volume portions to open-weight once you know where your volume actually is. Building infrastructure before you have measured is the expensive order to do it in.

The hybrid pattern most teams land on

In practice, mature setups are rarely all-one-thing. The common architecture:

• Frontier closed model for hard reasoning, complex code, and anything customer-visible
• Open-weight model for high-volume bulk work — classification, extraction, tagging, first-pass drafting
• Open-weight self-hosted for anything touching restricted data
• A cross-lab fallback so no single provider outage stops work

This captures most of the cost advantage where volume is high, keeps capability where it matters, and satisfies compliance where it applies.

The obstacle to running a hybrid used to be access — separate accounts, separate credentials, separate bills for each category. Multi-model platforms such as Perspective AI reduce that by putting both open-weight and closed models behind a single account and a shared allowance, which makes moving a workload from one to the other a configuration change rather than a procurement cycle. That matters mainly because it lets you test the hybrid before committing to it.

What to actually test before deciding

Do not decide from benchmarks. Run a comparison on your own work.

1. Take twenty real tasks from the workload you are considering moving.
2. Run them through one frontier closed model and one strong open-weight model, same prompts, no per-model tuning.
3. Score for accuracy, format compliance, and refusal behaviour — not for vibe.
4. Calculate cost per task for each, at your realistic monthly volume.
5. Add the operational cost honestly if self-hosting is on the table: engineering hours at real salary cost, not at zero.

Teams that run this exercise usually find one of two things. Either the open-weight model handles 80% of tasks at a fraction of the cost, which makes the hybrid obvious. Or the quality gap on their specific work is larger than expected, which makes staying closed obvious. Either result is worth an afternoon.

What people get wrong

“Open-weight means free.” The licence is free. Inference is not. GPU time, engineering time, and idle capacity are all real costs, and the last one is the one people forget.

“Closed models are more secure.” Different, not more. Closed means trusting a provider’s controls and retention terms. Open self-hosted means trusting your own. Which is safer depends entirely on which team is better at security, and that is an honest question with an uncomfortable answer in many organisations.

“Open-weight models are far behind.” They were. The gap on everyday work is now small enough that for most tasks it is not the deciding factor. It persists at the frontier.

“You have to pick one.” You do not, and most teams that are happy with their setup did not.

Frequently asked questions

Is open-weight the same as open-source? No. Open-weight means downloadable parameters, usually under a restrictive licence, typically without training data or code. Open-source implies far broader rights. Read the licence before building a product on it.

When does self-hosting an LLM become cheaper? When sustained volume is high enough to keep dedicated hardware well utilised, and you already have the operations capability. Below that threshold, rented inference is almost always cheaper once staff time is counted honestly.

Can open-weight models be fine-tuned on proprietary data? Yes, and this is one of their strongest advantages — the data never leaves your environment. Fine-tuning closed models is possible with some providers but sends your data to them.

Which is better for regulated industries? Open-weight self-hosted, generally, because data residency and processing control are provable rather than contractual. Some closed providers offer terms that satisfy specific regimes — check against your actual obligations rather than a generic claim.

The framing that helps

Stop asking which is better. Ask which dimension is binding for you: capability, cost, control, or operational burden.

For most teams the binding constraint is capability at the top end and cost at the bottom, which is exactly why the hybrid keeps winning. Measure your own workload, split it at the line where quality stops mattering more than price, and route accordingly.