DeepSeek V4 Pro API: Current Model, Pricing, Setup, and Tradeoffs

DeepSeek V4 Pro is available through the official API under the stable model ID deepseek-v4-pro. As of August 13, 2026, DeepSeek says that ID serves DeepSeek-V4-Pro-0813. The API exposes a one-million-token context window, a maximum output of 384K tokens, thinking and non-thinking operation, tool calls, JSON output, Responses API support, and both OpenAI- and Anthropic-compatible routes.

That makes the first request straightforward. Production planning is less straightforward: thinking is on by default, a cache miss costs far more than a cache hit, and the official rate card warns that a significant overall API price increase is coming. Treat today's numbers as a dated input to a budget, not a promise for the quarter.

What the official API currently identifies as V4 Pro

DeepSeek's live models and pricing page provides the contract that matters for a direct API integration:

Use the stable ID in application configuration. Record the served version in evaluation notes, incident logs, and reproducibility reports. That separation lets DeepSeek update the implementation behind the stable ID without forcing you to invent a dated API model name that the documentation does not expose.

Do not substitute the legacy names deepseek-chat or deepseek-reasoner. DeepSeek's change log says those aliases were part of a transition to V4 Flash's non-thinking and thinking modes. They are not alternate names for V4 Pro.

The lifecycle language deserves similar care. DeepSeek's April announcement called V4 a preview, and its July 31 update said an official V4 Pro release would follow soon. The current quick-start page already maps Pro to the 0813 version, but the official pages checked for this guide did not contain a separate notice explicitly labeling Pro generally available. “Callable now” is accurate; an unqualified GA claim is not yet necessary.

Price a workload instead of copying one token rate

The checked direct-API rates per one million tokens are:

• cache-hit input: $0.003625;
• cache-miss input: $0.435;
• output: $0.87.

Use all three meters:

request cost = cached input + uncached input + output

For example, a repository-analysis run with 600,000 cached input tokens, 200,000 uncached input tokens, and 30,000 output tokens costs:

0.6 × $0.003625 + 0.2 × $0.435 + 0.03 × $0.87 = $0.115275

That result is reproducible arithmetic from the rate card checked on August 13, 2026. It excludes tax, third-party router markup, external tool fees, retries, and human repair. DeepSeek also states on the same page that it expects to raise overall API prices significantly and has not published the final replacement rates. Re-open the rate card before approving a purchase or forecasting sustained traffic.

A low cached-input rate does not mean an entire long prompt will be billed as a hit. Cache behavior depends on reuse of a stable prefix. Keep system policy, an unchanged repository map, and fixed reference material stable and early; keep new user instructions, tool output, and changing conversation history out of the reusable prefix. Then inspect the provider's actual usage fields rather than assuming a hit.

For procurement, add one more denominator:

cost per accepted task = cost of all attempts / tasks that passed acceptance

Pro can be economically better than a cheaper model if it materially reduces retries and human takeover. It can also be wasteful when a simpler model already passes the same tests.

Make a first OpenAI-compatible request

DeepSeek's first-call guide shows that the standard OpenAI Python client is enough. Keep the key in an environment variable:

python
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "Review code changes conservatively."},
        {"role": "user", "content": "Find rollback risks in this migration plan."},
    ],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
    stream=False,
)

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

For short classification, extraction, or deterministic transformations, test non-thinking operation rather than paying for unneeded reasoning:

python
extra_body={"thinking": {"type": "disabled"}}

A successful smoke test should confirm more than HTTP 200. Check that final content is non-empty, usage fields are captured, the requested model is visible in logs, timeouts and errors are handled, and neither the API key nor sensitive prompts are written to application logs.

Thinking mode changes the integration contract

DeepSeek's thinking-mode documentation says thinking is enabled by default at high. Valid effort choices are low, high, and max; compatibility values such as medium and xhigh map to high.

Four familiar sampling controls—temperature, top_p, presence_penalty, and frequency_penalty—have no effect in thinking mode. The server may accept them without an error, which can make a configuration look tuned when it is not. Adjust reasoning effort or disable thinking for the task instead.

Tool-using agents have a more consequential rule. During a thinking-mode tool loop, the assistant message can contain reasoning_content, content, and tool_calls. After your code executes a tool, append the complete assistant message and then the role: tool result. Dropping reasoning_content from the continuation can produce a 400 response.

The safest pattern is to append the SDK's returned message object rather than reconstructing it field by field. DeepSeek's tool-call guide also separates ordinary tool calls from strict schema mode. Strict mode uses the /beta base URL and a limited JSON Schema subset; it is not a blanket guarantee that every schema will validate.

A 1M context window is a ceiling, not a prompt target

The context figure and the maximum-output figure answer different questions. A one-million-token context is the total working window; 384K is the listed output ceiling. Neither tells you that filling the context is efficient.

Large uncached prompts increase cost and prefill work, while irrelevant files can make an agent less precise. Start with retrieval that selects the files and evidence needed for the current task. Expand only when acceptance failures show that missing context caused the problem. Measure end-to-end time and accepted-result quality, not just first-token speed.

When Pro earns the premium over V4 Flash

At the checked rate card, Pro's cache-miss input and output prices are a little over three times Flash's. The right first candidate depends on failure cost:

Do not move a Pro benchmark score into a Flash evaluation. They are separate models with separate prices. If your decision expands beyond this pair, the same-locale DeepSeek V4 Flash vs Kimi K3 vs GLM-5.2 guide owns that broader comparison.

Run both candidates on 10–30 representative tasks with the same files, tool permissions, timeout, retry budget, and acceptance checks. Record cached and uncached input, output, wall time, retries, and human intervention. The model that wins one polished demo is interesting; the model that delivers more accepted work inside your budget is deployable.

Before implementation, verify the current rate card and change log again. The stable model ID makes code easier to maintain, but it does not freeze the version or the price behind it.