How do you use DeepSeek-V4-Pro for coding?

DeepSeek moved DeepSeek-V4-Pro out of preview on August 13. The model name in the API stays deepseek-v4-pro, and the finished version brings three changes that matter for programmers: better performance as an agent, an adjustable reasoning effort (low for simple jobs, high for everyday agent work, max for hard problems), and native support for OpenAI's Responses API, which lets coding tools built for that interface use it directly. New prices took effect on August 16, with cheaper off-peak hours.

The model can keep up to a million tokens in view, enough for a large slice of a codebase, and can write up to 384,000 tokens in one reply. By default it thinks before answering, which makes replies longer and slower but usually more careful.

Three ways to put it to work

1. In the chat app. On DeepSeek's website and app, V4-Pro is the model behind Expert Mode. It is fine for explaining code or sketching a function, but you will copy and paste a lot.

2. Through the API, from a script. DeepSeek's API accepts the OpenAI format at https://api.deepseek.com, so the OpenAI Python library works unchanged:

import os
from openai import OpenAI

client = OpenAI(base_url="https://api.deepseek.com", api_key=os.environ["DEEPSEEK_API_KEY"])

with open("dates.py") as f:
    code = f.read()
with open("test_dates.py") as f:
    test = f.read()

reply = client.chat.completions.create(
    model="deepseek-v4-pro",
    reasoning_effort="high",
    messages=[
        {"role": "system", "content": "You are a careful Python reviewer. Change as little code as possible."},
        {"role": "user", "content": f"This test fails:\n{test}\n\nCode:\n{code}\n\nExplain the cause in two sentences, then give a unified diff."},
    ],
)
print(reply.choices[0].message.content)

3. Inside a coding agent. A coding agent reads files, runs commands and edits code on its own. DeepSeek offers a second address, https://api.deepseek.com/anthropic, for tools that speak Anthropic's format, and says its new Responses API support is tuned for OpenAI's Codex. Point the tool at the right address, set the model to deepseek-v4-pro, and keep the agent's usual safety settings, such as asking before it runs commands.

A worked bug fix

The illustrative bug: a function that counts working days between two dates includes the end date when it should not, and a test catches it. The prompt that works best is narrow and gives the model the evidence:

The test test_two_week_span fails: expected 10, got 11.
Here are dates.py and test_dates.py.
1. Explain the cause in two sentences.
2. Propose the smallest fix as a unified diff.
3. Add one more test for a span that starts on a Saturday.
Do not change the function's signature.

Three habits make the difference. Give the failing test, not just "it's broken": the model can then check its reasoning against a concrete expectation. Ask for the cause before the fix, so you can judge the explanation before reading code. And ask for a unified diff, the standard format that shows only changed lines, so the review takes a minute rather than ten. Then run the tests yourself. A fix that the model says is correct is a proposal until your test suite agrees.

How does it compare on cost?

API prices are quoted per million tokens, the chunks of text a model reads and writes (a token is roughly three-quarters of an English word). DeepSeek charges less for input it has seen recently, a cache hit, and it now has two price periods: peak hours from 01:00 to 04:00 and 06:00 to 10:00 UTC, and off-peak at half price the rest of the day. In the eastern half of North America in summer, peak falls in two blocks between 9 p.m. and 6 a.m., so a normal workday is off-peak.

For a feel of real costs, take an illustrative coding request with 40,000 input tokens (several files plus instructions) and 8,000 output tokens (reasoning, explanation and diff):

On list prices, V4-Pro off-peak comes to roughly a tenth of Claude Opus 5 for the same token counts, and V4-Flash to a third of V4-Pro. Two cautions keep this honest. Models count tokens differently and think for different lengths, so the same task can produce different token totals on each. And the cheapest request is the one you do not have to repeat: if a stronger model fixes a bug in one try where a cheaper one needs three, the difference shrinks.

A practical approach is to run your own five or ten real tasks through each candidate, record the token counts from each API's usage report, and check how many fixes pass your tests. Then decide on cost per passing fix rather than price per token. Also consider where your code goes: the hosted API sends your code to DeepSeek's servers, so keep proprietary or client code out unless your agreements allow it.