DEV Community

Ahab
Ahab

Posted on • Edited on • Originally published at indieseek.co

DeepSeek V4 Pro GA: Responses API, Thinking Effort, and Peak Pricing

#ai #programming #api #productivity

DeepSeek V4 Pro GA: verify Responses API, thinking effort, and peak pricing before rollout

Quick answer

DeepSeek-V4-Pro is now generally available in the DeepSeek app, web product, and API. The stable API name remains deepseek-v4-pro, but it now resolves to the August 13 snapshot, DeepSeek-V4-Pro-0813. The release also adds native OpenAI Responses API support, explicit low, high, and max thinking-effort controls, and official Codex integration.

There is a time-sensitive cost change. At 16:00 UTC on August 16, 2026, DeepSeek will replace the current flat token rates with peak and off-peak pricing. Peak hours are 01:00–04:00 and 06:00–10:00 UTC; all other hours are off-peak. In Beijing time, the peak windows are 09:00–12:00 and 14:00–18:00, and the new billing starts at 00:00 on August 17.

Do not treat GA as a model-string-only upgrade. Record the resolved snapshot, test both Responses API and existing Chat Completions paths, prove tool-loop state, measure low/high/max on representative agent tasks, and budget against the new peak table before promoting Pro.

Who this is for

This guide is for developers calling DeepSeek directly, routing it through an OpenAI- or Anthropic-compatible adapter, or using it as a Codex backend. It updates the earlier legacy-name migration on this canonical: deepseek-chat and deepseek-reasoner are no longer rollback targets.

If your route can execute repository commands, keep the untrusted-repository sandbox checklist independent of model choice. If you need a cheaper first route, evaluate V4 Flash before sending every task to Pro.

What changed on August 13

Boundary Confirmed state Operator consequence
Product availability V4 Pro GA in app, web, and API Verify each surface independently; API evidence does not prove a third-party client uses the same snapshot
API identity deepseek-v4-pro now serves DeepSeek-V4-Pro-0813 Log the resolved version or observation date, not only the moving alias
Agent interface Native Responses API, adapted for Codex Run a separate Responses acceptance suite before replacing Chat Completions
Thinking effort Actual levels are low, high, and max; default is high Do not assume every OpenAI-style label creates a distinct route
Pricing Peak/off-peak rates start August 16 at 16:00 UTC Add UTC scheduling and budget gates before unattended jobs
Context and output 1M context, up to 384K output Treat ceilings as limits, not as default prompt or output budgets

DeepSeek publishes substantial agent benchmark gains for the GA snapshot. Those results establish the release direction, not the acceptance rate of your repository, tool set, permission model, or latency budget.

Build the new cost table into routing

Current flat prices remain in effect until the changeover:

Model Cache-hit input Cache-miss input Output, per 1M tokens
V4 Flash $0.0028 $0.14 $0.28
V4 Pro $0.003625 $0.435 $0.87

From 16:00 UTC on August 16, the official table becomes:

Model and lane Cache-hit input Cache-miss input Output, per 1M tokens
V4 Flash off-peak $0.007 $0.22 $0.66
V4 Flash peak $0.014 $0.44 $1.32
V4 Pro off-peak $0.022 $0.66 $1.98
V4 Pro peak $0.044 $1.32 $3.96

Off-peak is half the new peak rate; it is not half the old flat price. For a Beijing operator, schedule deferrable batch work outside 09:00–12:00 and 14:00–18:00. Keep user-facing and incident-response traffic latency-driven, not price-driven.

Use cost per accepted task:

task_cost = cache_hit_input * hit_rate
          + cache_miss_input * miss_rate
          + output_tokens * output_rate

accepted_task_cost = total_task_cost / accepted_tasks
Enter fullscreen mode Exit fullscreen mode

Count retries and failed tool loops. A lower per-token lane can still lose if it needs more attempts.

A seven-gate rollout workflow

1. Inventory every release surface

Find deepseek-v4-pro, deepseek-v4-flash, retired aliases, base URLs, and saved client profiles in code, deployment variables, workflows, proxies, dashboards, and local agent configuration. Record whether each path uses Chat Completions, Responses, or the Anthropic format.

The OpenAI-format base URL remains https://api.deepseek.com; the Anthropic-format base URL remains https://api.deepseek.com/anthropic. Do not expose the API key in logs or acceptance artifacts.

2. Pin evidence around the moving alias

The API model string is stable, but the served snapshot can change. For every canary, record:

  • requested model: deepseek-v4-pro;
  • expected snapshot: DeepSeek-V4-Pro-0813;
  • request surface and SDK/client version;
  • UTC timestamp and price lane;
  • response model field or other provider evidence when available.

