Open Weights Are Good Enough. The Hard Part Is Everything After.

Anyone responsible for AI strategy inside a large enterprise now spends less time asking "which model is best" and more time asking a harder question: for each workload, what is the cheapest model that clears the bar, and what risk comes along when it moves there?

A year ago that question had a lazy answer: use a frontier commercial model for everything and let procurement absorb the bill.

That answer is now wrong. And the evidence is not a benchmark. It is where production tokens actually go.

The signal

On OpenRouter, the neutral marketplace developers use to route traffic across hundreds of models, US-origin models from OpenAI, Anthropic, and Google fell from roughly 70 percent of token volume in June 2025 to about 30 percent a year later.

CNBC's investigation found Chinese open models have held above 30 percent of tokens routed by US firms every week since early February, peaking near 46 percent. That figure averaged 11 percent the year before, and just 4.5 percent in early 2025. Over the same window, the platform's total throughput grew from about 5 trillion tokens a week to more than 20 trillion.

OpenRouter is one venue, and it skews toward developer and agentic traffic rather than the whole enterprise market. But that is exactly what makes it useful: it is revealed preference at production scale, not a survey of intentions. And the preference moved.

The reason is not ideology. Open models got good, and they run 60 to 90 percent cheaper than the leading commercial offerings. In one nine-day stretch this summer, Zhipu's GLM-5.2 posted a higher SWE-bench Pro score than GPT-5.5, and Moonshot's Kimi K3 topped a frontend coding arena judged by real developers, ahead of Anthropic's Fable 5. For bulk and cost-sensitive work, the decision has stopped being close.

The question worth debating is no longer whether to use open weights. It is where to draw the line.

Which workloads move, which stay commercial, and how to run the open side without quietly accumulating risk that surfaces later as an incident review. That is the rest of this piece.

Where "good enough" actually ends

"Good enough" needs a boundary, because the capability gap is real in specific places even as it vanishes in most.

Epoch AI's capability index puts the best open-weight models about four months behind the closed frontier. The UK's AI Security Institute, measuring cyber capability specifically, puts the lag at four to seven months, down from six to ten through most of 2025.

On everyday coding, extraction, summarization, classification, and drafting, the gap has effectively closed. Where commercial models still clearly lead is the hardest reasoning, novel multi-step problems, and long-horizon agentic chains, where small per-step error rates compound into failure.

Two caveats belong next to those numbers.

First, the published frontier is not the real frontier. The leading labs hold their most capable systems back, so the true gap is probably somewhat wider than leaderboards show.

Second, open families ship new versions as fast as commercial ones (Kimi went K2.5 to K2.7 to K3 within months), but the weights you deploy are frozen. Nobody can deprecate or silently alter them, which is a gift for lifecycle planning. Nobody will silently patch a safety flaw either. Every upgrade is a migration you schedule, test, and own.

Both facts are inputs to the split, not reasons to avoid it.

The cost structure, and the deployment choice inside it

Capability explains why the switch is possible. Cost explains why it is happening now.

Open-weight flagships run at roughly a sixth of the price of a comparable commercial API, and the cheaper tiers sit far below that. DeepSeek's V4 Flash lists near $0.14 and $0.28 per million input and output tokens first-party, on the order of a hundred times cheaper than a premium model's output pricing. GLM-5.2 sits around $1.40 and $4.40, Kimi K2.7 around $0.95 and $4.00, while a premium commercial model like Opus 4.8 is $5 and $25.

At agentic-workflow volumes, where a single task can chain dozens of inference calls, that difference stops being a line item and becomes a constraint on how much AI you can afford to deploy at all.

How you capture the savings matters as much as the model:

Inference-hosted on a Western provider (Fireworks, Together, DeepInfra, Baseten and peers). Roughly double the Chinese first-party price, which buys a US or EU jurisdiction, zero-retention terms, and no operational burden. Still far below commercial rates. This is the default for most enterprises.

Self-hosted on your own or rented GPUs. Cheapest per token at sustained high volume, and the only path that keeps prompts entirely inside your perimeter, which is decisive for genuinely sensitive data. It carries real fixed cost: GPUs, idle capacity, and the security and maintenance work covered below.

The first-party Chinese APIs are cheapest of all, but they are also where prompts can fall under Chinese jurisdiction. They belong to experimentation on non-sensitive tasks, never production with real data. For any regulated business, that is not a debatable point.

The framework: three questions per workload

Do not pick a camp. Route each request to the cheapest model that clears the bar for that task, and set the bar with three questions.

1. How much reasoning does the task actually demand? This sets the capability floor. Routine extraction, classification, summarization, drafting, and bounded coding clear easily on open weights. Hard multi-step reasoning and long autonomous agent chains still favor commercial models, because that is precisely where the residual gap lives.

2. How exposed are its inputs? This sets the security floor. Controlled, trusted inputs (internal tools, batch jobs over your own data, developer agents, bounded transformations) are safe territory for open weights. Adversarial inputs (public chat, anything ingesting untrusted user text or web content, agents with real tool access to payments and personal data) are not, unless the open model sits behind a serious guardrail stack.

