DeepSeek V4 Flash 0731 API: What It Is, Pricing & How to Access It (2026)

A production job that sends 240,000 input tokens and receives 12,000 output tokens would cost about $0.02136 on DeepSeek V4 Flash 0731 at its listed vendor rates. That is less than three cents for a request large enough to include a substantial repository, months of support transcripts, or several long documents.

The headline number is attractive, but price alone does not tell you whether a newly released model belongs in production. DeepSeek V4 Flash 0731 combines extremely low token pricing with a 1,048,576-token context window, while important details—benchmark results, provider-specific limits, architecture, and long-context reliability—are still emerging.

Here is what developers can confirm today, what remains uncertain, and how to test the model without building an integration you will regret later.

What is DeepSeek V4 Flash 0731?

DeepSeek V4 Flash 0731 is a newly available DeepSeek model exposed through OpenRouter under this identifier:

deepseek/deepseek-v4-flash-0731

The published API metadata provides three concrete facts:

• Context length: 1,048,576 tokens
• Prompt price: $0.00000008 per token
• Completion price: $0.00000018 per token

Expressed in the more familiar per-million-token format, that is:

DeepSeek is the model developer. OpenRouter is an API routing layer through which the model can be selected; it should not be confused with the model maker or necessarily the underlying inference provider.

The “Flash” name suggests a speed- and cost-oriented model, but naming is not a benchmark. Until reproducible latency, quality, and throughput data is available across multiple providers, I would treat “Flash” as product positioning rather than proof of a specific performance tier. Similarly, 0731 appears to be a version or build label. Do not assume it guarantees a particular training cutoff or release date unless that is explicitly documented.

Where it fits in the 2026 model landscape

The model market is no longer a simple contest for the highest aggregate benchmark score. Teams now choose models along several axes: reasoning quality, latency, context size, tool use, output reliability, data controls, and cost.

DeepSeek V4 Flash 0731 enters the cost-efficient, long-context part of that market. Its most obvious comparisons are fast models from DeepSeek, MiniMax, and Qwen, although teams will also evaluate it against Claude-family options such as Sonnet 4.6, Haiku 4.5, Fable 5 with 1M context, and deployments labeled Claude gpt-5.6-sol, plus GPT-5.5 and Gemini 3.

Availability and exact capabilities for those names can vary by platform and deployment. A gateway label is not always identical to a first-party model name, so verify the model ID, context limit, tool support, and pricing on the endpoint you actually use.

This table is deliberately not a quality ranking. Newly launched models need task-specific evaluation. A cheap model that produces malformed JSON 4% of the time can be more expensive operationally than a higher-priced model that reliably completes the workflow.

The standout feature is the 1M-token context window

A context length of 1,048,576 tokens is exactly 2²⁰ tokens. In practical terms, it can accommodate far more material than a conventional chat request:

• A large collection of technical documentation
• Extensive application logs
• Hundreds of source files
• Long legal or financial document sets
• Multi-session agent state
• Large retrieval batches

A common gotcha is treating context capacity as recommended request size. It is only a ceiling. Sending one million tokens on every call can increase latency, dilute relevant evidence, and make failures expensive even when the token rate is low.

Context limits also commonly include some combination of input, generated output, system instructions, and tool definitions. Do not assume you can send exactly 1,048,576 input tokens and still request a long completion. Provider implementations may reserve output capacity or enforce a lower operational limit.

In practice, I would start with a retrieval layer even when the model can hold the entire corpus. Retrieve the most relevant 20,000–100,000 tokens, preserve source metadata, and expand only when evaluation demonstrates that the extra context improves answers.

Calling the API with an OpenAI-compatible client

OpenRouter exposes an OpenAI-style chat completions interface. A minimal request looks like this:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v4-flash-0731",
    "messages": [
      {
        "role": "system",
        "content": "Return concise, technically precise answers."
      },
      {
        "role": "user",
        "content": "Explain why idempotency keys matter in payment APIs."
      }
    ],
    "temperature": 0.2,
    "max_tokens": 800
  }'

