To call the DeepSeek V4 Flash API, send requests to https://api.deepseek.com with the model ID deepseek-v4-flash and a DeepSeek API key. As of 2026-07-31, that stable ID serves DeepSeek-V4-Flash-0731, the official release now in public beta per the DeepSeek changelog. You can reach the same model through three surfaces: OpenAI-compatible Chat Completions, an Anthropic-compatible endpoint, and a native stateless Responses API. The official API is text-only, supports up to 1M tokens of context with up to 384K output, and is usage-priced (see current DeepSeek V4 Flash pricing). This page is an independent, unofficial guide from the DeepSeek fans behind DeepSeek V4 Flash; it is not affiliated with DeepSeek.
DeepSeek V4 Flash API Quick Start
The correct model ID
The API model ID is exactly deepseek-v4-flash, lowercase with hyphens, as listed by the official List Models endpoint and the pricing page as of 2026-07-31. Do not send the Hugging Face repository name deepseek-ai/DeepSeek-V4-Flash-0731 as the model parameter; that string names the model version and open-weight repository, not the API ID. The distinction matters this week: on July 31 DeepSeek re-pointed deepseek-v4-flash from the April Preview to the 0731 release with no code change required (changelog). If your prompts were tuned on the Preview, see what changed in the 0731 release and rerun your evaluations.
Base URL and API authentication
The base URL for OpenAI-style calls is https://api.deepseek.com, shown in the official first API call guide. Authentication uses a bearer API key created in the DeepSeek open platform console after registering an account; the key is passed in the Authorization: Bearer header, or as the api_key value when you use the OpenAI SDK with a custom base_url. The Anthropic-compatible surface uses a different base URL, https://api.deepseek.com/anthropic, with the same key supplied as the Anthropic-style auth token per the official Claude Code integration guide (retrieved 2026-07-31). Keep the key server-side: DeepSeek billing is per token, so a leaked key becomes someone else's agent budget.
How to verify the model being served
Two checks take a minute and prevent version confusion. First, call the List Models endpoint and confirm deepseek-v4-flash appears for your account. Second, inspect a real response: the model field echoes the ID, and the pricing page names the version currently behind it (DeepSeek-V4-Flash-0731 as of 2026-07-31). This verification matters most when you are not calling DeepSeek directly - third-party resellers can serve an older checkpoint under a similar name, a live problem documented in the provider section below. If a tool asks you to pick between "Preview" and "0731", the official first-party API offers no such choice: the stable ID always serves the current version.
Three DeepSeek V4 Flash API Surfaces
OpenAI-compatible Chat Completions
Chat Completions at https://api.deepseek.com/chat/completions is the default surface and the one the official API reference documents most completely. It accepts OpenAI-format message arrays with text content and supports streaming, JSON output, and tool calls through the standard OpenAI SDKs. It is stateless: you resend conversation history on every request, and the context-caching system prices repeated prefixes at the cache-hit rate automatically (a large cost lever explained on the pricing page). Choose this surface when you control the client code or your tool already speaks the OpenAI protocol; it is the most complete of the three and the only one with beta prefix-completion and FIM extras.
Anthropic-compatible endpoint
The Anthropic-compatible endpoint at https://api.deepseek.com/anthropic accepts Anthropic Messages-format requests so that tools built for Claude models, most prominently Claude Code, can talk to DeepSeek V4 Flash without code changes (official guide, retrieved 2026-07-31). Compatibility is field-by-field, not identity: the official compatibility table marks image and document content blocks as Not Supported, and DeepSeek documents a model-name mapping in which claude-opus-prefixed names resolve to deepseek-v4-pro while claude-sonnet and claude-haiku names resolve to deepseek-v4-flash (Claude Code integration, retrieved 2026-07-31). That silent mapping can hide a misconfiguration: a Claude-style alias may route you to Pro when you meant to test Flash (see DeepSeek V4 Flash vs V4 Pro). Prefer explicit DeepSeek IDs over aliases.
Native Responses API
The Responses API, added with the 0731 release, is a native implementation of the OpenAI Responses protocol shape at the same https://api.deepseek.com base, called via client.responses.create() in the OpenAI SDK (official guide, retrieved 2026-07-31). Two constraints define it. It currently supports only deepseek-v4-flash - the guide says deepseek-v4-pro support is planned for early August 2026, a forward-looking date to recheck. And it is stateless by design, so it is compatibility with the Responses request format, not full OpenAI Responses parity. DeepSeek states it built this surface for Codex compatibility, which is why Codex is the flagship integration. If you do not specifically need Codex or the Responses request shape, Chat Completions remains the simpler default.
DeepSeek Responses API Support
Streaming, functions, and web search
Within its documented limits, the Responses API covers the core agent loop. Streaming uses typed server-sent events and terminates with response.completed, response.incomplete, or response.failed rather than the Chat Completions-style data: [DONE] sentinel, so a client that string-matches on [DONE] will hang (Responses API guide, retrieved 2026-07-31). Function tools work, and server-side web search is available via the documented web_search tool types. The exact request and response schema is in the Create Response reference; code against that schema rather than OpenAI's, because several OpenAI fields do not exist here.
Custom tools and the apply_patch limit
Custom tools - free-form tool definitions outside the standard function-call JSON schema - are restricted to exactly one name: apply_patch, the diff-application tool Codex uses to edit files. Any other custom tool name returns HTTP 400 as of 2026-07-31 (Responses API guide). This is a deliberate Codex-compatibility carve-out, not a general custom-tool framework. If your agent design depends on custom tools with other names, route those flows through regular function tools or Chat Completions tool calling instead, and test the 400 path explicitly when porting an existing OpenAI Responses integration.
Unsupported state and storage features
Everything stateful in OpenAI's Responses API is absent here. previous_response_id, conversation, store, and background are documented as not supported; there is no file search, code interpreter, or computer-use tool, no prompt-caching configuration parameters, no metadata or safety-identifier fields, no truncation handling, and no service-tier options (itemized in the official guide, retrieved 2026-07-31). Your client owns conversation history and must resend it each turn, exactly as with Chat Completions. One sharp edge deserves emphasis: several unsupported request fields are silently ignored rather than rejected, so a request can succeed while a feature you thought you enabled did nothing. Verify behavior from responses, not from the absence of errors.
Thinking Mode and Reasoning Effort
Thinking on or off
DeepSeek V4 Flash runs with thinking either enabled or disabled per request (Thinking Mode guide, retrieved 2026-07-31). With thinking on, the model emits reasoning_content before the final answer; you pay for those tokens as output, so thinking mode trades latency and cost for accuracy on harder tasks. With thinking off, responses are faster and cheaper but weaker on multi-step problems - the vendor-reported spread across modes on the benchmarks page shows how large that gap can be. A practical default for agents: thinking on for planning and debugging turns, off for mechanical high-volume steps, measured against your own pass rate rather than assumed.
Low, high, and max effort
With thinking enabled, Flash accepts a reasoning_effort of low, high, or max (Thinking Mode guide and the 0731 model card, both 2026-07-31). Higher effort buys more reasoning tokens: DeepSeek's own 0731 benchmark table was produced at max effort, and the model card recommends allowing output up to the 384K limit at higher efforts, so budget for long generations. Note that DeepSeek's official benchmark settings also fixed temperature=1.0 and top_p=0.95, which matters if you are trying to reproduce vendor numbers. Effort is a per-request knob - a cost-aware pattern is low by default with escalation to high or max only on failed attempts.
Ignored sampling parameters and reasoning replay
Two documented behaviors break naive ports. First, in thinking mode the API accepts temperature, top_p, presence_penalty, and frequency_penalty for backward compatibility but ignores them (Thinking Mode guide, retrieved 2026-07-31) - so sampling sweeps in thinking mode measure noise. Second, for requests that carry the tools parameter, the reasoning_content from prior turns must be passed back in full on subsequent requests; the API returns a 400 error if your code drops it. Many frameworks strip fields they do not recognize, and this replay rule is the root cause behind a class of mid-conversation tool-loop failures. Without tools, prior-turn reasoning can be omitted freely.
Tool Calling and Structured Output
Function calls and JSON output
Standard OpenAI-format function calling works on Chat Completions in both thinking and non-thinking modes (Tool Calls guide, retrieved 2026-07-31): you declare tools with JSON Schema parameters, the model returns tool_calls, you execute and append results. For structured output without tools, JSON mode (response_format: {"type": "json_object"}) constrains responses to valid JSON; the JSON Output guide itself warns that the API may occasionally return empty content, and recommends prompting with the word "json" and an example schema, so add an empty-response retry to production code. Remember the interaction with the replay rule above: tool-bearing thinking-mode conversations must round-trip reasoning_content intact.
Strict mode and beta limitations
DeepSeek documents a strict mode for function calling that enforces the declared JSON Schema on arguments, but as of 2026-07-31 it is labeled beta with documented schema constraints - not every JSON Schema feature is accepted (Tool Calls guide). JSON mode likewise guarantees valid JSON, not conformance to your schema, so server-side validation stays your job. Related surfaces such as chat prefix completion and FIM are also beta. Treat beta labels as permission to change: pin integration tests to documented behavior and rerun them when the changelog moves. Third-party harness configs also disable unsupported fields - DeepSeek's own Oh My Pi example sets supportsToolChoice: false - so check your framework's mapping before blaming the model.
Context, Output, and Concurrency Limits
1M context versus 384K output
The official limits as of 2026-07-31 are a context window of up to 1M tokens (the open-weight config specifies 1,048,576 positions) and a maximum output of 384K tokens, per the pricing and model table. These are one budget, not two: input plus generated output must fit inside the context window, so a 900K-token prompt cannot receive a 384K-token answer. Capacity is also not a quality guarantee - retrieval accuracy at extreme depths is a separate, testable question covered on the DeepSeek V4 Flash context window page. For agent work, the practical implication is to reserve output headroom when you pack a repository into the prompt, especially at high reasoning effort where thinking tokens count against output.
Default account concurrency
DeepSeek enforces concurrency per account rather than requests-per-minute quotas: deepseek-v4-flash has a default account concurrency of 2,500 simultaneous requests as of 2026-07-31 (Rate Limit page). Exceeding it produces 429 responses until in-flight requests drain. The same page documents user_id-based isolation so one downstream user's burst does not starve the rest of your traffic, and notes that higher limits can be requested. Batch pipelines that fan out aggressively should still implement a client-side semaphore, because saturating the limit converts throughput into retry churn.
Client limits versus API limits
The number your tool shows is often not the API's number. DeepSeek's own integration examples prove the point: the official Pi configuration sets contextWindow: 1000000 and maxTokens: 384000, while other official client examples ship more conservative context values, and agents like Claude Code apply their own compaction thresholds well before 1M. When a harness truncates or compacts, that is a client decision, not a served-model limit. To find the active configuration, read your tool's model-config file or startup log rather than its marketing page, and confirm against the official limits. The context window page walks through inspecting effective limits in common tools.
Text, Image, and File Inputs
Why the API is text-only
As of 2026-07-31, the official DeepSeek V4 Flash API accepts text input only. The evidence is consistent across every first-party surface: Chat Completions message content is a text string (API reference), the Anthropic-compatibility table marks image and document blocks Not Supported (guide), the 0731 open-weight config.json contains no vision configuration, and official integration examples declare supportsImages: false. DeepSeek V4 Flash is a 284B-total, 13B-activated mixture-of-experts text-generation model; DeepSeek-OCR is a separate model family, and its existence does not add OCR to Flash. The full evidence trail, plus workarounds that route images through a separate vision stage, is on the vision and OCR page.
What happens to images and files in Responses API
The Responses API does not reject visual input loudly - it neutralizes it. Per the official guide (retrieved 2026-07-31), image and file input items are not supported, and an input_image block is replaced by placeholder text by the compatibility layer rather than producing an error. The model then answers from surrounding text as if the image were absent, which can look like a bad vision answer instead of a missing feature. If you port an OpenAI Responses integration that sends screenshots, add an assertion that strips or flags image items before the request, and log when it fires. Agents that appear to "see" images while using Flash are running a separate vision model or OCR tool upstream and passing extracted text - identify that component before attributing the result to Flash.
Errors and Production Checks
Authentication, quota, and 429 errors
The official error code table covers the codes you will actually meet: 400 for malformed requests (including the missing reasoning_content replay case with tools), 401 for a bad or missing API key, 402 for insufficient balance - DeepSeek is prepaid, so a working integration halts when credit runs out - 422 for invalid parameters, 429 for hitting the account concurrency limit, and 500/503 for server-side failures. Map these to different reactions: 401/402 should page a human, 422 means fix the request, and only 429/500/503 deserve automatic retries. During a launch window like 0731, transient 429 and 503 spikes can run above normal and are not necessarily your bug.
Retries, timeouts, and provider verification
Three production checks pay for themselves. Retry 429/500/503 with exponential backoff and a cap, and make retried work idempotent, because with thinking enabled a retried request re-bills its reasoning tokens - retries are a real cost line, as the pricing examples show. Set timeouts to match reasoning effort: a max-effort agent turn can legitimately run far longer than a chat-style default timeout, and premature client timeouts produce phantom failures plus paid, discarded output. Finally, log the model field and usage block of every response. That record proves after the fact which version served your traffic - useful now that the stable ID moved from Preview to 0731 - and it is the only reliable way to catch a misrouted alias when a request path goes through a proxy or reseller.
Coding-Agent Integrations
Codex through Responses API
Codex is the integration the Responses API was built for: DeepSeek states the API was added in response to Codex demand, and the official Codex integration guide (retrieved 2026-07-31) shows the configuration pointing Codex at https://api.deepseek.com with model deepseek-v4-flash. The apply_patch custom tool exists precisely so Codex's file-editing loop works unmodified, and the same configuration is documented to apply across Codex CLI and its editor extensions. Constraints carry over from the Responses API section: stateless operation, Flash-only support as of 2026-07-31, and text-only input, so Codex features that assume server-side state or screenshot input will not function. Start from the official guide's config rather than a generic OpenAI-provider template.
Claude Code through Anthropic compatibility
Claude Code connects through the Anthropic-compatible endpoint by setting ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic and supplying your DeepSeek key as the auth token; the official guide's environment block also pins model variables and sets CLAUDE_CODE_SUBAGENT_MODEL=deepseek-v4-flash, routing lighter subagent work to Flash (Claude Code integration, retrieved 2026-07-31). Because of the alias mapping described earlier, verify which DeepSeek model each role actually resolves to before trusting a comparison or a bill. Claude Code remains a third-party tool from DeepSeek's perspective, and its image-paste feature cannot work against a text-only backend. Setup steps, cost controls, and failure triage live on the dedicated DeepSeek V4 Flash with Claude Code page.
Third-party providers and alias freshness
Everything in this section is dated third-party information (evidence grade C, checked 2026-07-31), not official DeepSeek specification, and it changes fast. The launch-day trap is alias freshness: on OpenRouter, the long-standing deepseek/deepseek-v4-flash listing still described the April 24 revision (shown at $0.09/$0.18 per million tokens via various resellers), while the new checkpoint appeared as a separate slug, deepseek/deepseek-v4-flash-0731, with far fewer providers behind it. DeepInfra's model page likewise listed $0.09/$0.18 with an fp4 label and no revision marker, and the BytePlus ModelArk Coding Plan page was internally inconsistent, advertising "DeepSeek-V4 Series" in its marketing copy while its FAQ listed DeepSeek-V3.2. Provider pages may also rename controls - one lists "high and xhigh" reasoning efforts where the official parameter values are low, high, and max - and quantized deployments differ from first-party serving. Before relying on any reseller: confirm the revision from returned metadata or a dated slug, not the display name; compare the price against the official rates; and assume a matching price does not prove a matching checkpoint. Only DeepSeek's first-party API was confirmed serving 0731 across the sources we checked on launch day.
DeepSeek V4 Flash API FAQ
What is the DeepSeek V4 Flash API model name?
The model name is deepseek-v4-flash, exactly as listed by the official List Models endpoint as of 2026-07-31. DeepSeek-V4-Flash-0731 is the version currently served behind that stable ID and the name of the open-weight repository - do not use it as the API model parameter.
What is the DeepSeek API base URL?
The base URL is https://api.deepseek.com for Chat Completions and the Responses API, and https://api.deepseek.com/anthropic for the Anthropic-compatible endpoint (official docs, retrieved 2026-07-31). OpenAI SDK users pass the base URL as base_url together with their DeepSeek key.
How do I get a DeepSeek API key?
Register on the DeepSeek open platform, add prepaid credit, and create a key in the console; the first API call guide walks through the initial request. The API is prepaid, so a 402 error later means your balance ran out, not that the key broke.
Is the DeepSeek V4 Flash API free?
No. The hosted API is usage-priced - as of 2026-07-31, $0.0028 per million cache-hit input tokens, $0.14 cache-miss, and $0.28 output (official pricing). The 0731 weights being MIT-licensed does not make the API free, and we found no verified official free tier on 2026-07-31; see the pricing breakdown for real task costs.
Does the API support images or PDFs?
No. As of 2026-07-31 the official API is text-only: image and document blocks are marked Not Supported on the Anthropic-compatible endpoint, and the Responses API substitutes placeholder text for image items. Extract text with a separate OCR or vision stage first - details on the vision and OCR page.
Is the Responses API stateful?
No. DeepSeek's Responses API is explicitly stateless: previous_response_id, conversation, store, and background are not supported (official guide, 2026-07-31). Your client must resend the conversation each turn, so it is format compatibility with OpenAI's Responses API, not full parity.
Which API should I use for Codex?
Use the native Responses API - it exists for Codex, supports the apply_patch custom tool Codex needs, and has an official Codex configuration guide. As of 2026-07-31 it serves only deepseek-v4-flash, with Pro support stated as planned for early August 2026.
Can third-party providers serve an older checkpoint?
Yes, and on launch day they demonstrably did: OpenRouter's plain deepseek-v4-flash alias still described the April revision while 0731 lived under a separate dated slug (checked 2026-07-31). Verify the revision from response metadata or a dated slug before trusting any reseller, and treat price parity as no proof of checkpoint parity.