Open Weights or Closed APIs? The Question Enterprises Are Actually Asking

Every few weeks I get the same question from a CIO or a head of platform engineering. Should we build on a closed model like GPT or Claude, or should we go open weight with something like Llama, Qwen, or DeepSeek? It usually arrives framed as a technology decision. It almost never is. It is a control decision, and once you see it that way, the answer gets a lot clearer.

Let me lay out the real difference, put current numbers on the table, and then tell you how I think about it after deploying agentic systems inside regulated enterprises.

What the two things really are

A proprietary closed model is hosted by the developer. OpenAI, Google, Anthropic, and xAI run the infrastructure, keep the internal mechanics hidden, and hand you an API. You send tokens in, you get tokens out, you pay per use, and you trust the vendor with everything in between, including where your data lands and how it is secured. It is clean, fast to adopt, and you never touch a GPU.

An open-weight model is different. The developer publishes the core parameters, the weights, so you can download the model and run it on your own hardware. Meta's Llama, Mistral, Google's Gemma, and the Chinese labs behind Qwen, DeepSeek, GLM, and Kimi all ship this way. You get to self-host, fine-tune on your own data, and keep everything inside your environment. In exchange, you own the infrastructure, the serving stack, and the operational burden that comes with both.

One correction, because the industry is sloppy about it. Most of what gets called "open source" is really open weight. You get the weights and usually a permissive or semi-permissive license. You rarely get the full training data or the complete training code. That distinction matters the moment your legal and compliance teams start reading licenses, so do not let anyone tell you these models are fully transparent. The weights are visible. The recipe usually is not.

The proprietary frontier, mid-2026

Here is where the top closed models actually sit as of July 2026. Treat the numbers as directional. This field moves monthly, and benchmark scores shift with the scaffold and the evaluation framework, so always verify against a live leaderboard before you commit.

Model (vendor)	Strongest at	Coding (SWE-bench Verified)	Reasoning (GPQA Diamond)	Price (in / out per 1M tokens)	Key concern
Claude Opus 4.8 (Anthropic)	Agentic coding, multi-file reasoning, long-context coherence	~88.6%	~93.6%	$5 / $25	Most expensive in the class; premium you pay whether the task needs it or not
GPT-5.5 (OpenAI)	Broad ecosystem, terminal and computer use, structured reasoning	High tier, API still rolling out	~92%	~$2.50 / $15	Recall caveated heavily in vendor docs; usage-based cost climbs fast at scale
Gemini 3.1 Pro (Google)	Abstract reasoning, multimodal, best value at the frontier	~80.6%	~94.3%	$2 / $12	Available only through Google Cloud and Vertex; ties you to one hyperscaler
Grok 4 (xAI)	Hardest-question reasoning (HLE), real-time data access	Competitive, trails the top three on coding	Strong	Mid-range	Youngest governance and safety track record; thinner enterprise tooling
Amazon Nova Pro (AWS)	Deep Bedrock integration, enterprise plumbing	Mid-frontier, below the leaders	Mid-frontier	Low to mid	Trails the frontier on the hardest reasoning; pulls you deeper into the AWS estate

Read that table and the pattern is obvious. No single model wins everything. Claude Opus leads coding and long-context work. Gemini gives you frontier-level reasoning at roughly half the price of the top tier. GPT gives you the broadest ecosystem and the strongest computer-use numbers. The right proprietary model depends entirely on the workload, which is exactly why locking your whole company to one of them is a mistake.

The open-weight field has closed the gap

Two years ago, open weights were a curiosity you tolerated for privacy. That is over. In the first half of 2026 alone, roughly nine frontier-class open-weight models shipped in about six weeks. The gap to the closed frontier is now measured in a few points, not a chasm, and on some agentic benchmarks the open models are ahead.

Here is the current open-weight shortlist, again as of July 2026.

Model (lab)	License	Strongest at	Coding (SWE-bench)	Context	Self-host footprint	Key concern
GLM-5.2 (Z.ai)	MIT	Long-horizon agentic engineering; open-weight coding leader	62.1% SWE-bench Pro (first open model to pass GPT-5.5 on Pro)	1M	80GB-class multi-GPU	Chinese-lab provenance draws procurement and security scrutiny
DeepSeek V4 Pro (DeepSeek)	MIT	Agentic coding, million-token traces, large-repo reasoning	~80.6% Verified (ties the closed frontier), #1 open on agentic work	1M	4 to 8x H100/H200	Heavy GPU bill; same provenance questions in regulated buys
Kimi K2.7 (Moonshot)	Modified MIT	Long-context agentic coding, tops the neutral open index	Top-tier among open weights	256K+	80GB-class multi-GPU	Serving ecosystem less battle-tested than DeepSeek or Qwen
Qwen 3.6 (Alibaba)	Apache 2.0	Best practical local coder; strong multilingual	73.4% Verified at only 3B active params	256K	Single RTX 4090 (27B variant)	Lower ceiling than the trillion-parameter models; provenance review still applies
Llama 4 Scout / Maverick (Meta)	Llama community license	Ultra-long context (Scout), broadest tooling and community	Maverick leads open MMLU (85.5%)	Up to 10M (Scout)	Multi-GPU for the large variants	Custom license restricts firms above 700M monthly users; now trails on coding