3. How much liability rides on its outputs? This sets the commercial floor. Internal and low-stakes outputs can run on open weights, where you self-carry residual risk comfortably. Customer-facing, brand-sensitive, IP-heavy, or regulated outputs are where commercial models earn their premium, because the major vendors indemnify you against third-party IP claims and open weights do not.

Score a workload on those three and the placement falls out into a three-tier pattern:

Tier 1. Bulk and routine work: open weights, self-hosted if volume justifies the fixed cost, otherwise on a Western host. This is the majority of most token budgets and where the savings are largest.

Tier 2. Harder open-eligible work: an open flagship (GLM-5.2, Kimi K3, DeepSeek V4, or a strong US open model like Nemotron) on a Western host, for tasks that need more capability but are neither the hardest reasoning nor highly exposed.

Tier 3. The top of the difficulty and exposure curve: a commercial frontier model, reserved for the hardest reasoning, the most adversarial inputs, and the highest-stakes outputs. A smaller share of volume carrying a disproportionate share of value.

The market is already bifurcating along this exact line: open weights winning the commodity lane on volume, commercial models keeping the premium lane on revenue. A router that sends each task to the right lane is how you capture most of the savings without giving up the ceiling.

If you want a first workload to move, it is almost always the coding assistant.

It scores well on all three questions simultaneously. Capability is proven. Inputs are internal and controlled. And outputs land in an environment already built for exactly this risk, since generated code gets reviewed, scanned, and run through CI before it ships. It is also one of the highest-volume AI workloads in most organizations, so it delivers the single largest slice of the cost reduction.

The part teams underestimate

The savings are real, but open weights transfer to you a set of responsibilities that hosted commercial models absorb silently. None of these are reasons not to switch. They are the engineering and governance work that makes the switch safe, and they are what push specific workloads back toward commercial.

You carry the liability. Commercial vendors stand behind their outputs against third-party IP claims, subject to conditions. Open weights carry no such shield, and the exposure is widening from the other side: through 2026, insurers have been adding AI-output exclusions to liability policies. "Open weight, self-carried risk, insurer excludes the harm" is a gap that belongs in front of a board before it appears in an incident review. This alone is the strongest reason to keep high-liability, customer-facing work on commercial models.

Open weights are structurally more attackable. The safety tuning is lighter and, worse, removable: anyone can strip guardrails or fine-tune a backdoor into weights that still pass every benchmark. And because the weights are public, an attacker can develop adversarial prompts offline against the exact model you run, with no rate limit and nobody watching, until one transfers. A commercial API forces attackers into slow, observable, throttled probing. Same capability, very different attacker economics. This is why adversarial-input workloads either stay commercial or sit behind a real guardrail stack: input and output classification, strict tool-use allowlisting, privilege separation from anything touching money or personal data, and anomaly detection on the input stream.

The weight file is a supply-chain artifact. If you self-host, treat models with the same hygiene as any other dependency. The common serialization format can execute code on load, and malicious models do surface on public hubs. Prefer safetensors, verify provenance before a model enters your registry, and treat the "trust remote code" flag like running an unknown binary. Routine engineering, not heroics.

Govern what the model writes, not only which model you run. Every model carries training-data bias into its output, and different open families lean different ways. A model will reach for a library like PyMuPDF because it is common in training data, even though its copyleft license makes it a poor fit for proprietary product code. Prompts and org-standard conventions lower the odds; only a deterministic gate in the pipeline, a license and dependency scan that fails the build, removes the exposure. And because you are spreading work across several models, that enforcement layer must be model-independent: one pass over every model's output, whichever model produced it. That layer is what makes a multi-model estate governable rather than chaotic.

The same model is not always the same model. "GLM-5.2" is whatever the endpoint served. Identical weights at different numerical precision on different hosts produce different quality: FP8 typically lands within about half a point of full precision, but four-bit quantization on a smaller model can cost five to ten percent. Two providers serving the nominally identical model can sit on opposite sides of your quality bar. Evaluate at the level of the served endpoint, not the model name, and pin the precision you accept in the contract.

Build redundancy that survives the failure it exists for. A fallback should differ from the primary on family, provider, and jurisdiction, because those are the axes that actually fail together: a shared jailbreak or lineage-wide suspension (when Anthropic suspended Fable earlier this year, the whole family went, not one endpoint), a provider outage, or a geopolitical action that sweeps every model of one origin at once. A fallback to another tier of the same family, or another host in the same region, is correlated risk wearing a redundancy costume.

What this means for how you organize

The strategic implication, and the reason chasing the single best model misreads the moment, is this.

The models are interchangeable and change every few weeks. What compounds is the layer you build around them:

• The router that scores workloads on reasoning, exposure, and liability.
• The evaluation harness that tests served endpoints against your own tasks rather than public benchmarks.
• The model-independent enforcement layer that governs outputs regardless of origin.

Those three assets are owned by your platform team, they outlive every individual model, and they are what turn model churn from a strategy crisis into a configuration change.

So split by task, not by loyalty. Push the bulk of your volume to open weights, hosted or self-hosted according to your volume and sensitivity. Keep commercial models for the hardest reasoning, the most exposed inputs, and the outputs you cannot afford to have wrong or unindemnified. Handle open's baggage as deliberate engineering.

Get that line right, and the next model that jumps the frontier, from whichever lab, under whatever license, is not a strategy decision. It is a routing change.