Four Chinese Open-Weight AI Coding Models, 12 Days, One-Third the Price: What It Actually Costs to Switch

Between April 7 and April 24, 2026, four Chinese open-weight AI coding models reached general availability in rapid succession: Z.ai's GLM-5.1, MiniMax's M2.7, Moonshot's Kimi K2.6, and DeepSeek V4. Seventeen days, four frontier-grade releases, no major conference to explain the timing. The compression was unusual enough to generate genuine attention, and the pricing gap between these models and Claude Opus 4.7 was real enough to generate genuine temptation. What followed was a wave of coverage that mostly got the headline right and the analysis wrong.

The headline is that Kimi K2.6's API costs roughly $4.50 per million tokens against Claude Opus 4.7's $15 per million, which translates, on a standardized ClawBench agentic coding task, to something in the range of $0.30 versus $1.10 per run. That is a real and significant difference. The part the coverage mostly skipped is that the word "open-weight" in these announcements is doing specific and limited work. Weights are available for self-hosting. That is not the same as open-source, and the license terms governing what you can actually build on top of those weights differ materially from what most developers assume when they hear the phrase. The interesting decisions, the ones that determine whether the cost savings are real or theoretical, live in that gap.

What Actually Happened in Those 12 Days?

The four models arrived in a sequence that matters for understanding their relative positioning. GLM-5.1 from Z.ai landed first, followed by MiniMax M2.7, then Kimi K2.6 from Moonshot, with DeepSeek V4 closing the window on April 24. Each release was accompanied by benchmark claims that positioned the model against the US frontier, and each set of claims required careful reading to understand what was actually being measured. The compression of these releases into a single three-week period was not coordinated in any publicly documented way, but the effect was a kind of collective proof-of-concept: Chinese labs were operating at a cadence that had previously been associated only with the period immediately following a major conference or a significant compute unlock.

The pricing comparison anchors the conversation but requires some precision to be useful. Kimi K2.6 at $4.50 per million tokens versus Claude Opus 4.7 at $15 per million is a roughly three-to-one ratio at the token level. On a per-run basis for a standardized ClawBench agentic coding task, the difference is approximately $0.30 versus $1.10. For a team running hundreds of thousands of agentic coding tasks per month, that arithmetic is genuinely compelling. For a team running a few thousand, the absolute dollar savings may be smaller than the engineering cost of the migration. The ratio is real. Whether it translates to real savings depends entirely on volume and on switching costs that the per-token price does not capture.

The open-weight distinction deserves more than a footnote. All four models make weights available for download and self-hosting, which is meaningfully different from the closed-API model that defines the US frontier. But open-weight is not open-source in the sense that the OSI defines it, and none of these four models ships under a license that permits unrestricted commercial deployment without reading the terms carefully. A team that celebrates "open-weight" as equivalent to MIT-licensed freedom is setting up a legal conversation they did not intend to have.

How Do These Models Actually Score on Real-World Coding Benchmarks?

On ClawBench agentic coding, Kimi K2.6 scores 87 out of 100, placing it in Tier A. Claude Opus 4.7 scores 97, placing it in Tier S. That ten-point gap is not cosmetic. It surfaces primarily on multi-step refactoring tasks and cross-file dependency resolution, which are exactly the kinds of tasks that define senior engineering work rather than greenfield generation. On single-file code generation, the gap narrows considerably, and for many practical workloads, Tier A is more than sufficient. But the aggregate score obscures where the gap is load-bearing and where it is not.

DeepSeek V4 presents a measurement problem that most published comparisons have not resolved cleanly. Its ceiling performance on SWE-Bench Pro requires the DeepClaude shim to unlock. Without that shim, out-of-the-box harness runs systematically undercount its capability, because the model's default behavior does not align well with the standard evaluation harness's expectations. This means that comparisons between DeepSeek V4 and US frontier models are frequently not measuring the same configuration of DeepSeek V4, and the published numbers should be read with that caveat in mind. The shim dependency is not a minor integration detail; it is a precondition for the model performing as advertised.

