DeepSeek changed its API pricing, and my spending jumped almost overnight. Instead of replacing the model, I tried something simpler: keep the exact same V4 Flash checkpoint and move the inference somewhere else.

On August 17, I checked my API usage and initially assumed something in my application had gone wrong.

The balance was disappearing much faster than usual.

Not a little faster.

Roughly five times faster.

I already knew DeepSeek had announced a pricing change. I had seen the announcement a few days earlier, but I did not expect it to have such a large effect on my actual usage.

A 20% increase would have been annoying.

A 50% increase would have been noticeable.

Even doubling the price would not have surprised me that much.

But this was enough to make me stop and look at the numbers properly.

There was nothing wrong with my billing integration.

The new prices were simply live.

DeepSeek introduced peak and off-peak pricing for V4 Flash and V4 Pro starting at 16:00 UTC on August 16. Reuters had already reported that some DeepSeek prices were increasing anywhere from 50% to 1,100%, depending on the model, token type and time of day.

That was when I remembered an important detail.

DeepSeek V4 Flash is available as an open-weight model.

And that changes the problem completely.

Instead of asking:

Should I replace DeepSeek with another model?

I started asking:

Can I keep exactly the same model and just stop buying the inference from DeepSeek?

That turned out to be the more interesting question.

The old DeepSeek pricing was extremely cheap

Before the change, V4 Flash had pricing that was difficult to complain about.

That is the pricing I had become used to.

The current official deepseek-v4-flash, which corresponds to DeepSeek-V4-Flash-0731, now has separate off-peak and peak rates.

Off-peak

Peak

DeepSeek currently lists the peak windows as:

• 01:00 to 04:00 UTC
• 06:00 to 10:00 UTC

My own spending being close to five times higher does not mean every possible DeepSeek request is exactly five times more expensive.

The actual increases depend on what kind of tokens you are paying for.

For example:

• cache-miss input went from $0.14 to $0.44 at peak, about 3.14x
• output went from $0.28 to $1.32 at peak, about 4.71x
• cached input went from $0.0028 to $0.014 at peak, exactly 5x

If your application generates a lot of output, a bill that feels close to five times larger is not difficult to explain.

I did not want to keep paying those rates while spending several days slowly evaluating alternatives.

So I started searching immediately.

Changing providers is much easier than changing models

There are plenty of models I could have tested instead.

Qwen.

GLM.

Kimi.

MiniMax.

Mistral.

And many more.

But changing an LLM in a real application is not always a one-line configuration change.

Even when the API format is similar, behavior can move in ways that matter.

Prompts may need adjustment.

Answers may become longer or shorter.

The tone can change.

Sampling settings that worked well before may no longer be ideal.

Long-context behavior can differ.

Edge cases appear.

If the current model already works well, replacing it creates a new testing problem.

I wanted to avoid that problem.

My goal became very specific:

Keep DeepSeek V4 Flash 0731. Change only the infrastructure serving it.

Open weights create a separate inference market

This is the part I think developers sometimes overlook.

DeepSeek published the deepseek-ai/DeepSeek-V4-Flash-0731 checkpoint publicly on Hugging Face under the MIT License.

The weights are available.

Deployment information is available.

DeepSeek even documents a deployment example using vLLM on a single node with four GB300 GPUs.

So an inference company does not necessarily need to purchase API tokens from DeepSeek and resell those tokens to you.

It can operate the model itself.

Conceptually, I used to think about DeepSeek like this:

Application
    |
    v
DeepSeek API
    |
    v
DeepSeek V4 Flash

But with public weights, the picture is closer to this:

                  DeepSeek V4 Flash weights
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
    DeepSeek API        Runware       Other providers
                                            |
                                            v
                                      Self-hosting too

DeepSeek created the model.

That does not mean DeepSeek has to be the only company selling inference for it.

Those are now two separate things.

And once I started looking at the market that way, the pricing became much more interesting.

How I searched for providers

I did not start with a list of famous inference companies.

I wanted to search broadly because smaller providers are often where the interesting prices are.

My process was basically this:

1. Ask an AI to help me create a very detailed research prompt.
2. Run that research repeatedly, usually around 15 to 20 separate searches.
3. Combine the results into one conversation.
4. Compare the providers.
5. Remove obviously unsuitable options.
6. Build a shortlist.
7. Verify the finalists manually.

I do not treat the AI's final ranking as truth.

That would be a mistake.

The useful part is breadth.

It can surface providers I would probably never discover by manually searching through the same five well-known companies.

