The Model Name Stayed the Same, but the Operating Contract Changed: Reading DeepSeek V4 Pro GA

원문 링크: WordPress 원문

AI NOTES · EN ENGLISH EDITION

KO · 한국어 / EN · English BILINGUAL PAIR

On August 13, 2026, DeepSeek moved DeepSeek-V4-Pro-0813 to general availability. The detail worth pausing on is not the phrase “stronger model.” It is the sentence stating that the API name callers already use, deepseek-v4-pro, stays unchanged. When the caller-facing name is held fixed while the underlying model version, the default reasoning effort, the supported protocols, the price structure, and the cache-isolation rules all move at the same time, the job for whoever operates against that name is not “try the new model.” It is “re-read the operating contract that changed underneath it.” The conclusion of this article is direct: V4 Pro GA should be treated as an operations release rather than a performance announcement, and before it reaches production a team needs to bind an alias-version receipt, protocol smoke tests, cost-window routing, per-user cache isolation, and a Flash/Pro escalation rule into a single deployment gate. Skip any of these five and the same client code will start returning different costs and different failure modes than it did the day before, without a corresponding code change on your side.

What GA actually changes

DeepSeek’s API documentation page “DeepSeek-V4-Pro GA Release” (August 13, 2026) announces the general availability of V4 Pro and states several things at once. It reports major agent-related upgrades. It confirms that both V4 Pro and V4 Flash support selectable low/high/max reasoning effort. It states native support for the OpenAI Responses API, optimized for Codex. It notes that app and web access run through Expert Mode, and that API model names remain unchanged. Finally, it previews a peak/off-peak pricing schedule effective August 16, 16:00 UTC, with off-peak prices set at 50% of peak.

These five items are worth listing separately because each sits at a different operational layer. Agent capability and reasoning effort change what the model does. Responses API support changes which protocol a client speaks. Price windows change the bill for an otherwise identical request. If you check only one of these and assume the rest are unchanged from yesterday, you find out about the gap after deployment, not before. The phrase “major agent upgrades” in particular is a qualitative claim; the source text this article draws on does not expose benchmark methodology that would let an independent party verify the size of that improvement. So this article does not attempt to rule on how much stronger the model actually is. What can be established here is that the operating contract changed and how to handle that change — not a claim of benchmark superiority.

It also helps to say why these five items get grouped under one word, “contract.” The word fits because each item is a promise that only holds if both the client and the server keep their side of it. Reasoning effort falls back to a server default unless the client specifies it. Tool-call state produces a server error unless the client returns it on the next request. Price windows apply whatever schedule the server has defined unless the client controls when the request actually fires. In other words, half of this contract lives in server-side documentation and the other half lives in client-side implementation. Reading the docs only fills in half; the rest has to be confirmed by testing real requests and real responses.

The alias is fixed; the version moves

The “Models & Pricing” page identifies deepseek-v4-pro as DeepSeek-V4-Pro-0813 and deepseek-v4-flash as DeepSeek-V4-Flash-0731. The important part is that the string your client calls is pinned to deepseek-v4-pro, while the trained snapshot that string actually resolves to is a dated release. That makes it a stable alias, not an immutable version. A request sent to that same name today can, after a future update, come back from a model with different weights and different default behavior.

The operational consequence is concrete. A regression test cannot be considered passing just because “the model name is the same.” A deployment pipeline needs a step that reads whatever version field or response header the API exposes and logs which dated snapshot actually answered — a version receipt. Only with that receipt in place can you later trace exactly when an incident or a regression started, and which version switch caused it. Reading “the alias is unchanged” as “nothing changed” is the single most common misread this section is meant to prevent.

Treating reasoning effort as a routing variable

According to the “Thinking Mode” documentation, thinking is enabled by default at high effort. OpenAI-format clients combine a thinking on/off flag with a reasoning_effort value of low/high/max; Anthropic-format clients set effort to none/low/high/max, where none disables thinking. While thinking mode is active, the server silently ignores temperature, top_p, presence_penalty, and frequency_penalty. Put together, this has two practical implications. First, reusing the same request body as before means that the moment the default reasoning effort shifts, response length and latency can shift with it, without any change on your end. Second, a pipeline that has been tuning output through sampling parameters needs to know that those adjustments are void once thinking mode is on.

