DeepSeek's Price Increase May Be Due to Traffic Management, Not Loss

AI-generated summary: Recently, engineer dax from the third-party platform OpenCode pointed out that DeepSeek’s upcoming price increase may not be due to losses, but rather a traffic management strategy to alleviate server overload. OpenCode revealed that its partnered team has already replicated DeepSeek’s current pricing. However, actual testing showed that OpenCode Go’s average model consumption costs are roughly four times those of the official API, with some long conversation sessions exceeding a tenfold difference. The primary cause of this discrepancy lies in cache hit rates: DeepSeek’s official cache hit rate can reach 100% within 12 hours, while OpenCode accumulates more unhit caches over extended sessions, amplifying costs. DeepSeek’s cache technology advantage stems from three prefix-based disk persistence mechanisms and V4’s Token-wise Compression + Sparse Attention, significantly reducing the cost of million-token contexts. In the future, competition among AI coding products may shift toward the Harness ecosystem rather than solely comparing model intelligence.

Article author and source: InfoQ

Is DeepSeek about to increase its price?

Engineer dax from the third-party platform OpenCode recently posted about DeepSeek’s upcoming price increase, stating that he found a way to replicate its current pricing even when renting GPUs. He speculated that this price hike is likely not due to DeepSeek currently operating at a loss, but rather serves as a traffic management strategy—since current service loads are already too high, they aim to reduce demand and alleviate overload by raising prices.

Dax’s speculation aligns with the sentiments of many netizens. “This surge is primarily due to the V4 Flash’s overwhelming cost-performance ratio, causing massive demand on both the East and West data centers since July 31—servers have been pushed to their limits. Peak-off-peak pricing? It doesn’t exist here; what’s off-peak on your side is peak on mine, making it 24/7 peak hours. So in the large model field, high intelligence, low cost, and service stability remain an impossible triangle for now,” said a user on Zhihu.

Regarding the news that OpenCode can maintain DeepSeek’s current price, a netizen commented, “If true, this would be highly significant and cause outsiders to reassess DeepSeek’s infrastructure team, long regarded as a ‘legendary’ force.”

Subsequently, Dax revealed that this was not achieved by their own team, but by another team they are collaborating with. OpenCode is currently promoting the use of low-cost DeepSeek outside China via OpenCode Go.

DeepSeek is known for its low pricing, but the same DeepSeek model may cost even less on third-party platforms than on DeepSeek's own platform.

According to current vendor data listed on OpenRouter for DeepSeek V4 Flash 0423, DeepInfra charges $0.09 per million tokens for input and $0.18 per million tokens for output, while DeepSeek’s official prices are $0.14 and $0.28 respectively. At list prices, DeepInfra is approximately 64% of DeepSeek’s official rates, offering a savings of about 36%. Other third-party platforms such as GMICloud and Baidu Qianfan also offer prices lower than DeepSeek’s official rates.

Price Comparison Table, Source: OpenRouter

However, note that DeepInfra explicitly labels its V4-Flash as FP4, while DeepSeek’s official model repository includes BF16, FP8, and other formats. The exact precision and inference strategy used by the official API have not been fully disclosed on the pricing page.

DeepSeek has publicly released the V4-Flash weights, and the license permits third parties to use, modify, redistribute, and even commercially sell them. Therefore, third-party providers do not operate by purchasing the DeepSeek API at $0.14 and selling it at a loss at $0.09; instead, they can directly download the weights and run the model on their own GPUs or other accelerator clusters.

This is completely different from closed-source models like GPT and Claude. Third parties selling Claude typically still need to purchase Claude tokens from Anthropic, AWS Bedrock, or Google Vertex. However, third parties selling DeepSeek V4 can produce tokens themselves.

But if the price is matched or even lowered compared to the official rate, will users spend less money?

Taking OpenCode Go as an example, it is positioned as a low-cost AI programming subscription service for open models, priced at $5 for the first month and $10 per month thereafter. It currently supports access to multiple models, including DeepSeek V4 Pro, DeepSeek V4 Flash, GLM-5.2, Kimi K3, MiMo-V2.5, MiniMax M3, and Qwen3.8 Max. OpenCode’s official usage limits are set at a maximum of $12 every 5 hours, $30 per week, and $60 per month. The platform also states that, for most models, it aims to deliver up to approximately 6 times the model usage value for subscribers through bulk purchasing and reserved GPU capacity, all for the $10 monthly fee.

It was precisely the “$10 for $60” deal that led many users to intuitively believe that calling DeepSeek via OpenCode Go should be significantly more cost-effective than purchasing the DeepSeek API directly.

But that is not the case.

A developer conducted a validation using real AI coding tasks. He selected a codebase containing over 100 repositories and wanted the model to investigate and understand system knowledge in a specific domain. He then opened two terminals simultaneously: one using OpenCode Go and the other directly connected to the DeepSeek official API, entering the same prompt and executing the same code investigation task on both.

