Four Chinese Open-Weights Coding Models Dropped in 12 Days. DeepSeek V4 Costs $0.14 per Million Tokens. Claude Opus Costs $15. Here's the Stack Decision You Actually Need to Make.
In a 12-day window in late April 2026, four Chinese labs each shipped an open-weights coding model. Z.ai released GLM-5.1 under an MIT license. MiniMax released M2.7. Moonshot released Kimi K2.6. DeepSeek released V4, following it quickly with DeepSeek V4 Pro. All four hit agentic engineering benchmarks at or near Claude Opus 4.6 and GPT-5.5. None of the four cost more than a third of what you're paying for Claude Opus on input tokens, and the cheapest, DeepSeek V4 Flash, costs $0.14 per million input tokens versus $15 for Opus.
This isn't a benchmarks story. It's an inference cost decision that every solo operator running LLM pipelines needs to make this quarter.
The four models and what they actually cost
Here's the pricing as of late April 2026, sourced from the providers' APIs:
DeepSeek V4 Flash: $0.14 input / $0.28 output per million tokens. DeepSeek V4 Pro: $0.55 input / $2.48 output. Kimi K2.6: $0.50 input / $1.50 output. GLM-5.1: $0.60 input / $2.00 output. MiniMax M2.7: $1.00 input / $3.00 output.
For comparison: Claude Opus 4.6 runs $15 input / $75 output. GPT-5.5 Instant runs $5 input / $30 output.
At the high end of the Chinese stack (MiniMax M2.7 at $3/M output), you're still paying one-tenth of what Claude Opus costs on output tokens. At the low end (DeepSeek V4 Flash), you're paying less than one percent of Opus output pricing.
On coding benchmarks, DeepSeek V4 Pro scores 80.6% on SWE-Bench Verified with a 1M context window. That puts it on par with or slightly ahead of Claude Opus 4.6 on agentic engineering tasks, the same task category most solo operators actually care about for LLM pipelines.
GLM-5.1 under MIT: what self-hosting actually means
GLM-5.1 ships under the MIT license. That means you can fine-tune it, self-host it, redistribute it, and build commercial products on top of it without asking Z.ai for permission. For most solo operators, this is the most strategically interesting development in the batch.
Self-hosting a model at GLM-5.1's scale isn't a laptop operation. You need H100s or equivalent, which means either renting inference capacity from a cloud provider (Runpod, Lambda Labs, CoreWeave) or using one of the growing number of managed inference providers that now offer GLM-5.1 as an API endpoint.
The cost structure for self-hosted inference via GPU rental varies by batch size and usage pattern, but at moderate traffic you can typically get to $0.20–$0.40 per million output tokens with a provider like Runpod, comparable to the API pricing but with full data control and no per-token metering on the provider side.
The self-hosting path makes sense if you have data residency requirements, if you're generating enough volume to hit $2K+ monthly in API spend, or if you want fine-tuning control. For lighter workloads, the API is simpler.
The practical decision tree
Not all workloads are the same, and a blanket "switch to Chinese open-weights" recommendation misses the nuance.
Switch makes sense for: code generation pipelines where you're running thousands of generations a day and the output goes to human review before deployment. Document processing and extraction workloads with high volume and low sensitivity. Internal tooling where data doesn't leave your infrastructure and the primary constraint is cost.
Stick with Anthropic/OpenAI for: client-facing AI products where the model brand is part of what you're selling. Workloads with strict data residency requirements that Chinese API providers can't meet. Situations where model reliability and consistency over time matters more than cost: the Chinese providers have shorter track records on API stability and versioning guarantees.
The gray zone: customer-facing chatbots, proposal generation, and research summarization tools where quality matters but cost is a real constraint. Here you need to run your own evals with your specific prompts and use cases before switching. "Benchmark parity" doesn't mean "your prompts work equally well."
The compliance reality nobody is saying clearly
Running Chinese-origin model APIs through your client's infrastructure is a conversation you need to have explicitly, not something to quietly slot in because the benchmarks looked good.
Some enterprise clients will have blanket policies against data flowing through Chinese-operated API endpoints. Some won't care. Some haven't thought about it. The right move is to surface it in your stack choices and let clients make informed decisions, not to assume silence is approval.
For self-hosted open-weights models running in your own AWS or GCP infrastructure, the calculus is different: the weights are yours once you download them, and the data doesn't leave your environment. That's a much cleaner compliance story for sensitive workloads.
What I'd actually do
If I'm running LLM pipelines today with material monthly inference costs, I'm running a parallel eval set against DeepSeek V4 Pro and Kimi K2.6 on my actual production prompts this week. Not the public benchmarks: my prompts, my data, my failure modes.
If the quality holds, I'm migrating non-sensitive high-volume workloads to the cheaper stack by end of June and saving the Opus/GPT-5.5 spend for the workloads that genuinely need it.
GLM-5.1 under MIT goes on my radar for a fine-tuning experiment: a domain-specific coding model trained on my client's codebase is worth more than a generic frontier model at any price, and MIT licensing makes that commercially viable.
The inference cost war isn't over. It's accelerating. The solo operators who treat their model selection as a quarterly decision rather than a set-and-forget choice will compound that cost advantage into margin over the next 18 months.
Author
Lukas
@lukcombinator