Two years ago, choosing an open-weight model over a closed frontier API meant accepting a visible quality drop. You did it to save money or to keep data on your own hardware, and you paid for it in worse outputs. That trade has quietly inverted for a large share of real-world tasks.

What "open-weight" actually means

First, a definition, because the loose use of "open source" muddies this. An open-weight model is one whose trained parameters you can download and run yourself. That is distinct from open-source in the strict sense — which would also include training code, data, and a permissive licence. Most of the well-known downloadable models are open-weight but not fully open-source: you get the weights and a licence with conditions, not the recipe. For practical deployment, weights are what matter. You can run them on your own GPUs, fine-tune them, quantise them, and ship them inside a product without a per-token bill to anyone.

The gap closed where the volume is

The headline benchmarks still favour the closed frontier labs on the hardest tasks. But headline benchmarks are a poor proxy for the work most teams actually run. The overwhelming majority of production LLM calls are not frontier-grade reasoning problems. They are:

• Summarising a document or a thread.
• Extracting structured fields from messy text.
• Classifying, routing, and tagging.
• Drafting routine copy.
• Straightforward code generation and transformation.

For all of these, a strong mid-sized open-weight model in the 8B–70B range is, in blind use, hard to distinguish from a frontier API. The capability surplus of the closed models is real but it is spent on tasks that are a minority of call volume. If 80% of your traffic is comfortably handled by a model you can run for the cost of electricity, the economics change completely.

Where closed models still win

Be honest about the gap, because pretending it's gone leads to bad architecture decisions. Closed frontier systems still lead on:

• Long-horizon agentic tasks — multi-step plans where small errors compound across many tool calls.
• Hard reasoning — competition maths, intricate multi-constraint problems, subtle code debugging across large contexts.
• Robustness under adversarial or unusual input, where the frontier models degrade more gracefully.

If your product lives or dies on the hardest 5% of tasks, the frontier API is still the right call, and the price is worth it. The mistake is routing all traffic there because of that 5%.

The decision moved up the stack

The interesting consequence is that model choice is no longer primarily a capability decision. It's a deployment decision, and the variables are:

Data control. If you cannot send data to a third-party API for regulatory, contractual, or competitive reasons, an open-weight model running in your own environment isn't a compromise — it's the only viable option, and now it's a good one.

Cost shape. API pricing is variable cost that scales linearly with usage. Self-hosting is largely fixed cost. At low volume, APIs win. Past a crossover point — which arrives sooner every year as open models improve — owning the inference is cheaper and the cost is predictable.

Fine-tuning freedom. You can fully fine-tune an open-weight model on your own data and own the result. With closed APIs you get constrained adaptation at best.

Latency and availability. Local inference removes a network hop and a dependency on someone else's uptime and rate limits.

The pragmatic architecture: route, don't pick

The teams getting the most out of this don't choose one model. They route. A cheap, fast open-weight model handles the high-volume easy traffic; a frontier API is held in reserve for the genuinely hard requests, triggered by a classifier or a confidence check. This model-routing pattern captures most of the cost savings of open weights while keeping the frontier as a safety net for the tail of hard cases.

What to watch

The trend line is clear: each generation of open-weight releases lands closer to the closed frontier, and the lag between a frontier capability appearing and an open-weight equivalent shipping keeps shrinking. The strategic question for any team building on LLMs is no longer "can the open model do it?" but "at what point does owning my inference beat renting it?" For more workloads every month, that point has already passed.