Once I get to the shortlist, I check everything myself.

I open the provider's website.

I read the documentation.

I verify the model identifier.

I check the actual pricing.

And if it looks promising, I send real API requests.

That process eventually led me to Runware.

Runware was serving the exact checkpoint

The important part was not merely that Runware supported "DeepSeek."

It offered:

DeepSeek-V4-Flash-0731

That is what I wanted.

I was specifically trying to avoid introducing another model variable into the test.

At the time I checked, Runware's pricing for the checkpoint was:

The first time I saw those numbers, I checked them again.

Not because Runware was cheaper than the new DeepSeek pricing.

I expected that.

What surprised me was that it was also substantially cheaper than the old DeepSeek pricing.

It was cheaper than DeepSeek before the increase

Take input first.

Old DeepSeek:

$0.14 / 1M

Runware:

$0.076 / 1M

That makes Runware roughly 45.7% cheaper.

Or viewed from the other direction, the old DeepSeek price was around 1.84x higher.

Now output.

Old DeepSeek:

$0.28 / 1M

Runware:

$0.153 / 1M

That is approximately 45.4% cheaper.

The old DeepSeek rate was about 1.83x higher.

This was the part I did not expect.

Finding a provider cheaper than DeepSeek after a major price increase is not surprising.

Finding the exact same public checkpoint for around 45% less than DeepSeek charged before the increase is much more interesting.

Against the new DeepSeek prices, the gap gets huge

For normal cache-miss input and output, the difference is now much larger.

DeepSeek off-peak vs Runware

Input:

$0.22 / $0.076 = ~2.9x

Output:

$0.66 / $0.153 = ~4.3x

DeepSeek peak vs Runware

Input:

$0.44 / $0.076 = ~5.8x

Output:

$1.32 / $0.153 = ~8.6x

There is one important exception.

DeepSeek's off-peak cached input currently costs:

$0.007 / 1M

Runware's cached input costs:

$0.014 / 1M

So DeepSeek is cheaper for that particular category during off-peak hours.

This is why comparing only one headline number can be misleading.

Your real cost depends on your own traffic.

An application with very high cache-hit rates may reach a different conclusion from an application generating large amounts of output.

Cheap pricing means nothing if the API is unreliable

At this point I still had no reason to trust Runware.

A pricing page is not a benchmark.

And cheap tokens are worthless if requests fail constantly.

So I funded the account, connected the API and started sending actual traffic.

One early dashboard snapshot looked like this:

790 requests
56 success
734 errors

Which looks awful.

Later I checked again:

1,570 requests
836 success
734 errors

The difference between those snapshots was:

+780 requests
+780 successful
+0 new errors

I want to be precise about what I am claiming here.

This does not prove some ridiculous five-nines reliability number.

It also does not tell us why the original 734 requests failed.

What it does tell me is very simple:

During the next batch of 780 requests, the success counter increased by 780 and the error counter did not increase at all.

I continued testing after that.

At the time I am writing this, I have already passed 1,000 successful AI requests through the Runware endpoint.

So far, the experience has been good.

The latency surprised me too

I was mostly looking for price differences.

Latency was secondary.

But the successful requests I checked were generally fast.

Most completed in somewhere between a fraction of a second and roughly 1.5 seconds.

Some of the smaller requests were costing around:

$0.000005

to:

$0.000018

per request.

After hundreds of successful calls, the total displayed spending was still around one cent.

That is when the comparison stopped feeling theoretical.

This was no longer:

Provider A says it costs X and Provider B says it costs Y.

The endpoint was connected to my application.

Requests were completing.

Responses were coming back quickly.

And the cost was tiny.

A necessary disclaimer about Runware

I want to be explicit about this because I am naming one company repeatedly.

This article is not sponsored.

Runware did not contact me.

I did not contact them before writing this.

Nobody asked me to publish anything.

I have no affiliate agreement.

No referral deal.

No discount code.

No free credits.

I found Runware while researching inference providers, created an account, deposited my own money and tested the API.

That is the entire relationship.

There is another important disclaimer.

I have been testing it for one day.

That is nowhere near enough time to declare a provider the best option on the market.

Maybe I discover reliability issues later.

Maybe its pricing changes.

Maybe performance gets worse.

Maybe another provider appears next week with better infrastructure and an even lower price.

If that happens, I will switch again.

I am not loyal to an inference endpoint.

I moved because DeepSeek's new pricing made me reconsider where I was buying compute.

