The old framing was "open is a year behind." That stopped being true in 2025 and is actively misleading in 2026. The real question now is which workloads genuinely need a closed frontier model, and which ones you're paying a premium for out of habit. Here's the scorecard as I see it, from someone who ships on both.
The gap, honestly measured
On raw capability benchmarks, the best proprietary models still hold a real but narrow lead on the nastiest reasoning and long-horizon agentic tasks. DeepSeek, Qwen, Llama and a string of strong open families have closed most of the everyday gap: summarization, extraction, code on typical repos, RAG over private corpora, tool use with sane schemas. If your workload is "smart autocomplete with tools," open handles it. If it's "open-ended autonomous research agent running for six hours," the frontier still earns its premium — usually.
Benchmarks flatter both sides, so trust your own evals on your own data. That's the only scorecard that predicts production behavior.
Where open clearly wins
- Cost at volume. Self-hosted or through cheap inference providers, open models undercut proprietary APIs decisively once you're past trivial scale.
- Data control. Nothing leaves your perimeter. For health, legal and finance workloads, that's often non-negotiable.
- Customization. Fine-tune, quantize, distill, prune. Proprietary APIs offer knobs; open weights offer surgery.
- No deprecation shock. Your model doesn't get retired on a vendor's schedule with two weeks' notice.
- Auditability. Weights you can inspect beat a black box when a regulator asks questions.
Where proprietary still wins
- Frontier reasoning and hard agents. The last 10% of capability, on the hardest tasks, still lives behind closed APIs.
- Multimodality at the edge. Video understanding and the wildest vision tasks skew closed, though open is catching up fast.
- Zero ops. No GPUs to babysit, no quantization tuning, no upgrade treadmill. Time-to-first-token in minutes, not sprints.
- Support and SLAs. When production breaks at 2 a.m., someone answers the phone. That's worth real money to some teams.
- Safety tooling. Content filtering, monitoring and red-teaming wrapped around the API save genuine work.
Benchmarks you should actually trust
Public leaderboards are marketing now. The ones worth your attention measure real workloads: SWE-bench-style software engineering, long-document reasoning over your actual corpus, agentic tool-use suites with real failure modes, and latency under load. Build a small golden set of fifty to a hundred examples from your own production traces, keep it private, version it, and re-run it on every candidate model. It costs a weekend to set up and saves quarters of arguing from vibes. Also track the boring metrics — JSON parse rate, tool-call accuracy, refusal rate, p95 latency — because a model that's clever but flaky at structure will quietly wreck an agent pipeline.
The total cost conversation with your board
If you report AI spend to leadership, bring TCO not per-token prices. Per-token pricing across providers is nearly meaningless now: caching, batch discounts, committed-use deals and open-model hosting cloud all muddy the sticker numbers. The honest comparison is cost per completed task at your actual quality bar. A cheap model that needs three retries and a human supervisor loses to a pricier model that finishes first time. Put it in the memo that way and the open-versus-proprietary argument stops being ideological and starts being arithmetic.
The hybrid is the grown-up answer
Most serious stacks I see in 2026 route by task. Open model for the high-volume, well-understood 80% — classification, extraction, draft generation, first-pass code. Proprietary frontier for the hard 20% and for tasks where vendor SLAs matter. A router with a cost budget and eval gates decides, and the whole thing is swappable. This isn't fence-sitting; it's how you keep leverage in a market where prices and quality reshuffle every quarter.
Licensing landmines
Open doesn't mean one thing. MIT and Apache-2.0 weights (much of the DeepSeek and early Llama lineage) are permissive. Some licenses cap monthly active users or require acceptable-use riders. Some "open" releases ship without training data or full recipes — open weights, not open source, and that distinction matters if you care about reproducibility. Read the license before the model card impresses you. Also note the EU AI Act treats genuinely open models somewhat more leniently in places, which is a nice nudge toward permissive releases.
What the open ecosystem actually looks like now
Pretending "open source" is one thing is how teams make bad decisions. There are at least three distinct open worlds in 2026, and they behave differently. There's permissive open-weights: DeepSeek, Qwen and Llama derivatives you can commercialize with minimal fuss. There's research-grade open: weights released with caveats, limited context, or acceptable-use strings attached. And there's ecosystem open: the forks, quantizations, LoRA adapters and llama.cpp-class runtimes that make this stuff usable on a laptop. Evaluate the license, the community, and the tooling together — a brilliant model with a dead ecosystem is a liability, while a good model with vLLM support, GGUF builds and active fine-tuning recipes ships product faster than it should.
Fine-tuning is having its moment
Proprietary APIs gate fine-tuning behind enterprise tiers, long queues and per-epoch fees. Open weights let you fine-tune tonight for the price of electricity — QLoRA on a single beefy GPU gets you 80% of the value for 5% of the spend. The teams getting real mileage are fine-tuning narrow, high-volume tasks: ticket routing, extraction formats, domain jargon. The teams wasting money are trying to teach a small model general intelligence. Fine-tune behavior, not knowledge. If you need fresh facts, pair the model with retrieval; fine-tuning is for style, format and task shape.
The hidden costs of self-hosting
I've painted open as nearly all upside, which isn't fair. Self-hosting brings a spreadsheet of costs the API hides: GPU spend even when idle, version upgrades every quarter, quantization regressions you only notice in production, eval drift, on-call for the inference fleet, and security patching of the serving stack itself. Cheap tokens stop being cheap if your best engineer spends Fridays chasing OOM kills. Honest accounting: if your inference volume is small, proprietary wins on total cost; cross a few hundred million tokens a month, open starts to dominate; at billions, it's not close.
One more nuance the scorecard can't show: reliability out of the box. Proprietary APIs give you tempered, well-instrumented defaults — safety filters, structured-output modes, monitoring. Raw open weights demand you build that layer yourself, and many teams underestimate it by weeks. The good news is the open tooling for guardrails and structured generation is now genuinely decent. The bad news is "genuinely decent" is still you doing the work. Budget for it honestly and open wins on value; pretend it's free and proprietary wins on total effort.
A field note on migration pain
Switching between open models is easier than people fear but not free. Tokenizer differences ripple into prompt design, chat templates vary, context-window behavior diverges under long prompts, and quantized builds quietly regress on niche reasoning. Budget a week per model swap with your eval suite as the gate. The payoff is real: teams that treat model choice as a quarterly, low-drama operation adapt to price and quality shifts while their competitors are still locked into last year's flagship pricing. Portability isn't a philosophy; it's a discount you collect every quarter.
Safety fine print worth reading
Open models ship with safety baked in to wildly varying degrees. Some have rigorous refusal training and model-card documentation; others are effectively raw completion engines with a responsible-use rider taped to the box. Neither is automatically right — it depends on your deployment context. But if your product touches minors, medical advice or high-stakes decisions, "the model said yes" is not an acceptable governance answer. You own the system prompt, the output filters, the escalation path and the logs. Choosing open means accepting that responsibility deliberately, not inheriting it by accident. Done well, it's a feature: your safety posture is yours to inspect, tune and prove, not a vendor's marketing page.
Questions to ask before you sign either way
Whether you land on open, proprietary or a blend, the contract questions are depressingly similar. For an API vendor: what the price trajectory actually looks like after the committed-use term, what happens to your data retention and deletion obligations, which model versions your prompts may be served on, and how much notice you get before a deprecation. For an open-weights self-hosting decision, the mirror versions: what the total GPU and ops bill looks like at twice your current volume, who owns the on-call rotation, what the exit plan is if the flagship checkpoint's license shifts, and what your regression eval catches when you swap versions.
One question worth asking both sides: "show me your eval harnesses." Vendors who answer with a marketing benchmark haven't measured anything; vendors who answer with golden sets and regression thresholds have. Internally, there's a sibling question — "what will this cost us to undo?" If reversing the decision in six months is a config change, take the risk. If it's a rewrite, you've married the thing, so do the homework first. The scorecard in this post ages quickly; the discipline of asking these questions doesn't.
The scorecard
Rough grades, opinionated: cost — open, A; proprietary, C. Frontier capability — proprietary, A; open, B+ and climbing. Privacy and on-prem — open, A; proprietary, B- (enterprise tiers help). Ops burden — proprietary, A; open, C+ (improving with better tooling). Customizability — open, A; proprietary, C. Vendor risk — open, A- (community can fork, though maintainers burn out); proprietary, C+ (deprecation and price hikes happen).
And one closing truth nobody puts on a slide: the best model for your product is the one your team can operate, debug and explain at 3 a.m. Capability curves don't care about your on-call rotation, but your customers do.
And when you write the memo recommending one side or the other, expect to be wrong about specific models within six months. What survives is the process: private golden set, quarterly review, routing layer, clean rollback plan. Pick your ideology freely — just don't let it make your architecture decisions for you.
What I'd pick, today
Default to open for anything commoditized and sensitive, proprietary for anything genuinely at the frontier or genuinely worth zero-ops pricing. Never marry either — route, measure, and keep both warm. The 2026 winner isn't a side; it's the team that designed for portability and can switch models without rewriting their product when the next six months of releases land. They will land.