GLM-5.1 and MiniMax M2.7 perform credibly on single-file generation and autocomplete-style tasks. They fall further behind on agentic multi-turn workflows, where sustained context management and cross-file reasoning are required. The gap between these two models and the top of the cohort is not uniform across task types, which is the core reason that aggregate leaderboard scores are a poor guide to deployment decisions. MMLU-style academic benchmarks are nearly useless for predicting agentic coding performance specifically. ClawBench and SWE-Bench Pro are the benchmarks that map most directly to real engineering work, and even those require running against your actual task distribution rather than the standard evaluation set.

The NIST CAISI cross-domain aggregate evaluation adds a useful calibration point. It places DeepSeek V4 behind the US frontier by roughly eight months on the metrics it measures, which include sustained reasoning chains across long codebases. Eight months is not years. It is also not negligible, particularly for teams whose hardest problems involve exactly that kind of sustained context management. The honest framing is that the Chinese cohort has achieved genuine frontier-adjacent performance on a meaningful subset of coding tasks, while trailing on the subset that is hardest to automate. That is a more useful description than either "caught up" or "still far behind."

What Are the Real Switching Costs Nobody Is Calculating?

Self-hosting open-weight models at inference scale is a different problem than running them locally for evaluation. Ollama is an excellent tool for local experimentation, and it is where most developers first encounter these models in a hands-on way. But Ollama's ceiling is well below production inference scale for a team running thousands of daily agentic coding tasks. The jump from local experimentation to managed deployment introduces GPU capacity planning, orchestration tooling, model-ops processes for version management and rollback, and ongoing latency monitoring. That work has a cost that does not appear in the per-token price, and it is not a one-time cost. It recurs every time a new model version drops, every time a dependency changes, and every time an inference node needs maintenance.

The DeepClaude shim requirement for DeepSeek V4 Pro is worth treating as a first-class engineering concern rather than a configuration note. The shim introduces a middleware dependency that sits between your application and the model, and that dependency has consequences for observability. Teams using Sentry for error tracking in AI pipelines will find that prompt logging and error attribution become more complicated when a shim is in the path. Any harness originally built for Claude-compatible APIs needs rework, not just reconfiguration. The shim is not insurmountable, but the teams that treat it as a minor integration footnote are the ones who discover its implications during an incident at two in the morning.

The switching cost is not the price of the new model. It is the price of everything that assumed the old one.

Enterprise data residency and compliance risk do not appear in per-token pricing at all. Data sent to non-Tier-1 API providers carries compliance exposure that varies materially by provider. SOC 2 coverage, data residency guarantees, and contractual liability clauses differ between Anthropic, the Chinese API providers, and self-hosted deployments on platforms like Google Vertex AI. A team with GDPR obligations, healthcare data, or financial data in their coding context windows cannot treat these differences as fine print. The compliance conversation needs to happen before the infrastructure commitment, not after the first audit finding.

Workflow automation teams running AI steps through tools like n8n or Make face a specific and underappreciated failure mode: silent schema drift. When a model backend is swapped, the response schema often changes in ways that do not throw an immediate error but produce subtly malformed outputs that propagate through downstream nodes. Every workflow node that assumes a Claude-compatible response structure needs to be audited and tested against the new model's actual output format. This is not a configuration change. It is a testing and validation exercise that takes real engineering time, and teams that skip it will find the problems in production rather than in staging.

For teams evaluating self-hosting more seriously, Hugging Face is the primary discovery and weight-hosting layer, and it is where the license terms, model cards, and community evaluations live alongside the weights themselves. For teams that want API-level access without full infrastructure commitment, OpenRouter provides a unified API that routes to multiple model providers, including several of the Chinese cohort, without requiring a direct relationship with each provider. OpenRouter is the lowest-friction path to running a real workload comparison before making any infrastructure decision.

What Do the License Terms Actually Permit?

