DeepSeek V4 Pro 0813 API: What It Is, Pricing & How to Access It (2026)

A single maximum-size prompt to DeepSeek V4 Pro 0813 costs about $0.456 before output. That is the practical headline behind this release: a 1,048,576-token context window paired with input pricing of $0.435 per million tokens. The model is inexpensive enough to make repository-scale analysis, long document workflows, and persistent agent context plausible—but a million-token window is still not a license to send everything indiscriminately.

DeepSeek V4 Pro 0813 is available through OpenRouter as:

deepseek/deepseek-v4-pro-0813

The confirmed API-facing details are straightforward:

• Developer: DeepSeek
• Context length: 1,048,576 tokens
• Prompt price: $0.000000435 per token, or $0.435 per million
• Completion price: $0.00000087 per token, or $0.87 per million
• Access pattern: OpenAI-compatible and Anthropic-compatible API clients
• OpenRouter model ID: deepseek/deepseek-v4-pro-0813

Some architectural, benchmark, training-data, and maximum-output details are still emerging. The safe way to evaluate this model today is by what the endpoint demonstrably exposes—not by inferring capabilities from the “V4 Pro” name.

What DeepSeek V4 Pro 0813 Is

DeepSeek V4 Pro 0813 is a DeepSeek model snapshot distributed through a routed API. OpenRouter provides the endpoint and billing layer; it did not create the underlying model.

The 0813 suffix identifies a versioned snapshot, which is operationally useful even while release details remain limited. Pinning a dated model ID is generally safer than using a floating alias because an application is less likely to change behavior overnight when a provider updates its default route.

Do not read too much into the name, however. “Pro” does not by itself confirm a particular parameter count, mixture-of-experts architecture, reasoning mode, or benchmark tier. Likewise, 0813 looks date-like, but the identifier alone is not enough to establish every detail of the release timeline.

What we can assess confidently is its product profile: very long context, low token prices, and compatibility with familiar chat-completion tooling.

Its standout strengths

The most compelling characteristics are practical rather than speculative:

• A true million-token-class context allocation. The published 1,048,576-token limit is exactly 2²⁰ tokens.
• Low long-context input cost. Even 500,000 input tokens cost only $0.2175 at the listed vendor rate.
• Stable model targeting. The full snapshot ID can be pinned in production configuration.
• Low integration friction. Existing OpenAI-style clients can usually switch through a base URL and model-name change.
• Potential consolidation of multi-stage workflows. Large code indexes, contract collections, logs, or agent histories can sometimes fit in one request rather than being aggressively partitioned.

The trade-off is that context capacity and context quality are different things. A model accepting one million tokens does not prove that it will retrieve one crucial detail equally well from every position in that window. In practice, long prompts still benefit from headings, file boundaries, metadata, summaries, and explicit instructions about where evidence should come from.

Where It Sits in the 2026 Model Landscape

The 2026 API market includes GPT-5.5, Gemini 3, Sonnet 4.6, Haiku 4.5, Fable 5 with a 1M context option, catalog labels such as gpt-5.6-sol, and expanding model families from MiniMax, Qwen, and DeepSeek.

Direct ranking is premature without controlled tests on the workload that matters. Model names and gateway catalogs also move faster than many production evaluation suites. A more useful comparison is the purchasing decision each option represents.

This is not a quality leaderboard. The table deliberately avoids assigning benchmark superiority where comparable evidence is not yet established.

For a coding agent, I would test repository navigation, patch correctness, tool-call reliability, and regression rate—not just whether the entire repository fits in one prompt. For document analysis, I would test citation fidelity and missing-fact rates at 50,000, 250,000, and 750,000 tokens. In practice, models can look nearly identical on short prompts and diverge substantially once relevant evidence is buried deep in a large context.

Calling the OpenAI-Compatible API

Set an OpenRouter key in your environment:

export OPENROUTER_API_KEY="replace-with-your-key"

Then send a standard chat-completions request:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v4-pro-0813",
    "messages": [
      {
        "role": "system",
        "content": "You are a careful API code reviewer."
      },
      {
        "role": "user",
        "content": "Review this retry policy and identify failure modes."
      }
    ],
    "max_tokens": 800,
    "temperature": 0.2
  }'

