Open-source LLMs caught up. The question now is which fits your constraints, not which is smarter.

For most of the past three years, "use the frontier closed model" was a defensible default. The gap was big enough that the cost premium was easy to justify — open-weight models lagged by enough that the engineering time spent compensating outweighed the savings. In 2026, that's no longer true. The gap closed dramatically through 2024 and 2025 and has stabilized at single-digit-percentage differences on most benchmarks that matter for production work.

That changes the decision. The question is no longer "which model is smarter," because for most tasks, the answer is "both are smart enough." The question is now: which fits your latency budget, your per-call cost target, your data privacy posture, and your engineering team's capacity to operate inference infrastructure. This post walks through how to make that call without being talked into the wrong tier by either side of the marketing.

The Landscape: What "Open" Actually Means in 2026

The open-weight LLM ecosystem in 2026 is dominated by five model families that are worth knowing in practical detail:

"Open" here doesn't mean a single thing. Apache 2.0 (Qwen, Mistral Large 3) and MIT (DeepSeek, GLM-5) are unambiguously permissive — you can use them commercially, modify them, redistribute fine-tunes, no licensing call to legal needed. The Meta Llama license is more restrictive: there's a 700M monthly active users threshold above which you need to negotiate separately with Meta, plus some use-case restrictions. For most companies the 700M MAU threshold is hypothetical, but enterprise legal teams will flag it, and if license cleanliness matters in your org, default to Apache or MIT.

The frontier closed models — Claude Opus, GPT-5, Gemini 3 — still hold a meaningful lead on the hardest work: long-horizon agentic coding (multi-file, multi-step refactors), novel reasoning problems that don't pattern-match to training data, the most multi-modal capability (audio, video, complex vision). That lead is likely to persist as long as those labs have meaningfully more training compute. For most production use cases, you don't need that frontier — and paying for it without using it is the most common over-spend in LLM budgets.

The Decision Tree

Here's the practical decision framework. Walk it top-down for any new use case.

1. Is your data subject to a hard "cannot leave VPC" constraint?

If yes — regulated data (defense, certain healthcare workflows, classified or contractually-locked customer data) — you self-host an open-weight model. The frontier closed APIs all offer enterprise zero-data-retention tiers that are sufficient for most regulated industries, but if the constraint is "the data literally cannot leave our network boundary," self-hosting an open model is the only path. Pick Qwen 3 or Mistral Large 3 for general work, GLM-5 for code, DeepSeek V4 for cost-sensitive volume.

If no, continue.

2. Is the workload at the absolute frontier of capability?

If yes — multi-hour agentic coding on a real production codebase, novel scientific reasoning, complex multi-modal work — the frontier closed models still lead. Claude Opus 4.7 has been the standard for multi-file coding agents; GPT-5 leads on terminal automation and complex tool use; Gemini 3 leads on certain reasoning and multi-modal benchmarks. The price premium (typically 4–10x over a hosted open model) is justified here because the task either requires frontier capability or has a high cost per failure.

If no — and most production workloads are not at this frontier — continue.

3. Is per-token cost the dominant constraint?

If yes (high-volume RAG, classification, structured extraction, customer-facing chat with millions of monthly turns), a hosted open-weight model API is almost always the right answer. Together, Fireworks, Anyscale, Replicate, and Groq all offer Qwen, DeepSeek, GLM, Mistral, and Llama at meaningful discount to frontier closed APIs. DeepSeek V4 Flash is the typical default for cost-sensitive default-pick workloads in 2026.

If no, continue.

4. Is license cleanliness a hard requirement?

If yes — enterprise legal will not approve anything with use-case restrictions or scale-based clauses — restrict your open-weight options to Apache 2.0 (Qwen 3, Mistral Large 3) or MIT (DeepSeek, GLM-5). Skip Llama and skip any model with a research-only or non-commercial clause.

If no, continue.

5. Do you have meaningful inference operations capacity?

If yes — a platform team that already runs GPU-backed services, has experience with vLLM or TensorRT-LLM, can on-call for inference outages — self-hosting becomes economically attractive once volume crosses the point where hosted API costs exceed your fully-loaded GPU costs. For most teams, this crossover is higher than they expect: the hosted providers are aggregating demand across many customers and running near 100% GPU utilization, which is hard to match in single-tenant deployment.

