DeepSeek-V4-Flash API: Responses, Codex, Agent Setup

DeepSeek opened the DeepSeek-V4-Flash API to public beta on July 31, 2026, under the date-stamped model ID deepseek-v4-flash-0731. Alongside the Chat Completions endpoint it has served for years, the beta adds a native Responses API surface, and that second endpoint is what changes how you write an agent loop against it.

It also takes one decision off your side of the wire: who holds the conversation.

The Responses endpoint keeps your turn history on DeepSeek's servers

Chat Completions is stateless by design. Every turn, your client resends the entire messages array: system prompt, all prior user turns, every assistant turn, every tool call and every tool result. A ten-step agent run sends the step-one context ten times. Input token spend grows roughly with the square of the step count, and the code that prunes, summarizes and reassembles that array is usually the ugliest file in an agent codebase.

The Responses API, as OpenAI specified it, inverts that. The client sends input items, the server returns a response object carrying an id, and the following turn sends only the new items plus a pointer back to that id, which OpenAI's schema calls previous_response_id. The server reconstructs the rest. For reasoning models there is a second effect that matters more than the token accounting: the model's own reasoning items can persist across a tool call instead of being discarded, so after a tool returns, the model resumes a plan rather than re-deriving one from the visible transcript. That property is the reason a third-party provider bothers implementing the surface at all. DeepSeek describes its beta as native Responses support, so the field names your client sends come from that spec, and DeepSeek's docs are where you confirm which parts of it the beta actually implements.

The mechanism carries a bill. Your conversation state now lives on DeepSeek's infrastructure, subject to whatever retention and residency terms the platform publishes. Turn server-side storage off for compliance reasons and chaining stops working, which puts you back to resending arrays. Debugging gets harder, because the exact prompt the model saw is assembled somewhere you cannot inspect. Portability drops too. An agent written against server-side state needs its state layer rewritten before it runs anywhere else; swapping a base URL will not move it.

Get a key, read the endpoint off the docs, pin the dated model ID

• Key: create one in the DeepSeek platform console under API keys. Export it as an environment variable rather than pasting it into code, since CLI harnesses expect to read it from the environment.
• Endpoint: take the base URL and the exact path the beta serves the Responses surface on from DeepSeek's own API documentation, not from a launch thread or a copied snippet. A compatibility layer shipped on the same day as a launch is the most likely thing in this stack to move.
• SDK: DeepSeek has documented OpenAI-SDK compatibility for its existing endpoints. Whether that compatibility extends to the beta's Responses surface, and to which client versions, is a documentation question worth answering before you assume your current client works unmodified.
• Model ID: use deepseek-v4-flash-0731 in anything you deploy. Undated aliases float to whichever build is current, which is convenient in a notebook and a silent behavior change in production. Pin the date, and treat a model ID bump as a deploy that needs a regression pass.

Chain turns by id instead of resending the array

The first call looks like a Chat Completions call with different field names. You pass a model, an input, and a tools list. What comes back is a response object containing an id and a list of output items, which may include a tool call, a message, or reasoning content the model wants carried forward.

The loop is where the difference shows up. When the output contains a tool call, you execute it locally and send the result back as a new input item, referencing the id you just received. You do not resend the system prompt. You do not resend the prior tool results. If your existing agent framework was built around rebuilding a messages array every iteration, the migration is mostly deletion, and the thing that breaks first is any code that assumed it could inspect or mutate the full prompt before each call.

One practical note for anyone porting from Chat Completions: response ids are the state. Losing one, or letting a retry fire against a stale id, orphans the branch. Store the latest id next to your run record with the same care you would give a database transaction handle.

Point Codex CLI at it as a custom provider

Codex CLI supports third-party model providers through its configuration file, which is where native Responses support pays off, because the CLI can speak that wire format rather than falling back to a chat shim. Register DeepSeek as a provider with the endpoint and key you set up above, then select it along with the dated V4-Flash model ID. The provider block's field names have shifted across Codex releases, so read the current schema from Codex's own configuration docs rather than trusting a block pasted out of any tutorial, this one included.

If the CLI starts cleanly and then fails on the first tool call rather than at startup, check the provider's protocol setting before you suspect the model. A provider pointed at the older chat format will complete a plain turn happily and fall over the moment the agent tries to call a function. Other harnesses that accept a custom OpenAI-compatible endpoint, including Aider and the model settings in Cursor, take the same endpoint and key, though whether they use the Responses surface or the older one depends on the harness, not on you.

DeepSeek says 0731 beats the V4-Pro preview on agent tasks

The headline claim in DeepSeek's own launch announcement on July 31 is that V4-Flash clears the agent benchmark results previously posted for the V4-Pro preview. The post travelled a long way, past 7.8 million views and 28,000 likes on X within the launch window, which tells you about developer appetite for a cheap agent-grade model and nothing at all about the measurement.

The baseline is a preview build of DeepSeek's own larger model, on a task mix DeepSeek picked and scored. Every lab reports itself this way, including the ones behind Claude and GPT-5.6 Sol. The number describes what DeepSeek optimized for. What your workload does is a separate question.

What's underappreciated here: on agent evaluations the harness moves the score about as much as the weights do. Retry policy, tool-schema wording, how many steps before a forced stop, whether reasoning survives a tool boundary, change any one of those and the same model posts a materially different result. Which is why a vendor shipping native Responses support in the same release as an agent benchmark claim is quietly telling you the benchmark probably ran on a stateful loop. If your production agent still rebuilds a messages array every turn, you are not running the configuration that produced the number.

The claim is unverified rather than wrong. No independent agentic leaderboard has published a result for deepseek-v4-flash-0731 yet, and a beta endpoint whose rate limits and defaults are still moving makes a poor subject for reproducible evaluation anyway.

Public beta means no waitlist and no SLA

Public beta, as of July 31, 2026, is the whole of what DeepSeek has said about access. The label conventionally reserves a set of rights for the provider: rate limits adjusted without notice, default parameters behind the endpoint changed, features accepted by the request schema only partially implemented. A beta endpoint that returns 200 is not the same thing as a beta endpoint that did what you asked. Log the full response object during your first week, not just the text you rendered.

Cost is the reason most people are reading this at all, and it is where the beta is thinnest on published detail. DeepSeek's July 31 announcement resolves no pricing for the new endpoint. Take the platform's own pricing page as authoritative for the tier you are on, read it after you have confirmed which model ID your key actually resolves to, and instrument your spend from the first call rather than budgeting from a launch thread.

Which leaves the figure nobody outside DeepSeek can currently reproduce: what a chained Responses turn bills as. When the server reconstructs a fifty-thousand-token history your client never transmitted, whether those tokens are invoiced as fresh input, at some cached rate, or not at all is the variable that decides whether V4-Flash stays cheap across long agent runs. That number sits in DeepSeek's meter. The docs do not give it.