One Model, 16 Prices: DeepSeek V4 Pro Costs 4x More Depending on Which Server Answers

The routing table nobody reads

DeepSeek V4 Pro is open-weight. Anyone can download the checkpoint, and 16 different infrastructure companies currently do, hosting the identical file and renting API access to it: DeepSeek itself, Baseten, Together, DigitalOcean, and a dozen others. Calling any of them through an OpenAI-compatible endpoint should, in theory, return the same completion for the same prompt at the same temperature. What it does not guarantee is the same price, the same latency, or the same uptime, because those three numbers are not properties of the model. They are properties of whoever is running the GPUs that day.

On July 13, 2026, OpenRouter's own blog published the actual spread across those 16 providers, and the numbers are not a rounding error. This piece walks through the full data set, cross-checks it against a second, independently run benchmark from Artificial Analysis, and ends with the exact API field that fixes it, in case your integration has been hardcoded to one provider since the day someone first pasted a base URL into an environment variable.

The 4x you are not supposed to notice

Start with price, because it is the easiest number to check and the one most teams assume is fixed once they have picked a model. Input tokens on DeepSeek V4 Pro, routed to DeepSeek's own infrastructure, cost $0.435 per million. Route the identical request to Baseten or Together instead and the same tokens cost $1.74 per million, exactly 4x more, for byte-identical output.

That gap is invisible on a typical integration, because most codebases call OpenRouter (or any multi-provider gateway) with load balancing left on defaults, which mixes traffic across providers to optimize for uptime, not price. A meaningful share of that traffic is quietly landing on the $1.74 tier without anyone deciding it should.

The 14x that actually costs you

Price is the boring half of the story. Throughput is the half that shows up as a support ticket. OpenRouter clocked the slowest DeepSeek V4 Pro provider, DigitalOcean, at 4 tokens per second. The fastest, Baseten, hit 57 tokens per second, a 14.25x gap on raw generation speed, same weights, same day.

Convert that into wall-clock time and it stops being an abstraction. A 500-token reply takes roughly 9 seconds at 57 tokens/sec and roughly 2 minutes at 4 tokens/sec. For a chat product, that is the difference between a response that feels instant and one that feels broken. For an agent loop making a dozen sequential calls, the 4-tok/s provider turns a 2-minute task into a 24-minute one, and nothing in the error logs says why.

Two benchmarks, same verdict

A single source publishing a surprising number is a claim. A second, independently run measurement landing on the same shape is evidence. Artificial Analysis runs its own provider benchmarking harness, separate from OpenRouter's production traffic telemetry, and its DeepSeek V4 provider comparisons show the identical pattern: fastest-to-slowest throughput spreads of 530% to 866% depending on the specific V4 variant (Pro, Flash, max/high reasoning effort).

The exact multiplier differs because the two organizations measure different traffic under different load conditions, which is expected. What does not differ is the conclusion: which provider answers a DeepSeek V4 call is not a minor implementation detail. It is one of the largest levers on both cost and latency available to anyone calling this model, and it is a lever most integrations never touch after the first day of setup.

Why identical weights produce different economics

The spread is not a bug in anyone's pricing page, and it is not evidence that one provider is running a worse copy of the model. Same checkpoint, same tokenizer, same logits. What differs is everything wrapped around the weights: how much GPU capacity a provider has reserved versus rented on demand, what batch size they run to keep utilization high, whether they serve the model at full precision or a quantized variant tuned for throughput, and how close their datacenter sits to the request origin. A provider running DeepSeek V4 Pro on spare capacity between other workloads can afford to undercut on price because the marginal cost of an idle GPU is close to zero, but that same provider has no incentive to hold request queues short, which is where the throughput gap comes from.

None of that is visible from an API response. A completion from the $0.435 tier and a completion from the $1.74 tier look identical in the response body: same schema, same finish reason, same token count. The only place the difference shows up is the invoice and the clock, which is exactly why it survives unnoticed in production for so long. Nobody diffs two API responses looking for a pricing bug when both responses are correct.

The uptime tax nobody budgets for

The third number matters less on a demo and more at 2am, when an agent is mid-task and a request just times out. DeepSeek's own infrastructure ran at 99.92% uptime in OpenRouter's measurement window. Together ran at 97.44%.

