deepseek-v4-pro: DeepSeek V4 Pro, the 1.6T open-weight MoE flagship, as a metered API

deepseek-v4-pro is this platform's serving alias for DeepSeek V4 Pro, DeepSeek's flagship open-weight model. The model carries 1.6 trillion total parameters, with about 49 billion active per token. It has a one-million-token context window, and its weights are MIT-licensed. The name needs unpacking twice this month. Once for version: the model shipped as a preview on April 24, 2026. Its general-availability release landed August 13, 2026. The checkpoint is the one the publisher calls DeepSeek-V4-Pro-0813. Once for lifecycle: September's retirement wave at the publisher's first-party API took the flash tier's old names. It was widely reported as coming for this one on September 14. The publisher's own change log decided otherwise. The section below shows what a dated read of the official pages actually supports. This page fixes both mappings with dated official sources. It traces every spec number to its owner, and lays out the request shape you send here today. The console's invite flow is the way in while the platform is in beta, and this page is the preparation.

Last verified: 2026-09-25

What it is

DeepSeek V4 Pro is a sparse mixture-of-experts model. The full network holds 1.6 trillion parameters. But only about 49 billion fire on any given token. That is how a model this large answers at usable speed. The counts come from the preview repository's download table, the official statement of them. The GA card itself lists no parameter counts. Per the official GA card, DeepSeek-V4-Pro-0813 is the official release of DeepSeek-V4-Pro. It supersedes the preview version with greatly enhanced agentic capabilities. It is built on the preview structure with a DSpark speculative decoding module fused into the checkpoint. Speculative decoding means a small draft module guesses ahead and the big model verifies. Tokens arrive faster than the 49B-active core could write them alone.

The family map, because the name alone will not tell you which model answers:

The September wave: what actually happened to pro

One date matters more than the rest, and it is not the one the reports gave. On September 10, 2026, per the official change log, DeepSeek released V4.1-Flash and retired the V4 Flash generation from its first-party API. The same entry carries the pro decision in the publisher's own words. DeepSeek will "continue providing API services for DeepSeek V4 Pro after September 14, 2026, with the billing method remaining unchanged." Search overviews and third-party write-ups had been reading that date as pro's end. The name would be rerouted to the new flash model and billed at its prices, they said. The record says otherwise. So does the live state. A read of the official pricing page on September 24, 2026 still lists deepseek-v4-pro. It is still served and still billed as the 0813 line. The retirement that actually happened in September was the flash tier's. This platform's flash lane, deepseek-v4-flash-0731, pins that generation's GA snapshot. None of this asserts what the publisher does next; it states what the change log says and what a dated read shows. And none of it touches the weights. The preview, the GA checkpoint, and a Blackwell-optimized variant remain public under MIT licenses. The base training checkpoints sit alongside them. And third-party hosts keep serving the 0813 generation by checkpoint. A first-party decision is an API-name event. The model itself stays alive anywhere someone chooses to serve it. And what this platform does is fixed either way: the alias here pins the checkpoint, serving the 0813 GA weights the name should mean.

The specs that matter for planning, each with its owner:

A pair of rows call for plain words. The context window: the publisher's own configuration sets 1,048,576 tokens, and that is the number a buyer should treat as the model's. Provider directories show the same 0813 checkpoint served with output caps anywhere from 64K to the full window depending on the host. So when a ceiling matters to your workload, ask the specific endpoint what it serves. The modality row: this model reads and writes text. Vision belongs to the newer flash generation at the first party, not to this one. So image input is the wrong reason to be on this page.

Thinking control is a first-class feature of this generation. The GA release carries three effort levels, low for simple tasks, high for daily agent work, and max for hard problems, selected through the reasoning_effort control. Thinking is on by default. One structural note for self-hosters, identical to the flash sibling's: the release ships no Jinja chat template. The repository provides an encoding folder. Its scripts turn OpenAI-format messages into the model's input format and parse its output back. Serving stacks apply that encoding for you when configured for the DeepSeek V4 tokenizer. A hosted API absorbs this entirely.

