Using DeepSeek on OpenRouter (and Cheaper BYOK Options)

If you want to call DeepSeek models without signing up for yet another provider account, routing through OpenRouter DeepSeek is the most common shortcut. One prepaid balance, one OpenAI-compatible endpoint, and you can reach DeepSeek's chat and reasoning models alongside everything else in OpenRouter's catalog. This guide covers how to do that in practice — the model slug format, a working request you can adapt, and the honest trade-offs on cost and data handling — plus a note on when skipping the aggregator entirely and going direct, or using a BYOK gateway, saves you real money.

Why developers use DeepSeek on OpenRouter

DeepSeek is available directly through its own API platform. So the first question is why anyone routes through OpenRouter at all when they could call api.deepseek.com directly. The reasons are practical, and they are worth naming rather than glossing over, because knowing them tells you whether the trade-off is worth it for your situation.

• One balance, everything. If you already run OpenAI or Anthropic calls through OpenRouter, adding DeepSeek is a one-line model swap — no new signup, no new key rotation, no second invoice. For exploration and prototyping, that friction reduction is genuinely useful.
• Easy A/B switching. OpenRouter's unified API makes it trivial to try DeepSeek V3 against GPT-4o or Claude Sonnet without touching your HTTP client. You change the model field; everything else stays the same.
• Fallback and routing. OpenRouter can route a DeepSeek-class model across multiple upstream providers if the primary is slow or down, and you can declare fallback sequences in your request headers. For production workloads that care about uptime, that is a real feature.
• No need to deal with DeepSeek's platform directly. DeepSeek's developer platform is usable, but if your team is consolidating billing and access management in one place, OpenRouter fits that model cleanly.

These are legitimate reasons. The flip side — cost — is covered below, because it matters and is often glossed over in articles that want you to sign up for something.

How to use DeepSeek via OpenRouter: model slugs and endpoint

OpenRouter uses a namespaced model ID format: provider/model-name. For DeepSeek models, the namespace is deepseek. The two main families map to slugs that look like:

• deepseek/deepseek-chat — the general-purpose V3-class model for chat, summarization, code, extraction, and tool use.
• deepseek/deepseek-r1 — the R1-class reasoning model that generates a chain of thought before answering, lifting accuracy on harder math, logic, and multi-step problems at the cost of extra output tokens.

Important: OpenRouter's model catalog is updated frequently as new versions ship and old ones are deprecated. The slugs above match the long-standing IDs, but you should verify the current list on OpenRouter's models page before hard-coding any string into production code. Filter by "deepseek" to see all available variants and their current per-token prices.

OpenRouter's base URL is https://openrouter.ai/api/v1, and the endpoint is the standard /chat/completions path. Any OpenAI-compatible client works by swapping the base URL and key. Here is a minimal curl example calling the chat model — replace the model slug with whatever the current live ID is:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-chat",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between input and output token pricing in one paragraph."
      }
    ]
  }'

The same call with the Python OpenAI SDK looks like this:

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-your-openrouter-key",
)

response = client.chat.completions.create(
    # Verify current slug at openrouter.ai/models
    model="deepseek/deepseek-chat",
    messages=[
        {"role": "user", "content": "What is 17 multiplied by 43?"}
    ],
)
print(response.choices[0].message.content)

For the DeepSeek R1 OpenRouter path — the reasoning model — swap the model string to the current R1 slug. R1 is worth using when you need correct answers on multi-step problems rather than fast answers on straightforward ones. Expect higher output token counts because the model reasons through the problem before replying; budget for that in your cost estimates.

OpenRouter-specific request headers

OpenRouter supports a few extra headers that are useful in practice. HTTP-Referer lets you identify your app in OpenRouter's dashboard, and X-Title sets a human-readable name for the request source. Neither is required, but they help with usage attribution when you run multiple projects through the same key.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "HTTP-Referer: https://yourapp.com" \
  -H "X-Title: MyApp" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek/deepseek-chat", "messages": [{"role":"user","content":"Hello"}]}'

