DeepSeek Hit 27.1% on OpenRouter. That’s Bigger Than Google and OpenAI.

OpenRouter’s text API request share puts DeepSeek at 27.1%, ahead of Google and OpenAI under that metric. That is not an all-out victory. The 27.1% is a share of request counts, not revenue share, and not overall market share. It measures what developers do when they can switch models: they press the call button, again and again. The number matters because it complements another figure. Count DeepSeek V4.1 Flash’s old and new versions together, and token usage reaches 51.6 trillion.

High token volume shows large usage. A high request share shows many users and frequent calls. Put the two together, and the growth looks broad: not a few large customers pulling up token volume, but many small and medium requests repeatedly choosing DeepSeek. The 51.6 trillion figure can be inflated by long context and batch jobs. The 27.1% figure, on its own, hides scale. Both metrics are needed.

Two concrete sources explain the rise.

First, version migration. DeepSeek’s old and new versions already had traffic switching between them. Some calls stayed on the old V4.1 Flash version and, during the statistical period, moved to the new 1017 version. That is not customer acquisition from zero. It is existing users regrouped onto the new version. The migration itself is ordinary. Statistically, it creates a period where the combined figure looks larger. Single-version and combined metrics need separate labels, or migration-driven volume will look like new growth.

Second, a competitor’s supply problem. MiMo-V2.6-Flash did not fail because its capability was weak. It failed because compute did not keep up. Speed was slow. Calls failed often. Developers hit timeouts, retried, and found that switching cost had dropped. Engineering teams compare more than benchmark scores. Latency, failure rate, rate-limit rules, and price sit on the same table. A model that fails often gets replaced, no matter how strong its capability looks. Some MiMo-V2.6-Flash users moved to DeepSeek V4.1 Flash 1017. DeepSeek did not do everything right on its own. A competitor dropped the ball on supply and pushed users over.

Compute constraints turn model competition into supply competition. When every model is good enough, migration is decided by stability, price, and rate limits, not by a few leaderboard points. MiMo’s problem was not the model. Compute did not keep up. Compute cannot be bought instantly. Supply chain, cluster scheduling, inference optimization, and long-term contracts mean money solves part of the problem, not all of it at once.

Kimi K3.1 Pro shows the same constraint from the pricing side. Put its subscription price next to DeepSeek V4.1 Flash’s API price, and the developer’s choice becomes concrete. One side is a subscription with fixed quotas or rate-limit rules. The other is pay-as-you-go pricing, billed by usage. Kimi is also trapped by compute. Its price is estimated from its own compute situation. When compute is tight, unit costs stay high, and the price-performance ratio is hard to make competitive.

Being expensive is not a sin. Enterprise customers pay premiums for SLA, context length, tool calling, and data compliance. The premium needs a reason, and users need to perceive that reason. If the premium shows up as lower failure rates, clearer rate limits, and steadier latency, users will pay. If the premium comes only from high compute costs, while speed and retry experience show no clear advantage, developers will do another calculation. Kimi’s price-performance ratio is low under current compute constraints. That does not mean Kimi cannot set this price. It means the price has not created a strong enough relative advantage. Price is set by the strength of substitutes, not by the seller’s wish.

MiMo and Kimi share a pattern. Neither loses because its model capability is completely inadequate. Both lose on supply experience under compute constraints. MiMo loses on speed and failure rate. Kimi loses on price-performance. DeepSeek offers a combination that fits this window: good enough, stable, cheap, and switchable. Competitors’ weaknesses become DeepSeek’s increment.

Competitor weakness explains only part of the story. Version migration regroups the existing base. Competitor weakness pushes incremental users over. API pricing keeps developers there. Request share verifies breadth. No single step is surprising. Together they produce 27.1%. This is a compounding process, not a single-point breakout.

DeepSeek’s OpenRouter performance should not be reduced to “the model is just too good to use.” At a stage when compute is a hard constraint, model competition shifts from a capability race to a supply race. DeepSeek caught the existing base from version migration, caught users overflowing from competitors’ compute shortages, and used pricing and stability to keep developers. The 27.1% is the result, not the cause.

MiMo’s lesson: failure rate and speed kill willingness to migrate. Kimi’s lesson: a premium needs a reason users can perceive. DeepSeek’s next test comes when MiMo catches up on compute and Kimi adjusts pricing. In OpenRouter’s model list, when developers switch models again, will they still click on DeepSeek?