Kimi K2.6 ships under a license that resembles MIT in its permissiveness for commercial use but contains usage restrictions that diverge from true MIT in specific deployment contexts. The distinction matters most for teams building a product on top of the weights rather than simply calling the API. API usage and weight-based deployment are governed differently, and the terms that apply when you are embedding the model into a product you sell to customers are not the same as the terms that apply when you are using the API for internal tooling. Reading the model card on Hugging Face is necessary but not sufficient; the full license document is where the operative language lives.

DeepSeek V4's license has evolved across versions, which is itself a risk signal for enterprise teams. The current version includes clauses restricting use in applications that compete with DeepSeek's own products. That clause is easy to dismiss in a developer context, where the immediate use case seems far removed from anything DeepSeek offers directly. It becomes harder to dismiss during a Series B due diligence process, when a legal team reads the license for the first time and asks whether the company's core AI-assisted product falls within the restricted category. The time to answer that question is before the infrastructure investment, not during the fundraise.

GLM-5.1 and MiniMax M2.7 carry their own custom terms, and none of the four models in this cohort are straightforwardly MIT-licensed in the way that phrase is typically understood by developers who have worked primarily with Western open-source projects. The pattern across all four licenses is that commercial deployment is permitted with conditions, and the conditions vary in ways that matter for specific use cases. Treating any of these models as equivalent to an MIT-licensed library is a legal exposure that most of the breathless coverage of the April release window skipped entirely.

For teams using Cursor AI or similar AI coding environments that embed model calls, the license question extends beyond the team's own direct use. The tool vendor's compliance posture with respect to the underlying model matters, and a team that is technically within the license terms for its own deployment may be relying on a tool vendor that is not. This is worth a direct question to the vendor before assuming the compliance chain is clean.

Who Should Actually Switch, and to What?

The decision is not binary, and the right answer differs meaningfully by team profile. Individual developers and small teams doing greenfield projects with low compliance exposure and genuine tolerance for integration work are the clearest candidates for switching. For this profile, Kimi K2.6 accessed via API through OpenRouter is the most defensible choice among the four models in this cohort. Tier A performance at roughly one-third the cost of Claude Opus 4.7, with no self-hosting overhead and no shim requirement, is a real value proposition. The ten-point ClawBench gap is real, but on the specific tasks that define most greenfield development work, it is rarely the binding constraint.

Enterprise teams with SOC 2 requirements, data residency constraints, or existing Claude-based toolchains face a different calculation. The switching cost for this profile almost certainly exceeds the per-token savings at current scale, at least in the short term. The compliance audit, the harness rework, the schema validation, the observability instrumentation, and the legal review of license terms together represent a project, not a configuration change. The right move for this profile is a bounded pilot on non-sensitive workloads, with a clear measurement framework for what success looks like, before any infrastructure commitment. Running the pilot through OpenRouter keeps the infrastructure cost low while generating real data on quality and schema compatibility.

Teams building AI workflow automation pipelines in n8n or Make should treat any model swap as a first-class engineering task. Budget explicitly for harness testing, schema validation, and observability instrumentation. The cost of not doing this is not a failed deployment; it is a quietly degraded deployment that produces subtly wrong outputs for weeks before anyone notices. The discipline required here is not different from the discipline required for any significant dependency upgrade, but it is discipline that the per-token price comparison does not remind you to apply.

The honest answer for most mid-sized engineering teams is a hybrid routing strategy. Keep Claude Opus 4.7 for the highest-stakes agentic tasks, the ones where the ten-point ClawBench gap is genuinely load-bearing: complex multi-file refactoring, cross-repository dependency analysis, and any task where a wrong answer has significant downstream cost. Route volume inference through Kimi K2.6: code review passes, docstring generation, test scaffolding, and other tasks where the quality delta between Tier A and Tier S is negligible in practice. This is not a compromise position. It is the architecture that captures the real cost savings while preserving quality where quality is actually required.

Before committing to any of this, run ClawBench against your actual task distribution. The aggregate benchmark score and your specific workload score will diverge, sometimes significantly, because the standard evaluation set does not mirror any particular team's codebase, language mix, or task complexity profile. That divergence is what determines whether the price difference represents real savings or an accounting illusion, and it is the one number worth generating before making any infrastructure decision.