With an OpenAI-compatible Python client, the important changes are base_url and model:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["OPENROUTER_API_KEY"],
    base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
    model="deepseek/deepseek-v4-pro-0813",
    messages=[
        {
            "role": "system",
            "content": "Return concise, actionable engineering feedback.",
        },
        {
            "role": "user",
            "content": "Explain when exponential backoff should include jitter.",
        },
    ],
    temperature=0.2,
    max_tokens=600,
)

print(response.choices[0].message.content)
print(response.usage)

A common gotcha is assuming that every OpenAI client feature is automatically supported because the request schema is compatible. Chat messages are the baseline. Structured output, tool calling, prompt caching, images, log probabilities, and provider-specific reasoning controls must be tested individually against the routed model.

Calling It with an Anthropic-Compatible Client

OpenRouter also supports Anthropic-style message clients through its compatible base URL. The same OpenRouter key is used:

import os
from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["OPENROUTER_API_KEY"],
    base_url="https://openrouter.ai/api",
)

message = client.messages.create(
    model="deepseek/deepseek-v4-pro-0813",
    max_tokens=600,
    temperature=0.2,
    system="You are a senior backend engineer.",
    messages=[
        {
            "role": "user",
            "content": "Design idempotency handling for a payment API.",
        }
    ],
)

print(message.content[0].text)
print(message.usage)

Compatibility here means the gateway translates an Anthropic-shaped request. It does not turn DeepSeek into a Claude model, nor does it guarantee identical system-prompt, tool-use, or content-block semantics. If an application depends on exact provider behavior, add contract tests around request fields and response parsing.

For teams already routing across Claude, GPT, and Gemini, a multi-model service can reduce integration and billing overhead. AI Prime Tech offers cheaper multi-model API access across those families, with advertised savings of up to 80%; compare effective rates, routing behavior, and feature support for your actual traffic rather than selecting solely from the headline discount.

Pricing Math That Matters

The base calculation is:

cost = (prompt_tokens × $0.000000435)
     + (completion_tokens × $0.00000087)

Here are representative requests:

At scale, small requests still add up. A workload averaging 8,000 input tokens and 1,000 output tokens costs $0.00435 per call. At 100,000 calls, that becomes:

100,000 × $0.00435 = $435

A full 1,048,576-token input would cost:

1,048,576 × $0.000000435 = $0.45613056

That calculation assumes the entire allowance can be used as input. Context limits commonly cover some combination of input and generated output, and the model’s separate maximum-output limit has not been established here. Leave headroom rather than constructing prompts exactly at 1,048,576 tokens.

These are vendor-token rates. Final invoices can differ because of gateway fees, taxes, provider routing, retries, or separately priced features. Token counts can also differ from character-based estimates because the model tokenizer determines billing.

Cost controls I use in practice

• Set max_tokens explicitly on every request.
• Record input tokens, output tokens, model ID, latency, and request outcome.
• Retry only transient failures, with capped exponential backoff and jitter.
• Do not resend a 700,000-token prompt blindly after an ambiguous timeout.
• Summarize old conversation turns instead of preserving every raw message.
• Use retrieval to select relevant files before consuming the million-token window.
• Route classification and extraction tasks to cheaper or faster models when quality holds.
• Add per-request and per-user budget limits before exposing the endpoint publicly.

Long-context calls also create operational pressure beyond token cost. Large JSON bodies take time to encode, upload, parse, and queue. Reverse proxies may reject the body or time out before the model responds. Streaming helps with response latency, but it does not eliminate input upload time.

Practical Takeaways

• DeepSeek V4 Pro 0813 is a DeepSeek snapshot available as deepseek/deepseek-v4-pro-0813.
• Its confirmed differentiators are a 1,048,576-token context window, $0.435/M input, and $0.87/M output.
• A million-token prompt costs roughly $0.456 before completion charges.
• Use OpenAI- or Anthropic-compatible clients, but test advanced features instead of assuming complete semantic parity.
• Treat the 1M window as capacity, not proof of perfect long-range recall.
• Pin the dated model ID, collect usage data, and run workload-specific evaluations against GPT-5.5, Gemini 3, Claude-side options, Fable 5, MiniMax, Qwen, and other DeepSeek models.
• Keep retrieval, summarization, request-size limits, and retry controls even when raw context is inexpensive.
• Architecture and benchmark details remain incomplete, so production adoption should follow measured application results rather than launch-label assumptions.