According to its published test results, OpenCode Go consumed approximately four times the cost of the official DeepSeek API across multiple short tasks; for some longer sessions, the difference exceeded ten times, while a few tasks showed only about double the cost.

The developer said he typically uses Claude and OpenAI subscription services for his daily development, spending about $100 per month on each. After the release of DeepSeek V4, he began using the official API to leverage V4 Pro and some V4 Flash instances for smaller-scale code investigations, observability analysis, and tasks requiring quick results—first having DeepSeek search code, read files, and analyze issues, then generating notes once satisfactory results are obtained, before handing these results over to Claude or GPT for final development. With this usage pattern, his monthly DeepSeek API costs remain under $10, even when handling substantial workloads.

However, some netizens have pointed out that the "dollars" shown in the OpenCode Go interface cannot be directly equated with the dollars in a user’s wallet. They argue that Go is essentially a subscription plan that provides a fixed monthly credit in exchange for a flat fee; if a user pays only $10 per month, the display of several dollars’ worth of model usage does not mean the user has paid that amount again. Therefore, directly comparing the $8 model usage shown in OpenCode with the actual $2 deduction from the DeepSeek API may overstate OpenCode Go’s true cash cost. Nevertheless, many developers genuinely feel that the official offering is cheaper.

“The main difference appears to be in cache hit rates,” the developer said. “DeepSeek’s official API handles caching significantly better than OpenCode Go. The longer a session lasts, the more cache misses OpenCode Go accumulates, causing the multiplier on final costs to increase steadily.”

In the end, he concluded that OpenCode Go may still be convenient for short tasks. However, for longer sessions—especially when cumulative model runtime from multiple interactions exceeds about five minutes—the cost of using DeepSeek via OpenCode Go could be significantly higher than calling the official API directly.

The developer also mentioned a detail: when using GLM, he can improve cache hit rates through model-specific settings, which are somewhat similar to configuring parameters like temperature or other request options. Specifically, he can set the model not to rewrite previous messages or to remove reasoning content from earlier turns. However, OpenCode does not expose similar model settings for DeepSeek.

For the Coding Agent, the model must continuously read code, invoke tools, return results, and feed the accumulated context back into subsequent reasoning rounds. If historical prompts can be cached, the large volumes of repetitive context in subsequent requests can be billed at a very low cache hit rate; however, if changes to the prompt prefix cause the cache to invalidate, hundreds of thousands or more historical tokens may be reprocessed at standard input rates. As conversations grow longer, this discrepancy rapidly escalates.

This is why measuring cost solely in terms of "price per million tokens" is becoming increasingly inaccurate.

The most noteworthy figure in the price comparison table above is DeepSeek's official "cached price of $0.0028," the lowest on the list. If a 95% or 99% cache hit rate can be achieved, DeepSeek’s $0.0028 price is nearly equivalent to receiving input tokens for free. Previously, users have tested and confirmed that DeepSeek can reach this hit rate.

The Zhihu answerer "Su Chi Dan Dao" conducted a test involving 20,000 experiments over three days, covering DeepSeek, Kimi, Zhipu GLM, MiniMax, and OpenAI models accessed via OpenRouter. The specific method involved sending 27 random requests to each model every 40 minutes, then resending the same content after intervals ranging from 1 minute to 720 minutes (i.e., up to 12 hours), recording whether the cache still hit, to minimize the impact of random fluctuations in system load.

The results show that DeepSeek performed the best, maintaining a 100% cache hit rate consistently during both working and non-working hours, with no significant expiration even after intervals of up to 12 hours. MiniMax ranked second, with a hit rate of approximately 90% during non-working hours and a drop to around 70% during working hours. Kimi and OpenAI showed moderate performance, while GLM performed the weakest, with a hit rate of about 80% after 2 minutes, falling to 50% after 3 minutes, and only 25% after 5 minutes—almost no cache entries survived beyond 15 minutes.

I believe there are two possible reasons for GLM's weaker performance: first, KV Cache relies heavily on VRAM and lacks the ability to persist to lower-cost storage media, leading to frequent cache eviction; second, the actual request volume exceeds the cache capacity, accelerating the expiration of older caches. However, these explanations are currently only speculative.

Therefore, using the cache hit rate provided by OpenRouter as a standardized benchmark, assuming DeepSeek’s official cache hit rate reaches 78.2% (actually higher), and the cache pricing is approximately one-tenth that of third-party platforms while all other prices remain unchanged, DeepSeek would need to increase prices for both Cache Hit and Cache Miss by roughly three times to match the overall pricing of third-party platforms; however, if only the Cached Read price is increased while standard input prices remain unchanged, it would require an increase of approximately 30 times to reach parity with third-party platforms.

