DeepSeek Raised Its Prices — I Found the Same V4 Flash Cheaper Than the Old Rate

On the morning of August 17, I opened my API usage statistics and initially assumed I had made a mistake somewhere.

DeepSeek was consuming money roughly five times faster than I was used to.

I knew a pricing change was coming. DeepSeek had announced it several days earlier, but I mentally filed it under a normal price increase: perhaps 20%, 50%, maybe even double.

Not this much.

There was no billing bug. The new rates had taken effect. DeepSeek officially moved V4 Flash and V4 Pro to peak/off-peak pricing from 16:00 UTC on August 16, which was already August 17 in China. Reuters had reported before the change that, depending on the model, token type and time of day, increases would range from 50% to 1,100%. The timing is documented in the DeepSeek API change log.

That was when another DeepSeek announcement suddenly became much more interesting to me: the model weights were available publicly. If other companies could run the same model themselves, why did I have to buy inference directly from DeepSeek?

What DeepSeek cost before, and what it costs now

Before the pricing change, DeepSeek V4 Flash cost:

Those figures are preserved on an older DeepSeek pricing page, and Reuters also cited the same rates on August 3.

The official deepseek-v4-flash, corresponding to DeepSeek-V4-Flash-0731, now costs:

Peak periods run from 01:00 to 04:00 UTC and from 06:00 to 10:00 UTC according to the current DeepSeek pricing page.

So my observation that the bill was roughly five times higher does not mean every token category became exactly five times more expensive. Compared with the old price:

• peak cache-miss input rose from $0.14 to $0.44, or 3.14×;
• output rose from $0.28 to $1.32, or 4.71×;
• cache hits rose from $0.0028 to $0.014, exactly 5×.

For a workload that generates a lot of output, a near-fivefold increase in actual spending is therefore entirely plausible.

I looked for another seller of the same model first

I could simply have abandoned DeepSeek. There are many other LLMs now: Qwen, GLM, Kimi, MiniMax, Mistral and plenty more.

But changing models introduces another variable. Responses, prompt compatibility, generation length, long-context behavior, sampling parameters and other characteristics all need to be checked again.

I wanted to test a simpler idea first.

Could I keep DeepSeek V4 Flash but stop buying its inference from DeepSeek?

There is an important terminology point here. DeepSeek did not merely publish the “source code of the neural network” in the same sense that a developer publishes an application's source tree. The more accurate description is that DeepSeek published the model weights and the materials needed to run them.

The official deepseek-ai/DeepSeek-V4-Flash-0731 repository is publicly available on Hugging Face. The repository and weights use the MIT License, and DeepSeek even provides an example of running the model through vLLM on one node with four GB300 GPUs.

That changes the economics. A third-party provider does not necessarily have to buy DeepSeek tokens and resell them with a markup. It can run the open weights on its own infrastructure and sell compute on its own hardware.

Of course, saying “just run DeepSeek locally” makes the task sound easier than it is. The 0731 repository is around 167 GB, and the official deployment example uses four GB300s. This is not docker compose up on a $20 VPS. The repository files are visible on the model file page.

For an inference company with a GPU cluster, however, the problem is very different. The license is no longer the main barrier. The remaining problems are hardware, electricity, GPU utilization, batching, the software stack and inference efficiency.

I found Runware

After a long search, one of the most interesting options I found was Runware.

How did I find it? I used my favorite research workflow: first I asked an AI to write a detailed prompt for finding the cheapest credible inference provider for this exact model. Then I ran roughly 15–20 separate searches with that prompt, collected the results, dropped all of them into one final chat, and asked it to compare the candidates and identify the strongest option. Only after that did I check the winner manually: the model page, pricing, documentation and the API itself.

The AI helped me widen the search, but it did not make the final decision for me. Runware survived the manual check, I connected it myself, and the recommendation here is based on that test.

It currently offers the exact DeepSeek-V4-Flash-0731 checkpoint with a 1M context window, rather than an unnamed “DeepSeek-compatible” model. Its model page lists the following prices:

I initially thought I had misplaced a decimal point.

But the more useful comparison is not with DeepSeek's new expensive rates. It is with the old rates that had already seemed cheap.

Old DeepSeek input was $0.14. Runware input is $0.076. Runware is therefore about 45.7% cheaper, while the old DeepSeek price was about 1.84× higher.

Old DeepSeek output was $0.28. Runware output is $0.153. That makes Runware about 45.4% cheaper, while old DeepSeek was about 1.83× higher.

After a major price increase, I found a third-party API serving the same V4 Flash 0731 checkpoint that was not merely cheaper than the new DeepSeek API. It was almost twice as cheap as the old, inexpensive DeepSeek.

Compared with today's official DeepSeek pricing, the gap is even larger. During off-peak periods, Runware is roughly 2.9× cheaper on cache-miss input and 4.3× cheaper on output. During peak periods, the differences are roughly 5.8× and 8.6×.

There is one important exception: cheap cache hits. DeepSeek currently charges $0.007/M for off-peak cached input, while Runware charges $0.014/M. A workload dominated by cache hits therefore cannot be compared using only ordinary input and output prices.

A low price is meaningless if the API does not work

A pricing table alone is not enough for me. An LLM API costing $0.000001 per request is useless if half the requests fail.

So I connected Runware and started sending real requests.

I kept two snapshots of the usage dashboard. The first showed:

790 requests
56 success
734 errors

That looks terrible on its own. Later, however, the dashboard showed:

1,570 requests
836 success
734 errors

Between those two measurements, the counters changed by exactly:

+780 requests
+780 successful
+0 new errors

