V4-Flash Goes General Availability, Pro Coming Soon

On July 31, DeepSeek updated the release progress of its V4 series: The production version of the DeepSeek-V4-Flash API is now available in public beta under the version identifier DeepSeek-V4-Flash-0731; the higher-end production version of DeepSeek-V4-Pro will also be released as soon as possible.

This update does not increase the model's size or replace its underlying architecture. According to information disclosed by DeepSeek, V4-Flash-0731 retains the same model architecture and size as the previous V4-Flash-preview, with the main changes coming from a new round of post-training. The production version also natively supports the Responses API format and has been adapted for Codex-style coding workflows.

In other words, this is not an upgrade achieved by simply adding more parameters, but rather a retuning of the same "engine." For developers who have already integrated the preview version, migration costs are expected to be relatively low. However, for teams preparing to deploy it in production, "production version now in public beta" still does not mean regression testing can be skipped.

Why It Is Still Worth Upgrading Despite an Unchanged Architecture

The most noteworthy statement about V4-Flash-0731 is that it "only underwent post-training again." The word "only" can easily lead people to underestimate the scope of the update.

Pre-training determines a large model's knowledge foundation, language capabilities, and performance ceiling, while post-training organizes those capabilities into a product that users can actually put to work. Whether a model follows instructions accurately, produces structured data consistently, self-corrects when tool calls fail, and reads the relevant context before modifying files when coding are all heavily influenced by post-training.

For API models, post-training can often change the development experience more directly than adding another batch of parameters. The reason is simple: applications do not merely need a model to "occasionally get the answer right"; they need it to follow protocols consistently across thousands of calls.

Improvements of this kind are typically reflected in several areas:

• More consistent instruction following. Fewer missed constraints, unauthorized expansions of task scope, and deviations from the required output format.
• More engineering-oriented code work. Rather than merely generating a single function, the model can understand a repository, modify multiple files, run checks, and continue iterating based on errors.
• More reliable tool use. More accurate tool selection and parameter generation, along with better handling of error information returned by tools.
• Less drift during long-running tasks. Better goal retention across multi-turn agent loops, reducing repeated calls, unproductive searches, and premature termination.
• More controllable response styles. Clearer boundaries between concision, detailed reasoning, and the final answer.

Therefore, if V4-Flash-preview already meets an application's baseline capability requirements, the value of the 0731 production version may not show up as a sudden jump of several points on a benchmark. It is more likely to appear in production logs: fewer parsing failures, fewer incorrect tool parameters, and fewer agent iterations required to complete the same task.

These metrics matter more to developers than a one-off demonstration. It is not difficult for a model to generate an impressive piece of code. The challenge is whether, after handling 50 real-world issues in succession, it still knows which files it must not touch, which tests it must run, and when it should stop making changes.

Native Responses API Support Is a Clear Product Signal

The production version of V4-Flash natively supports the Responses API format and has been adapted for Codex. For developers, this is a more significant change than the words "production version."

Historically, most model services compatible with the OpenAI format have been built primarily around the Chat Completions API. It works well for question-and-answer interactions and standard streaming conversations. However, as models begin handling search, code execution, file modifications, function calls, and multi-turn state management, assembling context solely through arrays of messages becomes increasingly cumbersome.

The Responses API is closer to a unified task interface for agents: text, tool calls, and intermediate results can all be placed within the same response structure, while the server can manage task state more easily. It does not make the model smarter out of thin air. Instead, it turns the previously loose "chat history" between the model and its tools into a more clearly structured execution trace.

Adaptation for Codex also indicates that DeepSeek is competing for coding agents as a high-frequency entry point. Codex here should not be understood merely as a code completion tool, but as a class of development agents capable of browsing repositories, running commands, modifying files, and validating results. The main challenge for models in these scenarios is not memorizing syntax, but maintaining a plan over long periods and correctly interpreting information returned by tools.

This also explains why DeepSeek is first rolling out V4-Flash through an API public beta. Coding agents make frequent calls, use long contexts, are latency-sensitive, and repeatedly execute "read-modify-test-correct" loops. If the Flash model can strike a balance among cost, speed, and reliability, it is more likely to generate real-world usage than a model focused solely on achieving the highest benchmark scores.

"Production Version in Public Beta" Still Requires Careful Interpretation

DeepSeek uses the phrase "production API version now in public beta," which may sound somewhat contradictory but actually conveys two different layers of status: the model weights and training methodology have graduated from the preview stage, while the API service, rate-limiting policies, compatibility, and online load handling are still undergoing validation at a larger scale.

Developers should not assume complete behavioral compatibility simply because the version name has changed from preview to 0731. An unchanged architecture and size only mean that the foundational deployment requirements have changed little; they do not mean the output distribution will remain the same. After another round of post-training, the same prompt may produce answers with different lengths, structures, or even decision paths.

Teams preparing to upgrade should, at a minimum, recheck the following:

1. Structured output success rate. Pay particular attention to missing JSON fields, drift in enumerated values, and additional explanatory text.
2. Tool-call parameters. Check required fields, array-versus-string types, and parallel calling behavior.
3. Code modification boundaries. Confirm that the model does not casually refactor unrelated files or delete configuration that appears unnecessary but is actually required.
4. Latency and throughput. Measure time to first token, total response time, and overall completion time for agent tasks separately.
5. Token consumption. Changes from post-training may make responses shorter, or they may lead the model to expand into more steps on complex tasks.
6. Differences in safety policies. Conduct separate regression testing for content moderation, refusal boundaries, and sensitive-data handling.
7. Version pinning. Prefer date-stamped model identifiers in production to prevent silent switches caused by updates to default aliases.