If the provider does not return an immutable snapshot ID, preserve the observation date and official changelog reference.

3. Make thinking effort explicit

Thinking is enabled by default at high. DeepSeek exposes low, high, and max. Compatibility labels do not all remain distinct: requests for medium or xhigh map to actual high.

Use low for bounded triage only after latency and quality pass. Use high for normal agent tasks. Reserve max for the hardest multi-step work, and set a token and tool-round budget because greater effort can increase cost.

If thinking is disabled, prove the client actually sent the disable control. Sampling fields such as temperature and top_p do not take effect in thinking mode even when compatibility code accepts them.

4. Test Responses API separately

Native Responses support removes an adapter translation layer, but it changes the integration surface. Run at least these canaries through the exact Codex or Responses client you intend to use:

Canary Pass condition
Read-only repository diagnosis Evidence cites the intended files; no write tool runs
Multi-file patch Only allowed files change; patch and tests complete
Parallel tool calls Call IDs and results reconcile exactly once
Permission denial The agent stops or requests authority; it does not route around the denial
Context pressure Compaction or truncation remains within the declared repository scope
Failed tool result Retry is bounded and final status is explicit
Resume or next turn Prior state is neither lost nor replayed as a duplicate side effect

The official Codex integration writes a model catalog and provider settings shared by Codex CLI, desktop, and the IDE extension. Back up and diff those files, validate them before replacement, and keep MCP and project-trust settings intact. Inspect any remote setup script before running it.

5. Preserve Chat Completions tool state

Existing Chat Completions adapters still need their own regression suite. When a thinking turn performs a tool call, DeepSeek requires the assistant message—including reasoning_content—to be passed back in subsequent requests. Dropping it can return HTTP 400.

Do not assume Responses state management and Chat Completions message replay are interchangeable. Keep separate fixtures and telemetry for each surface.

6. Compare Pro with Flash under one harness

Freeze at least 20 production-shaped tasks: repository diagnosis, implementation with tests, structured output, long context, tool failure, and rollback. Compare blind acceptance, unwanted edits, tool rounds, p95 latency, input/output tokens, cache-hit rate, and accepted-task cost.

Promote Pro only for routes where its measured gain justifies its higher price and lower documented concurrency limit. Keep V4 Flash for high-volume work that already passes.

7. Canary across both price lanes

Run shadow traffic first, then 5%, 25%, and target share. Include both a peak and off-peak window before calling the economics verified. Stop on lower acceptance, schema failures, repeated side effects, unbounded reasoning/tool loops, or a budget breach.

Rollback new sessions to the previous explicit V4 route or disable the provider. Retired legacy aliases are not a safe fallback.

Common mistakes

  • Calling the April preview article current after V4 Pro GA changed the snapshot, interfaces, and prices.
  • Recording only deepseek-v4-pro and losing evidence of the served snapshot.
  • Assuming medium and xhigh create new effort levels instead of mapping to high.
  • Calling off-peak “half price” without stating that it is half of the new peak rate.
  • Scheduling Beijing jobs from UTC labels without converting both peak windows.
  • Trusting a successful simple chat call as proof that Codex tools, permissions, resume, and patches work.
  • Dropping reasoning_content in a Chat Completions tool loop.
  • Piping a remote setup script into a shell without review, backup, diff, and rollback evidence.

Copyable rollout record 

date / owner / workload:
requested_model / expected_snapshot:
API_surface / SDK_or_client / base_url:
thinking: disabled | low | high | max
UTC_time / local_time / price_lane:
task_pack_revision / sample_count:
Responses_canaries / Chat_Completions_canaries:
tool_denial / failed_result / resume / duplicate_side_effect:
Flash_acceptance / Pro_acceptance:
Flash_p95 / Pro_p95:
Flash_accepted_task_cost / Pro_accepted_task_cost:
cache_hit_rate / tool_rounds / unwanted_edit_rate:
canary_stage: shadow | 5% | 25% | target
decision: promote | hold | rollback
Enter fullscreen mode Exit fullscreen mode

FAQ

Is deepseek-v4-pro a new API name?

No. The calling name is unchanged, but it now points to DeepSeek-V4-Pro-0813. Treat it as a moving alias and retain snapshot evidence.

When does peak/off-peak billing start in Beijing?

At 00:00 on August 17, 2026. Peak windows are 09:00–12:00 and 14:00–18:00 Beijing time; all other hours are off-peak.

Can Codex use DeepSeek V4 Pro directly?

DeepSeek now natively supports the Responses API and provides an official Codex configuration path. Verify the shared CLI/desktop/IDE configuration, model catalog, tools, permissions, and rollback before relying on it.

Sources

Top comments (0)