I do not treat this as proof of 99.999% uptime. It proves nothing of the sort, and those two snapshots do not tell me what caused the original 734 errors.

What I can say is narrower: during the next 780 requests, the successful counter increased by 780 while the error counter did not move at all.

The API was also fast in that test window. In the visible request log, most successful calls completed in fractions of a second to roughly 1.5 seconds. Individual short requests I could see often cost around $0.000005–$0.000018. After hundreds of successful calls, the dashboard still showed total spending of only about one cent.

That was the point at which Runware stopped being just a line in a comparison table for me. I had actually connected the API, it generated responses, and my test traffic cost almost nothing.

This is not an ad — and I have only been testing Runware for one day

I want to make this explicit because a positive section about one provider can easily read like sponsored copy. It is not. Runware did not contact me, and I did not contact Runware. Nobody there asked me to write this article.

I have also been using the service for only one day. I may leave in a week or a month if reliability, response quality, pricing or something else turns out to be worse than it looks today. This is not a long-term verdict.

I switched away from the expensive official DeepSeek API immediately because I did not want to keep burning money at the new rates while I evaluated alternatives. Instead, I moved the traffic and started testing Runware right away.

So far I am very happy with that decision. By the time I was finishing this article, the number of successful AI requests through Runware had already reached 1,000. That still does not prove future uptime or performance at every scale, but it is enough for me to say that this is not a provider I merely found on a pricing page: I am actually using it.

So my recommendation is deliberately narrow: I checked Runware myself, it is working well for me today, and at the moment I would recommend trying it. If the service changes, my opinion can change too.

DeepSeek may have created its own price competitor

From here on, this is interpretation rather than an observed fact.

DeepSeek has put itself in an unusual business position. It did two things: it released a highly competitive model, and it gave the market the ability to run that model independently.

While the official DeepSeek API was extremely cheap, there was little tension. Why search for somebody else's GPU cluster when DeepSeek itself sold inference for $0.14/$0.28?

After the price increase, that calculation changes. If the official API reaches $0.44 input and $1.32 output during peak periods, while an independent provider serves the same public checkpoint for $0.076/$0.153, the economic incentive to try the alternative becomes strong.

This is not an accidental loophole. The MIT license on the published weights permits broad use, including commercial use, and the official repository contains self-hosting instructions.

That is why I would not describe Runware simply as a “reseller of DeepSeek tokens.” A more accurate picture is:

DeepSeek
    │
    ├── official DeepSeek API
    │
    └── open DeepSeek V4 Flash weights
                   │
                   ├── Runware infrastructure
                   ├── other inference providers
                   └── your own GPU cluster

The same model is no longer tied to one inference seller.

Was releasing the weights a business mistake?

I would not state that as a fact.

It would be too simplistic to say that DeepSeek opened the model, competitors can now sell it more cheaply, and therefore DeepSeek must lose money. We do not know the company's internal economics.

An open-weight strategy can have other benefits:

• wider model distribution;
• more integrations;
• greater influence over the ecosystem;
• the chance to become a de facto standard in third-party products;
• more developers;
• enterprise adoption;
• research popularity;
• pressure on competitors.

Reuters has also noted the broader emphasis among Chinese model developers on open-weight approaches as a way to achieve wide developer adoption in its coverage of the Chinese AI market.

So it is too early for me to call the decision a business mistake. I am comfortable with a narrower conclusion:

By opening the weights, DeepSeek voluntarily gave up a monopoly on inference for its own model.

When the official API becomes much more expensive, the consequences of that choice become far more visible. DeepSeek is no longer competing only with Qwen, OpenAI, Anthropic or Moonshot. In a sense, it is also competing with companies selling inference for DeepSeek's own open model.

That is excellent for API buyers. For monetization strategy, it is much more complicated.

Why I am not self-hosting DeepSeek

The next thought is obvious: if third-party companies can run DeepSeek and sell inference, why not do the same myself?

Because there is a huge gap between “the model is free to download” and “inference is free.”

The weights can be downloaded. GPUs cannot.

You need to buy or rent expensive hardware, provide enough VRAM, load a huge checkpoint, configure the inference engine, batching, KV cache, monitoring, scaling and redundancy, and then generate enough traffic to keep those GPUs busy.

The official DeepSeek example for V4 Flash 0731 uses one node with four GB300 GPUs.

For a specialized inference provider, that investment can make sense because infrastructure cost is spread across many customers. For one developer, paying $0.076 per million input tokens may be much more rational than investing a large amount of money in GPUs and then trying to maintain high utilization.

For now, I prefer buying inference. But I understand much better what I am actually buying.

The main lesson I took from that morning

At the start of the day, I thought about DeepSeek like a normal SaaS API: there is a DeepSeek model, so DeepSeek determines what it costs to use it.

By the end of the day, my mental model was different: there is a DeepSeek checkpoint, and there is a competitive market of companies willing to run that checkpoint for me.

Those are fundamentally different markets.

With a closed model, API pricing is largely controlled by the model owner. With permissively licensed open weights, inference pricing is also shaped by competition between infrastructure providers.

For me, that difference became very concrete on August 17. Old DeepSeek V4 Flash cost $0.14 input and $0.28 output. The new official DeepSeek price reaches $0.44/$1.32 during peak periods. Runware currently offers DeepSeek-V4-Flash-0731 for $0.076/$0.153.

I have tested that API myself, and it works for the traffic I sent to it.

Will those prices still be the same in a month? I do not know. Will the same provider handle every possible scale and traffic profile? I have not proven that either.

But one thing has changed for me: after this price increase, I no longer assume that the official API of an open-weight model's creator is automatically the best place to buy inference.

My first step now is to check who else can run the same weights, and what they charge for doing it.