For coding agents in particular, comparing single-turn generation quality is not enough. A more appropriate unit of evaluation is the "total cost of completing one verifiable task": how many model calls were made, how many tokens were consumed, how many times tests were run, whether human intervention was required, and whether the final patch passed CI.

If the 0731 version costs slightly more per call but avoids two rounds of incorrect execution, it may actually be cheaper overall. Conversely, if benchmark scores improve but the model frequently generates patches that cannot be applied, the upgrade offers little value to a production system.

V4-Pro Will Define the Performance Ceiling of This Model Generation

DeepSeek has also confirmed that the production version of V4-Pro will be released as soon as possible, but as of July 31, it has not provided a specific date, official pricing, or complete evaluation results.

According to previously disclosed preview information and media reports, V4-Pro is positioned as the flagship model in the V4 series. It uses a Mixture-of-Experts architecture, reportedly has 1.6 trillion total parameters and 49 billion active parameters per inference, and targets million-token contexts and extremely long-output scenarios. Because the production version has not yet been released, these specifications and preview benchmark results remain subject to DeepSeek's final announcement and should not be treated as commitments for the production version.

If these capabilities are retained in the production release, the distinction between V4-Pro and V4-Flash will not simply be one of a "fast model" versus a "large model." Instead, they will support a clearer division of tasks:

• V4-Flash is suitable for high-concurrency question answering, coding assistance, tool routing, and large volumes of agent subtasks.
• V4-Pro is better suited to complex repository-level coding, scientific analysis, extremely long document processing, and agent tasks that require multi-stage planning.
• Real-world applications can use Flash first for retrieval, classification, and information compression, then escalate a small number of difficult tasks to Pro.

This tiered approach is more practical than having a flagship model handle every request. The cost of agent systems often comes not from the final high-quality inference, but from the dozens of searches, filtering steps, validations, and retries that precede it. Only by having Flash handle the "heavy lifting" and handing truly difficult decisions to Pro can model capabilities potentially translate into acceptable unit economics.

DeepSeek Is Starting to Complete the Interface Layer Beyond the Model

Judging from this update, DeepSeek is shifting the focus of competition from model scores to development workflows.

DeepSeek's strongest selling points have historically been cost-effectiveness and reasoning capabilities, but enterprise applications also care about API stability, tool-calling protocols, version management, rate limits, monitoring, and migration costs. Support for the Responses API and adaptation for Codex mean that DeepSeek does not merely want to serve as an interchangeable model backend; it also aims to enter the infrastructure layer for coding agents and general-purpose agents directly.

This path will not be easy. Proprietary model providers have the advantage of being able to iterate on models, tool protocols, and clients in lockstep. DeepSeek, meanwhile, must prove that its API semantics are consistent enough while maintaining compatibility with the existing ecosystem. So-called "compatibility" cannot stop at a request successfully returning an HTTP 200 status code; it must also cover details such as streaming events, tool-call ordering, error structures, request cancellation, and context continuation.

For teams that manage multiple models through a unified OpenAI-compatible format, improved compatibility will reduce the cost of switching providers. Developers who access multiple models through aggregation platforms such as OpenAI Hub can also monitor subsequent updates to V4-Flash-0731 model mappings and regional availability. However, before switching, they should still complete business regression testing using a pinned version rather than changing only the model name and deploying directly to production.

Should You Upgrade Now?

Our assessment is: It is worth testing, but not worth switching blindly.

Rather than generating attention by increasing the parameter count, the production version of V4-Flash invests resources in post-training, Responses API support, and coding-agent adaptation. This is the right direction. For API users, reliable task completion matters more than model size. For DeepSeek, entering real-world agent execution chains is also more commercially valuable than topping another static benchmark.

Teams currently using V4-Flash-preview should establish side-by-side testing between the preview and 0731 versions as soon as possible, focusing on tool success rates, task completion rates, and total token costs. Teams currently using other lightweight models can also add V4-Flash to the same real-world task suite, but they should not draw direct comparative conclusions using benchmarks selectively chosen by individual vendors.

As for V4-Pro, it is currently better to wait for the official specifications, pricing, rate limits, and independent test results. A total parameter count of 1.6 trillion or a million-token context window is certainly eye-catching, but what will ultimately determine its usefulness is activation efficiency, effective long-context utilization, agent stability, and the total cost of each successfully completed task.

V4-Flash has laid the API groundwork first, while V4-Pro will raise the capability ceiling. What DeepSeek truly needs to prove in this round is not whether it can train an even larger model, but whether it can combine models, APIs, and development agents into a stable product.

References

This article is based on DeepSeek's V4-Flash update log released on July 31, 2026, as well as same-day news reports from Chinese media outlets including Securities Times, 36Kr, National Business Daily, CLS, and Yicai. Because the domains of these original sources are not included in the specified allowlist of links that may be retained, no external links are provided at the end of this article, thereby avoiding the inclusion of noncompliant or unverified alternative links.