From an agent-operations standpoint, reasoning effort should not be treated as a “quality dial.” It should be treated as a routing variable. Short, deterministic tool calls should get low effort; multi-step planning tasks should get high effort; verification-critical final steps should get max effort — assigned explicitly per request type rather than left to whatever the default happens to be. If effort is never specified, every shift in DeepSeek’s own default propagates straight into your pipeline’s behavior. Seen this way, agent operations is not a one-time choice of “which model,” but a routing problem connecting Flash, Pro, reasoning effort, and verification gates.

Agent operations are a routing problem that connects Flash, Pro, reasoning effort, and verification gates rather than a one-time model choice.

The tool-call and reasoning_content state contract

The “Thinking Mode” documentation also states that once a tool call has occurred, the API returns a 400 error unless reasoning_content is passed back unchanged on the subsequent request. This is a state-management contract, and ignoring it breaks a multi-turn tool-call chain partway through. It is worth being explicit here about what this article is and is not recommending: this is not a suggestion to expose hidden reasoning content to end users or to log it for later inspection. Including reasoning_content in the next request body is a technical requirement for passing state along — a separate question entirely from whether a human should read, store, or reproduce what that field contains.

Teams wiring an agent framework directly into this API should treat the field as part of session state, and confirm that session storage or cache-invalidation logic never accidentally truncates it. Retry logic that reconstructs a request body from scratch is a common place for this field to go missing. If 400 errors show up intermittently in a tool-call loop, this dropped state is the first place to look.

Protocol compatibility and silent mapping

DeepSeek supports several protocols side by side. The “Integrate with OpenCode” page instructs users running OpenCode 1.14.24 or later to select DeepSeek-V4-Pro. OpenCode is an agent client built for coding work, and this guidance signals that DeepSeek intends its models to sit behind existing agent and coding clients, not only its own interface. The “Integrate with Hermes Agent” page introduces Hermes as an open-source agent from Nous Research and walks through connecting it via the DeepSeek API base URL with the deepseek-v4-pro model. Together, both pages are written on the assumption that DeepSeek serves as a backend for third-party agent clients, not just a standalone chat product.

The page that deserves closer attention is “Using the Anthropic API”. The Anthropic-compatible base URL is https://api.deepseek.com/anthropic, and unsupported model names can be mapped automatically to V4 Flash. Under Claude-style name mapping, Opus-prefixed names route to V4 Pro, and Haiku/Sonnet-prefixed names route to V4 Flash. There is a boundary that must hold here: this mapping is a compatibility convenience, and sending a Claude-shaped name is not evidence that an Anthropic Claude model actually executed the request. Images, documents, MCP tool use and results, code-execution tool results, and several other fields are unsupported or ignored inside this compatibility layer. Any team migrating a pipeline that routes by Claude-style names onto DeepSeek needs to separately verify that the name is accepted and that the request is actually processed in full — those are two different facts.

The timing across documentation pages also deserves caution. The GA announcement and the pricing page both state that V4 Pro supports the Responses API, but some dedicated integration pages may have been written earlier and could still carry a “coming soon” note. Treat the dated GA and pricing pages as the later, authoritative statement, but before routing production traffic through any given protocol, run an endpoint-level smoke test regardless of what the documentation says. Assuming that every documentation page is synchronized with every other one is itself a risk.

The one-million-token context and 384K output boundary

The “Models & Pricing” page states that both deepseek-v4-pro and deepseek-v4-flash support a 1M-token context and up to 384K tokens of output. It also lists JSON output, tool calls, the Responses API, the Anthropic API, prefix completion, and fill-in-the-middle (FIM), with FIM limited to non-thinking mode. These figures are API ceilings, not a guarantee that any given application can use the full ceiling in practice. Client-side context compaction, latency targets, memory budgets, and application-specific token budgets routinely cap the context and output an application can actually sustain well below 1M tokens and 384K tokens. Translating “1M-token context” directly into “our service can handle a 1M-token conversation” is not a safe step.