On this platform the alias is deepseek-v4-pro, one chat lane among the chat catalog, with the models index tracking the catalog as it stands. The row is live. The page's numbers describe the 0813 GA release, the version the publisher's own table lists for this name and the checkpoint the row serves.

Use cases

The GA release exists for one headline, and the record supports it:

• Agentic coding and terminal work. The publisher's GA table puts the 0813 release at 87.9 on Terminal Bench 2.1 and 62.7 on DeepSWE, evaluated with a named harness at the max effort level, against the preview's 72.1 and 12.8. A jump that size inside one generation is rare, and it is the release's whole reason to exist.
• Tool-calling agents. The platform's chat route accepts and forwards the standard OpenAI tool shapes (tools, tool_choice), and this model's encoding keeps earlier reasoning turns in context when tools are in play, which is the behavior agent loops need to track multi-step work.
• Long-context reading. A million-token window holds whole repositories, long transcripts, or full document sets in one request. It is also where host shopping matters most, because a capped window is usually discovered mid-project.
• Knowledge-heavy work. The family's April announcement led with world knowledge, claiming the preview ahead of other open models of its day, and the GA release carries that posture forward. Treat it as the publisher's framing; the benchmark section below shows what is measured and what is claimed.
• What it is not. It is not a vision model, and it is not the newer V4.1-Flash architecture; that model succeeded the flash tier at the first party, not this one. None of that changes what the weights do.

Who serves V4 Pro: three paths compared

The September wave was real, but it took the flash tier's names, not this lane. Three serving paths exist regardless. The honest differences between them are the point.

Serve it yourself when the data must stay inside a boundary you control. Or serve it yourself when you want to fine-tune the checkpoint. The tooling is real: MIT weights on Hugging Face and ModelScope. GGUF quantizations come from the runtime vendors that publish them. First-class support sits in the vLLM serving recipe. The recipe walks the four published checkpoints (GA 0813, preview, the Blackwell NVFP4 variant, and the preview-plus-draft build). The floor is the story: about 893 GB of fused checkpoint, and official recipes targeting eight-GPU nodes. One common GPU configuration carries an 800K context cap. Another adds a two-tray requirement. Community quantization guides put a 4-bit build near 870 GB of memory. This is the datacenter sibling; the flash model is the one that fits a serious workstation.

Use a third-party host when you want the model without the datacenter. Provider directories list dozens of hosts serving the 0813 checkpoint today. The one check that matters is the one this page keeps repeating: confirm which checkpoint a host pins and what context and output ceilings it actually serves. Listings disagree with each other on this model family more than on any other.

Use this platform when you want the model by name on a metered route. The deepseek-v4-pro row is live here: per-token metering against a prepaid wallet. Each response carries its own cost line, and per-key revocation is immediate. And the invitation queue below stands open.

API usage

Calls go to POST /v1/chat/completions with a console-issued Bearer key, OpenAI-compatible in shape. The model id is deepseek-v4-pro. The route is live. What follows is the contract as it stands.

Three laws of this lane that save debugging time:

1. The examples carry no thinking knob, on purpose. The publisher documents three effort levels for this generation, low, high, and max, selected through reasoning_effort, plus a thinking toggle, with thinking on by default. This platform's contract accepts a top-level reasoning_effort parameter, with the values minimal, low, medium, and high accepted at the contract; a value outside the accepted set is rejected with a named parameter error. How those values map onto the publisher's three depths follows the platform contract, so the tabs show only what is guaranteed. Do not send the publisher's nested template fields yourself; nested bodies sit outside this platform's accepted surface and are answered with a named parameter error. The accepted set can also grow, so treat the table above as the current surface, not a frozen contract.
2. Thinking tokens are real output. When thinking is on, the model's reasoning is generated text: it is metered, it takes time, and the card recommends allowing up to 384K output tokens at the high and max levels. A max-effort run on a hard problem is a long run, so budget output headroom and client timeouts accordingly.
3. Every response carries its own receipt. The usage object on the reply holds the retail charge for that call, derived from the token counts, and the prepaid wallet is debited in the same transaction that logs the call. That wallet balance is the spending stop. Spend caps per key have not shipped; turning off one key is instant. The pricing page renders the rates from the catalog.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "messages": [
      {"role": "user", "content": "Review this migration plan and list every step that breaks under concurrent writes."}
    ],
    "max_tokens": 4096
  }'

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "deepseek-v4-pro",
        "messages": [
            {"role": "user", "content": "Summarize this incident log and rank the three likeliest root causes."},
        ],
        "max_tokens": 8192,
    },
    timeout=600,
)
resp.raise_for_status()