Runware happened to be the provider that looked good enough to test immediately.

So far:

• more than 1,000 requests have completed successfully
• latency has been good in my testing
• pricing is extremely low
• the first day has gone well

That is the extent of my claim.

DeepSeek is now competing with companies that run DeepSeek

This is the most interesting part of the whole situation to me.

DeepSeek built the model.

Then it published the weights under a permissive license.

That means infrastructure companies can take the same model and compete on:

• GPU utilization
• batching
• serving software
• capacity planning
• margins
• geographic infrastructure
• latency
• reliability
• pricing

In other words, DeepSeek is not only competing with Qwen, OpenAI, Anthropic, Mistral or other model developers.

For inference revenue, it can also end up competing with companies serving DeepSeek's own model.

When official V4 Flash inference cost $0.14 for input and $0.28 for output, that competition was easy to ignore.

The official API was already extremely cheap.

But when peak pricing becomes $0.44 input and $1.32 output while another provider offers the same checkpoint at $0.076 and $0.153, the infrastructure market starts to matter a lot more.

This is also why I do not think "Runware is reselling DeepSeek" is necessarily the right way to think about it.

If a provider is running public weights on its own hardware, then what you are purchasing is its inference infrastructure.

The model came from DeepSeek.

The compute came from someone else.

Did DeepSeek make a mistake by releasing the weights?

I do not think the answer is obvious.

It is tempting to look at these price differences and say:

DeepSeek created competitors for its own API business.

That is true in one narrow sense.

But open-weight models also gain advantages that closed models do not.

More developers can experiment with them.

More companies can integrate them.

Cloud providers can support them.

Inference platforms can optimize them.

Researchers can use them.

Businesses can deploy them privately.

The model can spread into places where a single proprietary API never would.

That adoption has value.

So I am not arguing that releasing V4 Flash was a bad business decision.

The claim I am comfortable making is much narrower:

Once a model's weights are publicly available under a permissive license, the company that created the model is no longer the only company capable of selling access to its inference.

When the creator's API is the cheapest and easiest option, nobody cares.

When the creator raises prices significantly, people start looking around.

I certainly did.

Why not just self-host V4 Flash?

I also considered the obvious next step.

If Runware can download the model and run it, why not do the same thing myself?

Because running a model like this is not the same thing as deploying a Node.js service onto a $20 VPS.

The model repository itself is large.

DeepSeek's own deployment example mentions four GB300 GPUs on one node.

And GPUs are only one part of the system.

You also need to think about:

• enough VRAM
• inference engines
• model loading
• batching
• KV cache management
• concurrency
• networking
• monitoring
• capacity planning
• failover
• power
• cooling
• maintenance
• keeping expensive GPUs utilized

Self-hosting can absolutely make sense at sufficient scale.

But there is a huge difference between:

I can download the weights.

and:

I can serve this model economically in production.

An inference provider can spread the cost of its hardware across many customers.

For my current usage, I cannot.

If somebody is willing to serve the model to me for $0.076 per million input tokens, buying the API can be much more rational than building the infrastructure myself.

If I had enough GPUs and capital, though, I would absolutely be interested in this market.

Running open models efficiently and selling inference is an interesting infrastructure business.

I just do not need to own that infrastructure today.

What I am changing after this

The main lesson for me is not specifically "use Runware."

That could change next week.

The bigger change is how I evaluate open-weight APIs.

Before this, my mental model was basically:

DeepSeek built the model
        ↓
DeepSeek sells the API
        ↓
That is the price of DeepSeek

Now I think about it more like:

Model creator
     ↓
Public weights
     ↓
Many companies compete to serve them
     ↓
Different prices, latency and reliability

And the numbers make the distinction hard to ignore.

Old DeepSeek V4 Flash:

Input:  $0.14 / 1M
Output: $0.28 / 1M

New DeepSeek peak pricing:

Input:  $0.44 / 1M
Output: $1.32 / 1M

Runware when I tested it:

Input:  $0.076 / 1M
Output: $0.153 / 1M

And I have already sent more than 1,000 successful AI requests through that endpoint.

Will I still use it a month from now?

Maybe.

Maybe not.

What I will definitely keep doing is this:

When a model has public weights, I will no longer assume that the model creator automatically has the best inference API.

I will identify the exact checkpoint.

I will find out who else serves it.

I will compare the real token pricing.

And then I will send actual requests before making a decision.

That is how I found a cheaper way to keep using DeepSeek V4 Flash without changing the model at all.

deepseek #ai #llm #api