The FIM restriction to non-thinking mode also has real consequences. Workloads that rely on FIM, such as code autocompletion, need reasoning effort explicitly turned off or lowered; leaving the default high-effort thinking mode in place, as discussed above, means FIM requests can be processed in a way the caller did not intend. Context ceilings, output ceilings, and the FIM constraint look like independent line items, but in practice they need to be reconciled inside the same request design.

Peak/off-peak price arithmetic

The price change takes effect August 16, 16:00 UTC. Before that time, the documented Pro rates per 1M tokens are $0.003625 for a cache hit, $0.435 for a cache miss, and $0.87 for output. After the change, Pro off-peak rates are $0.022 cache hit, $0.66 cache miss, and $1.98 output; Pro peak rates are $0.044 cache hit, $1.32 cache miss, and $3.96 output. Peak hours are defined as 01:00–04:00 UTC and 06:00–10:00 UTC, and every other hour is off-peak. For readers working in Korea time, those two peak windows correspond to 10:00–13:00 KST and 15:00–19:00 KST, and all other hours are off-peak. It is worth stating plainly: these prices do not apply before August 16, 16:00 UTC. If you are reading this article before that moment, the off-peak and peak figures above are scheduled, not current.

The same V4 Pro workload can have a different cost structure depending on cache use, output volume, and execution window.

To see what the change actually means, run the arithmetic. Take a hypothetical batch workload of 100M cache-miss input tokens and 20M output tokens. The pre-change Pro bill is 100 × $0.435 + 20 × $0.87 = $60.90. The new off-peak bill is 100 × $0.66 + 20 × $1.98 = $105.60. The new peak bill is 100 × $1.32 + 20 × $3.96 = $211.20. Off-peak is exactly half of peak after the change, but for this workload it is roughly 73.4% more expensive than the old rate; the new peak rate is roughly 246.8% more expensive than the old rate. These numbers push back against reading the schedule as “shift to off-peak and get a discount.” Off-peak is half of the new peak price — not half of the old price. The higher a batch workload’s cache-miss share, the more directly this difference shows up on the invoice. Before treating time-of-day routing as a cost-saving lever, run your own cache-hit rate and traffic time distribution through this same arithmetic.

Concurrency and user isolation

The “Rate Limit & Isolation” documentation states account-level concurrency limits of 500 for Pro and 2,500 for Flash, with excess requests returning HTTP 429. These numbers are ceilings on how many requests an account can have in flight simultaneously — not a guarantee of a specific throughput and not a service-level agreement. Reading 500 as “500 requests per second, always” is a misreading that only gets corrected the first time a real load spike returns 429s.

The same page describes the user_id parameter as supporting content-safety, KV-cache, and scheduling isolation. user_id must match [a-zA-Z0-9\-_]+, stay under 512 characters, and must not carry private information. Any multi-tenant service needs to populate this value consistently, one value per actual end user, for cache isolation and content-safety judgments to separate correctly by user. Leaving it blank, or pinning it at the application level instead of the user level, risks mixing different users’ requests into the same cache and scheduling bucket. It’s also worth noting for pipeline design that requests may receive empty-line or SSE-style keep-alive signals, and that the server closes any request that has not started inference within ten minutes — a detail that matters for timeout design in batch and agent pipelines with long queue waits.

A production decision framework

Pulling the conditions above into one deployment judgment produces a specific order of operations. Before sending traffic, log the version identifier carried in the response so you know which snapshot actually answered. Next, run endpoint-level smoke tests against each protocol you intend to use — OpenAI format, Responses API, Anthropic-compatible format — to confirm that documented support matches actual behavior. Then specify reasoning effort explicitly per request type instead of relying on the default. For any path that uses tool calls, test that reasoning_content re-transmission survives your retry logic and session-storage layer, not just the happy path. For pricing, plug your workload’s real cache-hit rate and execution-time distribution into the arithmetic above to determine whether shifting to off-peak is actually cheaper for you, or merely half of a peak price that is itself higher than before. Build concurrency limits and user_id isolation into multi-tenant traffic design from the start, with a retry-and-queue strategy ready for when 429s occur.