message = resp.json()["choices"][0]["message"]
# When thinking is enabled on a lane, deliberation arrives in a
# separate reasoning field and the answer itself in content.
# Reasoning tokens are output tokens and are metered as such.
print("answer:", message["content"])
print("usage:", resp.json()["usage"])

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Check the refund rules and draft the policy update section."},
    ],
    tools=[
        {
            "type": "function",
            "function": {
                "name": "search_docs",
                "description": "Search the internal handbook",
                "parameters": {
                    "type": "object",
                    "properties": {"query": {"type": "string"}},
                    "required": ["query"],
                },
            },
        }
    ],
    tool_choice="auto",
    max_tokens=8192,
)

message = response.choices[0].message
if message.tool_calls:
    call = message.tool_calls[0]
    print(call.function.name, call.function.arguments)
else:
    print(message.content)

An existing OpenAI-SDK integration transfers with two lines: the base URL and the model id. Integrations written against the publisher's own API transfer the same way, since that API is OpenAI-compatible too. One difference is worth repeating: at the first party a name tracks whatever the publisher's current line serves, and the September changes show how fast a name can move. This platform's alias exists to pin and serve this checkpoint by name.

Benchmarks

The evidence below comes in three layers, all labeled, all dated. The lane here is live, but the platform has published no benchmark runs of its own. So nothing here is our own measurement.

The publisher's GA table. Self-reported, from the official GA card, released August 13, 2026 and mirrored in the official change log. Methodology per the card: code-agent tasks ran with the minimal mode of DeepSeek's harness at the max effort level, temperature 1.0, top_p 0.95. The two DSBench rows are internal test sets, not public benchmarks.

Carry the label with you as you read: publisher-reported, reference configuration, comparators chosen by the publisher. The shape that holds up: a very large step over its own preview on every row. It sits at or near the top of the published agentic set. The hardest reasoning rows still go to the strongest proprietary models. The preview column doubles as version evidence: it is what a marketplace page pinned to April numbers shows you.

The independent point. The publisher's September 10 release note says testing by multiple parties puts the newer V4.1-Flash ahead of V4 Pro across performance, cost, speed, and total time. That claim came with the flash tier's retirement. That is a vendor claim about its own models. One independent index has since scored the pair on the same scale with V4.1-Flash ahead on the composite measure. It is a single third-party datapoint, quoted here by class and date rather than linked, and it measures an aggregate, not any row above. The honest summary: the claim is plausible and partially verified. Your workload is the arbiter that matters.

Community calibration. The September wave's reception was split in an informative way, and the split tracks the confusion the change log settled. A large community thread framed the change as a soft retirement and shopped alternatives. The character and roleplay user base, which runs on this model heavily, read the reported reroute as a forced downgrade. Those reads were reactions to the flash retirement generalized onto pro, not to the pro decision the changelog actually records. Separately, practitioners of the newer flash class report coding-harness failure modes: loops, early terminations, and malformed tool calls. Those reward disciplined harnesses or a larger model. Put together: if V4 Pro is your model, the open weights and the hosts that serve them are the path that keeps it answering regardless of any first-party decision. And any migration decision deserves your own regression run first.

Getting started

1. Register on the console. While the platform is in beta the invite flow is the way in: an open account can call every served model the day it appears.
2. Cut an API key. One per project is the working pattern, and each key is its own kill switch: an exposed key is revoked alone, the others unaffected.
3. Check the rate. Per-token rates live on the pricing page and the per-call cost field settles each response; the same catalog that meters the route renders those numbers, so nothing is retyped.
4. Make the first call. Take the curl tab, export KEY, and keep the opening request modest so the first response is quick. A working first call means the rest is just bigger messages payloads.

More chat lanes are rounded up on the chat category page. The models index carries the platform's served map.