If no — and most teams below significant scale should answer no — stick with hosted APIs (either frontier closed or hosted open-weight, per the decision above). The hosted open-weight providers will be cheaper and faster than running the same model yourself, because you're sharing GPU capacity rather than paying for idle time.

The Cost Comparison That Actually Matters

List prices are misleading. The real cost comparison is total cost on your task, which includes:

• Per-token price — the headline number. Open-weight via hosted providers typically runs 4–10× cheaper than frontier closed APIs.
• Effective failure rate on your task — if the open model fails 3% more often and you have to retry, the per-successful-call cost converges. Build evals before deciding.
• Latency at your traffic profile — open-weight hosted providers can have higher tail latency at peak times if capacity isn't co-located with your inference traffic.
• Engineering time — every time you swap models, evals need updating, prompts need re-tuning, fallback logic needs maintenance. Engineering time is the most under-priced cost line.
• Switching cost — if a frontier closed model gets dramatically better in 6 months, can you switch back without a rewrite? Designing for portability has a real cost up front.

Hybrid Patterns Are the Common Production Setup

Most production LLM applications in 2026 aren't pure-open or pure-closed — they're hybrid, routing by task. A typical pattern:

• Default tier: hosted open-weight model (Qwen 3 or DeepSeek V4) for the 90%+ of traffic that's routine RAG, classification, summarization, or first-pass extraction.
• Premium tier: frontier closed model (Claude, GPT, Gemini) for the user-facing interactive features, the agentic workflows, and the cases where capability genuinely matters.
• Specialized tier: a domain-fine-tuned open model for narrow high-volume tasks where you have enough labeled data to outperform a generalist (typically tens of thousands of examples).
• Router layer: a small classifier or simple LLM call that decides which tier to use per request, so you don't pay frontier prices for routine work.

The platform tooling for this routing has matured a lot. Vercel's AI Gateway and similar provider-agnostic gateways let you swap models with a config change rather than a code change, which is a precondition for keeping the routing layer practical.

The Privacy and Compliance Reality

The "open models are more private" framing is partially true and partially marketing. The full picture:

Frontier closed APIs (enterprise tier). All major closed providers — Anthropic, OpenAI, Google — offer enterprise tiers with zero data retention, SOC 2 / HIPAA compliance, no training on your data, and strong contractual guarantees. For most enterprises, including most regulated industries, these tiers are sufficient. Your data goes over the wire, gets processed, never gets stored, never gets used for training. The provider is contractually on the hook if any of those fail.

Hosted open-weight APIs. Privacy posture varies by provider. Together, Fireworks, Anyscale offer enterprise tiers with similar guarantees. Some providers do not. Read the data-processing agreement; don't assume.

Self-hosted open weights. Only path where data literally never crosses your network boundary. Right answer for: defense, certain healthcare workflows where even a contractual guarantee isn't enough, customer data that's the product itself, R&D workloads where the prompts and outputs reveal strategic information you don't want any third party to see (even contractually). Wrong answer for: companies who want the marketing benefit of "we don't send your data anywhere" without the engineering cost of running inference at scale.

What This Means for Your Stack in 2026

If you're greenfielding an LLM application this year:

1. Start with a hosted open-weight model (Qwen 3 if you want generalist capability, DeepSeek V4 if cost dominates, GLM-5 if it's code-heavy). Get the product working at production-acceptable quality.
2. Build real evals before optimizing. "Frontier model would be 5% better" is meaningless without a metric on your task. With evals you can make the model-tier decision quantitatively.
3. Wire a provider-agnostic abstraction from day one — AI Gateway, LangChain, your own thin wrapper. The cost of swapping models later is 10× lower if you didn't bake the API surface into your application code.
4. Reserve the frontier closed tier for the small slice of traffic where capability genuinely matters and the user is interactive. Pay there. Save elsewhere.
5. Defer self-hosting until volume or regulatory posture forces it. The hosted open-weight providers are good enough for most cases and a fraction of the operational burden.

If you want to keep up with the model landscape as it shifts, the Artificial Analysis leaderboard is the cleanest aggregate view. For deeper context on the AI engineering job market and the skills companies are hiring for in 2026, browse our AI/ML engineering roles and the AI tools directory we maintain.