Finally, set an explicit escalation rule between Flash and Pro. Short, deterministic tasks and anything requiring high concurrency should default to Flash; only multi-step planning or precision-critical tasks should escalate to Pro, and that rule should live in code, not in convention. Without it, every request defaults to Pro, hits the 500-request concurrency ceiling first, and absorbs peak-hour pricing by default. Binding these five checks — version receipt, protocol smoke tests, cost-window arithmetic, isolation-key design, and Flash/Pro escalation — into a single deployment checklist is the practical conclusion of this article.

Limitations and what remains unconfirmed

It’s worth being explicit about what this article does not settle. The public sources available here do not expose benchmark methodology sufficient to independently verify how much the “major agent upgrades” phrase actually delivers, so this article does not claim a performance edge. A stable model alias is not an immutable version, and that bears repeating: the pricing page’s actual version is V4-Pro-0813, while clients keep calling the name deepseek-v4-pro. Not every protocol page should be assumed synchronized — even when the GA and pricing pages state Responses API support, some individual integration pages may still carry earlier “coming soon” language, which is why an endpoint smoke test comes first. Anthropic-compatible formatting is not the same claim as an Anthropic or Claude model actually executing the request. This article does not recommend retaining or exposing hidden reasoning; reasoning_content re-transmission is described here strictly as a state-management contract. The peak/off-peak price change is not described as a blanket discount — off-peak is half of the new peak price, and the worked example above shows it can cost more than the pre-change rate. The 1M-token context and 384K-token output figures are API ceilings, not a promise that every client can use them in full. The 500 and 2,500 concurrency numbers are account-level limits, not throughput guarantees or an SLA. This article does not include API keys, credentials, private identifiers, internal paths, or step-by-step secret configuration.

Before production, bind alias-version receipts, protocol smoke tests, price windows, isolation keys, and regression evaluations into one release gate.

Next actions

Before putting V4 Pro GA into production, here is a concrete sequence to run. First, extract the version identifier from whatever deepseek-v4-pro responses your current pipeline already receives, log it, and build a receipt system that can track future version switches over time. Second, write a minimal request/response smoke test for every protocol you actually intend to use — OpenAI format, Responses API, Anthropic-compatible — so any gap between documentation and real behavior surfaces before it reaches users. Third, hard-code an explicit reasoning-effort mapping table per request type into your codebase, and add integration tests that verify reasoning_content re-transmission across the tool-call path. Fourth, plug your actual cache-hit rate and traffic’s time-of-day distribution into the arithmetic in this article to confirm for yourself whether off-peak routing is genuinely cheaper for your workload, and do not apply these prices before August 16, 16:00 UTC. Fifth, fold user_id isolation design and a 429 retry strategy into your multi-tenant traffic design, and make the Flash/Pro escalation rule an explicit item in code review. Only once these five steps pass as a single deployment gate does “the same model name” actually mean “the same operating conditions.”

Sources

• DeepSeek API Docs, “DeepSeek-V4-Pro GA Release” — https://api-docs.deepseek.com/news/news260813/

• DeepSeek API Docs, “Models & Pricing” — https://api-docs.deepseek.com/quick_start/pricing

• DeepSeek API Docs, “Thinking Mode” — https://api-docs.deepseek.com/guides/thinking_mode

• DeepSeek API Docs, “Rate Limit & Isolation” — https://api-docs.deepseek.com/quick_start/rate_limit

• DeepSeek API Docs, “Using the Anthropic API” — https://api-docs.deepseek.com/guides/anthropic_api

• DeepSeek API Docs, “Integrate with OpenCode” — https://api-docs.deepseek.com/quick_start/agent_integrations/opencode

• DeepSeek API Docs, “Integrate with Hermes Agent” — https://api-docs.deepseek.com/quick_start/agent_integrations/hermes