A few things stand out. The permissive licenses (MIT for GLM and DeepSeek, Apache 2.0 for Qwen) mean no royalties, no usage caps, and no geographic restrictions, which is why they are the cleanest choices for a commercial build. Meta's Llama carries a custom license with a large-user restriction, so read it before you assume it is free to deploy. And if data sovereignty is your driver, Mistral is the European option worth adding to any shortlist, now shipping under Apache 2.0, and NVIDIA's Nemotron is the one built to deploy cleanly on NVIDIA hardware inside your own environment.

Notice that the top open models now demand serious iron. A trillion-parameter model at 4-bit still needs multiple 80GB GPUs, and the KV cache balloons at these context lengths. Open weight does not mean free. It means you trade a per-token bill for an infrastructure bill, and you only come out ahead past a certain volume.

Where each one actually wins

Closed models still hold the lead on the hardest reasoning and the broadest general knowledge, and they carry the most mature safety alignment. If your use case is deep, novel reasoning and you want to offload safety and scaling to someone else, the API path gets you to production in an afternoon.

Open weights have caught up on almost everything else. For structured extraction, summarization, standard code generation, and increasingly for agentic patterns like function calling and tool use, the quality difference is negligible for most production workloads. That last part is the shift that changed the conversation this year. The agentic capabilities that used to be proprietary-only now ship in open weights.

The cost curve is the part most teams get wrong. APIs feel cheap because the first bill is small. Then usage scales. The crossover point, where self-hosting an open-weight model becomes cheaper than paying per token, tends to land somewhere between ten and thirty million tokens a day depending on model size and your input-output ratio. Below that, APIs usually win on economics. Above it, you are renting something you could own, and the meter never stops. Financial services teams running fine-tuned open-weight models internally have cut third-party API spend by more than forty percent. That is not a rounding error at enterprise scale.

And then there is the reason none of this is really a benchmark debate. Data. With a closed API, your prompts and your data are processed on the vendor's servers under the vendor's terms. With a self-hosted open-weight model, the data never leaves your environment. For a bank, a hospital, or anyone operating under GDPR, SOC 2, or a sovereignty mandate, that single fact often decides the whole thing before performance ever enters the room. "We send it to OpenAI" is no longer a frictionless answer in a procurement review. It is why on-premises deployment is now the largest slice of the open-weight market, and why European enterprises adopt self-hosted models at a noticeably higher rate than everyone else.

The framing that actually helps

If you take one thing from this, take this. Stop treating it as open versus closed. That framing forces a bet you do not need to make.

The models are moving too fast to bet on any single one. The best open-weight model in March was not the best in May, and will not be the best in September. The best closed model gets a price change or a deprecation notice you did not ask for. Anyone who hard-wired their stack to one provider in early 2025 has felt that pain by now. The winning posture is not picking a side. It is building so you can switch.

That is the position I have taken with lowtouch.ai from the start, and it comes from watching enterprises get burned by lock-in on both sides. Our platform runs privately, inside the customer's own infrastructure, including air-gapped environments, and it is model-agnostic by design. We support the closed models, OpenAI, Claude, Gemini, when the reasoning genuinely calls for them, and we host open-weight models like Llama and Nemotron privately when data control, cost, or latency matter more. The customer decides per workload, not once for the whole company. When a stronger model ships next quarter, you swap it in. You are never renegotiating your architecture because a vendor moved.

This is where most of the open-versus-closed debate misses the point. The real enterprise question is not which model is smartest. It is who controls your data, your orchestration, and your cost structure. Get those three right and the model choice becomes a tuning decision instead of a strategic gamble. Get them wrong and it does not matter how good your model is, because you have handed away the leverage that mattered. Governance, observability, and human-in-the-loop control have to sit above the model, not inside any one vendor's cloud, or your CISO is signing off on a black box.

How I would actually decide

If you are a senior technologist sizing this up, here is the practical path.

Start with your data constraints, not your model wish list. If sensitive data cannot leave your environment, or you operate under a residency or sovereignty mandate, self-hosted open weight is your baseline and everything else works around it. That is a hard constraint, not a preference, and it should drive the architecture.

Then look at volume. If you are prototyping or running low-volume workloads, closed APIs are the fast, cheap way to move. Once a workload becomes high-volume and steady, run the token math against the cost of owning the infrastructure, including the GPU footprint those tables above make clear is not trivial. Past the crossover point, self-hosting usually wins on cost, and it wins on control at the same time.

Then match the model to the task. Route the genuinely hard reasoning to the strongest model available, closed or open. Run the routine, high-frequency work on a smaller, cheaper, private model. Most mature teams I talk to already run both, and the ones getting real leverage are the ones who can move a workload between models without rebuilding anything.

The hybrid answer is not a hedge. It is the correct answer. The mistake is committing your architecture to one provider and calling it a strategy.

The bottom line

Open weight and closed API are not rival philosophies you have to choose between. They are two tools, each with a clear zone where it is the right one. Closed models for frontier reasoning and speed to first deployment. Open weight for data control, cost at scale, and independence from anyone's roadmap but your own.

What you should refuse to accept is lock-in. Build so your data stays yours, your orchestration stays auditable, and your model choice stays yours to change. Do that, and the open-versus-closed debate stops being a fork in the road and becomes what it always should have been, a setting you adjust as the landscape moves.

The enterprises that win the next two years will not be the ones who picked the right model. They will be the ones who never had to bet the company on the question.