Source: OpenRouter

This advantage stems from DeepSeek's architectural design.

The latest official caching documentation reveals three mechanisms for persisting cache prefixes. The first generates cache prefixes automatically at the end of user input and the end of model output for each request. The second is Common Prefix Detection: if the system identifies common prefixes across multiple requests, it proactively persists these shared prefixes separately. The third mechanism generates cache prefix units at fixed token intervals for extremely long inputs and outputs, avoiding the need to wait until a lengthy request completes before creating reusable cache entries. The Common Prefix Detection method directly improves actual cache hit rates. Unused cache entries are typically cleared after several hours to several days.

With the introduction of V4, the official implementation adopts "Token-wise Compression + DeepSeek Sparse Attention (DSA)," with the primary goal of further reducing the computational and memory costs associated with million-token contexts, making a 1-million-token context the standard configuration for all official services.

According to the vLLM team's breakdown of the V4 architecture, V4 not only shares Key/Value pairs but also further compresses the KV Cache across tokens—one mode achieves approximately 4x compression, while another reaches up to 128x. For a million-token context, the estimated BF16 KV Cache size is about 9.62 GiB, compared to 83.9 GiB for the V3.2 architecture—a reduction of roughly 8.7x. In actual deployment, FP4 is used to store the Indexer Cache and FP8 for the Attention Cache, further reducing cache memory usage by approximately half.

But how long this advantage will last is also a question worth considering.

Today, dax posted that over the past 48 hours, DeepSeek received more traffic than any other platform. This traffic came from a variety of different clients, not just OpenCode. He provided cache hit rates for several platforms:

However, there can be differences in quality between third parties and official sources.

Developers have repeatedly tested and found that DeepSeek V4 Flash routed through OpenCode has an effective context window of approximately 600k; beyond this, OpenCode applies some form of compression or truncation. In contrast, the official version supports the full 1M context window, offering more comprehensive capabilities and stronger performance. “The wide variation in evaluations of DeepSeek’s capabilities may also stem from this difference.”

V4-Flash-0731 did not expand the base model size and retains the original model architecture; the main changes come from retraining and Agent adaptation. In other words, when DeepSeek demonstrates “why V4 Flash suddenly has such strong Coding Agent capabilities,” it effectively combines two factors: model post-training and DeepSeek’s own Harness.

The developer found in practical use that the same DeepSeek V4 Flash model may exhibit significantly different performance across various AI coding tools. Their experience shows that DeepSeek V4 Flash performs nearly on par with Fable 5 in Codex, but in the OpenCode environment, it only achieves about half of its true capability.

This difference is primarily reflected in two aspects. First, the ability to comprehensively understand the problem. In Codex, DeepSeek V4 Flash demonstrates significantly better code comprehension and a stronger grasp of the overall problem, making it less likely to focus solely on local details while neglecting the broader system. In contrast, when running in OpenCode, the model is more prone to getting caught up in local details, which can impair its judgment of the overall task.

The second difference lies in memory coherence during long-term tasks. Complex software development tasks often involve numerous interrelated issues, where local optima do not necessarily lead to global optima. After resolving a local issue, new global problems may emerge, causing the Agent to cycle repeatedly between different solutions—and sometimes even produce invalid solutions by the task’s end. Developers report that such issues remain fairly common with DeepSeek on OpenCode.

However, in Codex, DeepSeek V4 Flash rarely encounters such issues. Even when the task execution chain is very long, the model remains capable of understanding the original objective and is unlikely to deviate from the overall task direction due to solving numerous local problems—essentially, “no matter how far it goes, it never forgets why it started.”

In fact, DeepSeek's official team previously released a Codex integration document that provided a complete models.json configuration, enabling Codex to understand how to effectively utilize V4 Flash.

This configuration reveals certain Harness-level adaptation details. For example, V4 Flash is configured in Codex to support parallel tool calls, a context length of approximately 1.04 million tokens, and a 95% effective context window. It also defines freely formatted tools such as apply_patch and Web Search. The documentation even explicitly outlines compaction behavior during long tasks—how to compress history when the context becomes too long and how to resume the task after compression rather than restarting from the beginning.

This also shifts the developer’s focus further from the model itself to Harness. A mature Harness involves numerous mechanisms such as message routing, memory management, optimization and invocation of long- and short-term memory, and tool usage—capabilities that typically emerge from prolonged, iterative engineering experimentation and refinement. Moreover, the relevant SDKs do not fully disclose all implementation details and techniques.

Therefore, in its view, future competition among AI coding products may no longer be solely about the intelligence of the models. The harness systems built around the models—and the accumulated capabilities in message routing, memory management, and tool invocation—may form a deeper moat than the models themselves.