# uptime_cost.py — a 2.48-point uptime gap, converted to hours
HOURS_PER_YEAR = 24 * 365

def downtime_hours(uptime_pct: float) -> float:
    return HOURS_PER_YEAR * (1 - uptime_pct / 100)

print(f"Together   (97.44%): {downtime_hours(97.44):.0f} hours/year down")
print(f"DeepSeek   (99.92%): {downtime_hours(99.92):.0f} hours/year down")

$ python uptime_cost.py
Together   (97.44%): 224 hours/year down
DeepSeek   (99.92%): 7 hours/year down

⚠ FIX: a 2.48-point uptime gap between providers compounds to roughly
  9 extra days of downtime a year on the slower one.

A 2.48-point gap on a percentage sounds small until it is converted into hours. It works out to roughly 224 hours, over 9 full days, of extra downtime a year on the low-uptime provider, on a model that a meaningful share of the industry is actively calling in production.

Not a niche model

None of this is a fringe-case warning about an obscure endpoint. DeepSeek V4 Flash and V4 Pro are currently the 3rd and 6th most-used models on OpenRouter, across every lab, every model, every provider on the platform. DeepSeek alone accounts for 16.7% of all tokensrouted through OpenRouter. That is a meaningful fraction of one platform's entire inference volume, quietly split across a 4x price band and a 14x latency band, because the model card does not mention which of 16 servers will actually answer.

The lever nobody checks

The uncomfortable pattern across all three numbers is the same. Model selection gets real scrutiny: teams compare leaderboards, run their own evals, argue about which lab to bet on. Provider selection, which of 16 companies serves that model on any given request, gets set once, usually by default, and essentially never gets revisited. The data above says that second, ignored decision swings cost by 4x and latency by 14x, on every single call, indefinitely, until someone actually looks.

If you want to build your own provider-aware router

OpenRouter already exposes the fix as a first-class request parameter, and it is a three-line change most integrations never make. The provider.sort field disables default load balancing and orders provider selection by whichever attribute actually matters for your workload:

# deepseek_router.py — force price- or throughput-first routing
import requests

def call_deepseek(prompt: str, sort_by: str = "throughput"):
    # sort_by: "price" | "throughput" | "latency"
    resp = requests.post(
        "https://openrouter.ai/api/v1/chat/completions",
        headers={"Authorization": "Bearer $OPENROUTER_API_KEY"},
        json={
            "model": "deepseek/deepseek-v4-pro",
            "messages": [{"role": "user", "content": prompt}],
            "provider": {
                "sort": sort_by,          # disables default load balancing
                "ignore": ["digitalocean"] # drop the 4 tok/s tail if latency-sensitive
            },
        },
    )
    return resp.json()

For a latency-sensitive agent loop, sort by throughput and drop the slowest provider from the pool entirely. For a batch job with no real-time constraint, sort by price and accept whatever latency the cheapest provider offers. The mistake is not picking one of these. It is never picking either, and letting the default silently average across a 4x price band and a 14x latency band on every request.

One caveat worth stating plainly: none of these three numbers are static. Providers add GPU capacity, drop it, and revise prices without a release note, and OpenRouter's own uptime and throughput figures are measured over a rolling window, not a permanent ranking. The specific provider that is cheapest or fastest this week will not necessarily hold that position next month. The fix is not “hardcode Baseten for speed and DeepSeek native for price” and move on. It is routing on the attribute that matters for the workload, continuously, instead of on whichever provider happened to be in a getting-started tutorial.

Running that audit once is a five-minute fix. Running it continuously, as providers add capacity, drop capacity, and quietly move prices, is a recurring job that most teams do not have the discipline to schedule by hand. That is a natural fit for a mhermesagent: it runs on its own isolated VM with shell and network access, so it can hit the OpenRouter and Artificial Analysis provider endpoints on a cron schedule, diff the current price/throughput/uptime table against last week's, and flag the moment a provider you are routing to drifts outside the band you actually want.

And once you know which provider attribute matters for a given workload, MegaBrain gives you one API across 500+ models with transparent, at-cost pricing and automatic routing, so acting on that data is a config change, not a re-integration.

Sign up at getmegabrain.com to route at cost, or spin up a mhermes agent to keep this exact audit running the next time a provider's price or throughput quietly moves.