DeepSeek’s 57.6T-Token Week Is Bigger Than Its Two-Slot Lockout
Leaderboards invite the wrong kind of confidence. A model moves up one place, somebody screenshots the table, and by lunch the ordinal number has become a procurement argument. OpenRouter’s latest weekly usage ranking is a useful corrective: DeepSeek now owns both top slots, but the important number is not “two.” It is 57.6 trillion tokens.
That is how much traffic DeepSeek V4.1 Flash 1017 processed through OpenRouter over seven days, according to the platform’s live rankings data through November 4. The model’s volume rose 46% week over week and now represents roughly 41% of all tokens consumed by the top 20 models. It handled 3.56 times the volume of the second-place model and more than ranks two through four combined, which totaled 41.05 trillion tokens.
This is no longer the usual post-launch sugar rush where a new model briefly attracts benchmark tourists. No model entered or left the top 20. Every position change was a one-slot move. Inside that unusually stable cohort, DeepSeek V4.1 Flash climbed from third to second, putting two DeepSeek variants at the top with 73.8 trillion weekly tokens between them. Together they processed about 4.6 times the volume of third-place GLM 5.3 Flash.
The ranking shuffle is small. The concentration behind it is not.
One company is becoming the default path through the router
OpenRouter’s chart measures prompt, completion, and reasoning tokens routed through its API. It does not measure intelligence, customer count, revenue, successful tasks, or the total market. Direct traffic to OpenAI, Anthropic, Google, DeepSeek, and every other provider is outside the frame. Even within OpenRouter, free tiers, routing defaults, tokenizer differences, and verbose reasoning traces can change token volume without changing the number of useful jobs completed.
Those caveats are real, but they should not be used to wave away 57.6 trillion tokens. Developers do not route that much production-shaped work by accident. Each token carries some combination of cost, latency, privacy exposure, and operational risk. A model sustaining this lead has cleared enough teams’ practical thresholds to become infrastructure, not merely a demo.
The first original implication is about ecosystem gravity. When two variants from one provider dominate a neutral router, integrations, examples, caches, fallback policies, and institutional familiarity begin to accumulate around that family. That makes the next workload cheaper to migrate onto DeepSeek even if a competitor is marginally better on a benchmark. Adoption can compound through operational comfort long before it becomes a formal standard.
The second implication is less flattering: token share may reward verbosity. A reasoning model that burns twice as many tokens to reach the same accepted result appears twice as large in this table. The right unit for an engineering team is not tokens routed but accepted outcomes per dollar and per second. OpenRouter’s numbers show utilization; they do not tell us whether DeepSeek reached those outcomes efficiently.
GPT-6 Luna rose while its traffic fell
The cleanest warning against reading rank as demand comes from fourth place. GPT-6 Luna moved from fifth to fourth even though its rolling weekly volume declined 7% to 8.95 trillion tokens. It rose because Tencent’s Hy4 preview contracted faster, falling 10% to 8.1 trillion. The podium changed while both runners slowed down.
That distinction matters anywhere a leaderboard feeds automated routing or model evaluation. An ordinal rank records crossings, not momentum. If your internal dashboard stores only the current position, it cannot tell the difference between a model winning new work and losing less work than its neighbor. Teams should retain absolute token volume, week-over-week change, price, latency, error rate, and task mix alongside rank. Without the denominator and trend, a leaderboard is a lossy compression format pretending to be strategy.
The same dynamic explains why the fastest-growing models did not leap through the table. Kimi K3.1 Pro grew 166% and moved only one place, to thirteenth. GPT-5.6 Luna grew 163% but remained ninth. MiniMax M3.1 Flash nearly doubled at 98% and stayed eighth, while Nvidia’s free Nemotron 3.5 Super VL gained 60% and held eighteenth. A seven-day rolling window carries yesterday’s traffic forward; acceleration takes time to become rank.
That creates a third useful insight: rate of change is a discovery signal, while absolute volume is an operational-confidence signal. A fast-growing model belongs in the evaluation queue. A high-volume model deserves attention as an established option. Neither earns automatic production promotion.
Turn popularity into an evaluation backlog, not a buying decision
For practitioners, the immediate move is not to replace a working model with DeepSeek. It is to make sure the model family appears in a workload-specific evaluation if governance permits it. Use production traces with sensitive data removed, define what an accepted result means before testing, and compare cost per accepted result rather than cost per million advertised tokens.
At minimum, record p50 and p95 latency, tool-call success, structured-output validity, retries, total tokens per completed task, and failure recovery. For agentic systems, separate first-pass success from eventual success: a cheap model that needs three retries may be more expensive and slower than a premium model that completes once. For extraction and transformation, score exactness and schema adherence. For coding, run the model against repository-specific tests rather than a public benchmark that may overlap with training data.
The growth list provides a sensible challenger set. Kimi K3.1 Pro, GPT-5.6 Luna, and MiniMax M3.1 Flash have enough momentum to justify a controlled bake-off. DeepSeek’s two leading variants deserve tests across both routine and difficult tasks, because the cheaper workhorse and the heavier fallback may have different failure shapes. Keep an incumbent as the control and route only a small percentage of low-risk traffic until the challenger clears reliability and governance thresholds.
Teams should also test resilience, not just quality. Two top slots from one provider can tempt a router configuration that is diverse in model names but concentrated in one vendor’s infrastructure, policies, and failure domain. A fallback tree should cross providers where practical. Otherwise a nominally multi-model stack can fail like a single-provider stack during an outage, quota change, moderation shift, or pricing event.
The stable membership of the top 20 makes this a tuning day rather than a strategy-reset day. There is no fresh entrant demanding an emergency migration. The productive work is quieter: update evaluation candidates, preserve underlying trend data, inspect routing concentration, and verify that token-heavy reasoning is buying better outcomes rather than merely larger invoices.
OpenRouter’s ranking is valuable precisely when read narrowly. It shows what developers using one important routing market are willing to keep running. DeepSeek’s lock on the top two positions says its models are economically useful across a substantial body of real workloads. It does not crown the smartest model, and it does not absolve anyone from testing.
The leaderboard’s strongest signal is therefore not that DeepSeek “won.” It is that routed LLM usage may be consolidating before the model market itself has settled. Builders should exploit that maturity without inheriting its blind spots: benchmark the leaders, watch the accelerators, diversify the failure domains, and make every promotion earn its place with accepted outcomes. Popularity can choose what enters the test. It should never decide what leaves it.
Sources: OpenRouter Rankings, OpenRouter weekly rankings API, OpenRouter model catalog API, OpenRouter rankings methodology