With the OpenAI Python SDK, change the base URL and model name:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["OPENROUTER_API_KEY"],
    base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
    model="deepseek/deepseek-v4-flash-0731",
    messages=[
        {
            "role": "system",
            "content": "You review Python code for correctness and security.",
        },
        {
            "role": "user",
            "content": "Review this function:\n\n"
                       "def divide(a, b):\n"
                       "    return a / b",
        },
    ],
    temperature=0.1,
    max_tokens=1000,
)

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

if response.usage:
    print(
        "tokens:",
        response.usage.prompt_tokens,
        response.usage.completion_tokens,
    )

Pin your client library version in production, apply request timeouts, and log the returned model and usage fields. Routing layers can normalize APIs, but provider behavior around error codes, finish reasons, tool calls, and streaming can still differ.

Using an Anthropic-compatible interface

An OpenAI-compatible endpoint is not automatically compatible with the Anthropic Messages API. If your platform or multi-model gateway offers an Anthropic-compatible adapter, the request shape typically looks like this:

curl "$GATEWAY_BASE_URL/v1/messages" \
  -H "x-api-key: $GATEWAY_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "deepseek/deepseek-v4-flash-0731",
    "max_tokens": 800,
    "system": "Return concise, technically precise answers.",
    "messages": [
      {
        "role": "user",
        "content": "Explain optimistic concurrency control."
      }
    ]
  }'

The important detail is the adapter. OpenRouter’s standard chat-completions endpoint uses an OpenAI-shaped schema; do not point an Anthropic SDK at it and expect automatic translation. Confirm that your gateway maps system messages, content blocks, tool calls, streaming events, stop reasons, and token usage correctly.

AI Prime Tech is another option for teams that want cheaper multi-model API access across Claude, GPT, and Gemini, with advertised savings of up to 80%. Regardless of gateway, compare the final routed price and supported features rather than assuming every model has identical capabilities on every endpoint.

What requests actually cost

The cost formula is straightforward:

cost = (input_tokens × $0.00000008)
     + (output_tokens × $0.00000018)

For a request containing 240,000 input tokens and 12,000 output tokens:

input:  240,000 × $0.00000008 = $0.01920
output:  12,000 × $0.00000018 = $0.00216
total:                            $0.02136

Several representative workloads illustrate the pricing:

The near-full-context input alone costs approximately $0.08389. That is inexpensive, but repeated agent loops change the calculation. Ten such calls cost roughly $0.85; 100,000 calls would be a material infrastructure bill.

These estimates use the stated vendor token rates only. Your actual invoice may include gateway markups, routing differences, taxes, minimum charges, or separate pricing for caching and other features. Cached-input discounts should not be assumed unless the selected provider explicitly exposes them.

How I would evaluate it before production

A polished demo is not enough. I would build a 50–200-case evaluation set drawn from real traffic and compare the model against one existing production model.

Measure:

• Task success, not subjective eloquence
• JSON-schema and tool-call validity
• Citation or evidence fidelity for long documents
• Latency at p50 and p95
• Input and output token consumption
• Retry and timeout rates
• Performance as context grows
• Total cost per successful task

Long-context testing deserves special attention. Run the same evidence-retrieval task at 25K, 100K, 500K, and near the supported limit. Place decisive facts near the beginning, middle, and end. What actually matters is not whether the API accepts one million tokens, but whether the model consistently uses the right information inside them.

Architecture details, benchmark standing, multimodal support, tool-calling behavior, rate limits, and production latency should be treated as emerging until they are clearly documented and independently reproducible. Avoid inferring those capabilities from the V4 or Flash labels.

Practical takeaways

• DeepSeek V4 Flash 0731 is available as deepseek/deepseek-v4-flash-0731.
• Its listed context window is 1,048,576 tokens.
• Vendor pricing is $0.08 per million input tokens and $0.18 per million output tokens.
• Use OpenRouter’s OpenAI-compatible chat-completions endpoint directly; use Anthropic request syntax only through a gateway that explicitly translates it.
• A large 240K-input, 12K-output request costs about $0.02136 before gateway-specific charges.
• Treat the 1M context limit as capacity, not an instruction to skip retrieval.
• Benchmark quality, latency, structured output, and long-context recall on your own workload.
• Keep the model ID configurable so you can route difficult requests to a stronger model without rewriting the application.
• Regard undocumented architecture and performance claims as unconfirmed while launch details continue to emerge.