DeepSeek’s price debate turns on the bill for useful work

Original research record

We see a new DeepSeek discussion asking why cheap token prices produce very different user bills. Participants disagree about subscription value, cache reuse and provider choice. We read this as a demand for clearer usage evidence: compare the same completed task, its total cost and its result. One selected conversation cannot establish typical savings, broad adoption or public sentiment.

One participant reports spending $50 in a few days through an unnamed OpenRouter provider. Another reports stretching a $100 balance from July across several DeepSeek versions and still having $16 left. These are unverified accounts of different workloads and periods, not a controlled price comparison. [Higher-spend account](https://news.ycombinator.com/item?id=50012463) [Longer-use account](https://news.ycombinator.com/item?id=50012838)

Replies ask how often earlier input is reused from a cache. The official direct API lists off-peak DeepSeek-V4.1-Flash rates of US$0.003 per million cached input tokens, US$0.15 per million uncached input tokens and US$0.60 per million output tokens. Cached and uncached input therefore have a 50-fold rate difference. That is not a 50-fold saving on a whole job, which also includes fresh input and generated output. The page lists different peak rates. [Official price basis](https://api-docs.deepseek.com/quick_start/pricing/)

OTR Database Data already separates generation cost from full-task cost and warns that delayed background work can fall outside a task total. Its latest research also calls for price-and-quality comparisons using identical test cases. We connect those accounting checks with this new discussion: record the actual provider, cached and fresh input, output, retries, background work, total bill and accepted result for the same task. This adds a cache-and-provider check to the earlier cost boundary. It is our proposed test, not a measured DeepSeek benchmark.

Key points At 22:50:42 UTC on 8 October, the native thread showed 291 points and 253 comments. We read the first displayed cost-discussion branch: 30 comment bodies from 27 handles, posted between 21:20:17 and 22:48:39 UTC. Handles are not verified unique people. The original submission was posted at 00:14:48 UTC. The new evidence is the later reply branch, after the previous edition’s 20:17 UTC cutoff. We use absolute native and API clocks, not the page’s relative age label. Commenters report different cache rates and billing periods. Some describe cached input tokens; another describes requests. Those percentages have different denominators and cannot be pooled. Official documentation supports cache-sensitive billing. It does not verify the commenters’ invoices, completed work or provider comparisons. We measured no platform-wide sentiment or engagement growth.

What could change this view? The cheapest useful option can differ by workload. A participant explicitly cannot separate the effects of the provider from the coding tool around it. OpenRouter’s documentation already describes keeping requests with the same provider to preserve cache use, with fallback if that provider is unavailable. DeepSeek says cache hits are best-effort. The discussion therefore does not establish that one route always costs more, that a provider overcharged anyone, or that subscriptions always win. Matched invoices and accepted outputs could weaken or strengthen our reading. [Unresolved provider-versus-tool comparison](https://news.ycombinator.com/item?id=50013489) [OpenRouter caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching) [DeepSeek caching](https://api-docs.deepseek.com/guides/kv_cache/)

Bottom line We would compare the bill for a completed, checked task before switching services because of a token-price headline. The useful signal is the set of missing measurements that participants are asking about. We cannot infer an industry-wide move towards or away from DeepSeek.

How likely is this call? · Three frameworks This signal has no investible bullish or bearish call. A market-direction percentage does not apply. We describe observed discussion and a proposed way to test its claims. Bayesian · what changed the estimate? New replies identify competing explanations for reported bills: cache reuse, provider route, subscription terms and the work being done. Official billing rules make cache reuse a plausible mechanism. Without matched records or fitted likelihoods, we make no numerical update and no claim that it explains a particular invoice. de Finetti · are the comparisons fair? A few days of spending, a balance used since July and a monthly subscription cover different periods and tasks. The comments influence one another inside one thread. We do not treat them as independent, interchangeable trials or pool request-based and token-based cache percentages. Kolmogorov · do the numbers agree? Bullish, Bearish, Neutral, market horizon and neutral band are Not applicable. The 50-fold figure divides two input-token rates under the same off-peak schedule. It is neither a probability nor total-job savings. Points, comments and handles cannot be added into an audience total.

Evidence behind this view We retained the native thread at 2026-10-08T22:50:42.335831+00:00, with 291 points and 253 displayed whole-thread comments. The parsed page contained 248 visible comment bodies, of which the first displayed cost branch’s 30 bodies were semantically read. We do not treat the remaining bodies as read or explain the five-count difference without evidence. Eleven selected comments and the original submission were also checked through the official API. All comments share one conversation. DeepSeek and OpenRouter documentation explain their own mechanisms; they do not independently audit these users. [Native thread](https://news.ycombinator.com/item?id=50000488)

What past price moves show Market-price history is not applicable. Earlier OTR records covered Beam’s generation-only cost estimate, task ownership in HydraFusion usage totals, and local hardware costs. They supply comparison questions, not a measured DeepSeek billing baseline. Earlier DeepSeek memory and runtime records address separate mechanisms. We have no matched history linking this discussion’s engagement to later usage or provider switching.

Evidence against this view The cheapest useful option can differ by workload. A participant explicitly cannot separate the effects of the provider from the coding tool around it. OpenRouter’s documentation already describes keeping requests with the same provider to preserve cache use, with fallback if that provider is unavailable. DeepSeek says cache hits are best-effort. The discussion therefore does not establish that one route always costs more, that a provider overcharged anyone, or that subscriptions always win. Matched invoices and accepted outputs could weaken or strengthen our reading. [Unresolved provider-versus-tool comparison](https://news.ycombinator.com/item?id=50013489) [OpenRouter caching](https://openrouter.ai/docs/guides/best-practices/prompt-caching) [DeepSeek caching](https://api-docs.deepseek.com/guides/kv_cache/)

Why the direction changed No investment direction is issued or changed. We add a newly reviewed 8 October cost-and-cache reply branch to an earlier same-day submission. We do not present the submission, model or price schedule as newly launched after the previous edition.

What people say vs the facts We separate spending claims from billing evidence. A reported high cache-hit rate is not a typical-user measurement. One participant asks which provider was used; another compares published prices, but no matched invoice settles the dispute. Claims about subsidies, provider profits or overcharging remain unsupported by this sample. [Provider question](https://news.ycombinator.com/item?id=50012779) [Price comparison](https://news.ycombinator.com/item?id=50012883)

How past forecasts performed We have no resolved forecast sample for this discussion and publish no savings probability, sentiment percentage, adoption estimate or virality claim. Points and comments are different platform actions. The first displayed branch is a convenience sample, not a random or population sample.