The cost angle: OpenRouter credits vs. direct DeepSeek vs. BYOK

DeepSeek's native API is already one of the cheapest options for a capable frontier-class model. When you route it through OpenRouter, the effective cost rises slightly because OpenRouter operates on a prepaid credit model — there is a layer of platform margin, processing fees, or a spread built into the credit-purchase mechanism. The exact figure is something to verify on OpenRouter's current pricing page, not a number to take from a blog post, but the direction is consistent: direct is usually cheaper per token than via an aggregator, for the same underlying model.

If cost is the primary driver, the options in rough order of cheapest-to-most-convenient are:

• Direct to DeepSeek: sign up at DeepSeek's developer platform, load credits, call api.deepseek.com directly. You pay list price with no aggregator spread. See our DeepSeek API guide for the full setup walkthrough.
• Direct to an open-weight host like DeepInfra: DeepSeek's open-weight models (the non-API variants) run on hosts like DeepInfra, Together AI, and Fireworks. These hosts sometimes price below DeepSeek's own API for equivalent model quality — worth checking if you want a Western-hosted inference endpoint for the same weights.
• OpenRouter with credits: convenient if you already have a balance, and the cost difference is negligible for low volumes. At scale the spread compounds.
• A BYOK gateway like flo2: bring your own DeepSeek API key to a gateway that adds zero token markup. You keep the direct-provider price while gaining routing, fallback, and a unified endpoint. More on that below.

The convenience vs. cost trade-off is real, and where you land on it depends on your volume. For prototypes and low-volume experiments, the OpenRouter credit model is fine. For production workloads billing thousands of dollars a month in tokens, the per-token spread starts to show up as a line item that is worth addressing.

Data governance considerations for DeepSeek-class models

DeepSeek is a Chinese AI lab, and its models have attracted scrutiny in some regulated industries and jurisdictions. This is not a reason to avoid the models — the open-weight variants especially are widely deployed — but it is something to think through before shipping to production.

• Review the terms of service for any host you use. When you call DeepSeek's own API at api.deepseek.com, traffic and data are subject to DeepSeek's terms. When you route through OpenRouter, OpenRouter's terms govern the relationship, and they in turn route to their upstream — so there is a chain to understand. For sensitive data, read the terms of every party in that chain.
• Consider which region the inference runs in. Open-weight hosts like DeepInfra and Together AI often run inference in US or EU data centers and publish their data retention and processing policies explicitly. If your organization has data residency requirements, a Western-hosted provider running the same open-weight model may fit policy better than calling the origin API.
• Check whether the host retains prompts. Some providers offer zero-retention commitments or BAA agreements. These are features to ask about explicitly rather than assume.
• Know your own threat model. For most public, non-sensitive workloads, the governance questions are straightforward. For healthcare, finance, or government use cases, loop in your legal or compliance team before routing production data through any third-party inference endpoint, including OpenRouter.

For more background on OpenRouter as a platform — how it works, how it bills, and what it is genuinely best suited for — see our full explainer on what is OpenRouter.

An alternative: bring your own DeepSeek key to a zero-markup gateway

If the credit spread bothers you but you still want a unified endpoint, a routing layer, and fallback without managing it yourself, the BYOK gateway model is the middle path. You supply your own DeepSeek API key (and keys from other providers), and the gateway routes your requests through them — so you pay the provider's list price directly with no markup on tokens.

flo2 is a developer-first LLM gateway built on this model. One OpenAI- and Anthropic-compatible API key routes to any provider you wire in, including DeepSeek, with zero token markup, automatic fallback, and routing to the cheapest or fastest available option. It is free during beta, which makes it reasonable to try even if you are already running on OpenRouter — the migration is a base URL and key swap, same as going to OpenRouter in the first place.

The short summary: OpenRouter DeepSeek works, is convenient, and is a sensible default when you are consolidating model access behind one balance. The cost of that convenience is a small per-token spread and a data chain that is worth understanding for sensitive workloads. For teams where the token economics start to matter, going direct to DeepSeek or routing via a zero-markup BYOK gateway like flo2 is the next natural step.