DeepSeek V4 Pro to V4.1 Flash: September 14 migration guide

DeepSeek will route all direct API requests to deepseek-v4-pro to V4.1 Flash from September 14, 2026, at 12:00 Beijing time (UTC+8). To test the replacement now, explicitly select deepseek-flash. The scheduled switch is 04:00 UTC and remains in place until V4.1 Pro is released, according to the official pricing documentation.

This guide was checked against documentation on September 10. We have not run paid inference tests or validated your application’s compatibility. The release overview covers the launch; this page focuses on what an existing Pro deployment needs to change.

Separate the three model-name cases

The September 10 change log distinguishes the new ID, already-retired Flash models and the scheduled Pro transition.

Leaving a Pro string unchanged does not pin the underlying model after that deadline. Nor does retaining a saved client configuration guarantee a rollback to V4 Pro once the upstream service has changed. The notice does not supply a V4.1 Pro release date.

Inventory the places that select a model

Search application configuration, environment variables, scheduled jobs and coding-agent settings for the old IDs. Record the endpoint alongside each name: a gateway may expose different IDs or maintain its own routing policy.

For the direct API, make an explicit deepseek-flash selection in a staging configuration. Keep the original configuration available for comparison before the transition. The API setup guide covers the current endpoint and request format.

Coding clients deserve a separate check. Update both model selection and provider metadata in Codex. In Claude Code, check the main model, default model aliases and subagent model, rather than changing only one field.

Run a regression test you can compare

Choose representative tasks with known acceptance criteria before changing production traffic. This is a proposed validation procedure, not an Ofox benchmark:

1. Save the prompt, tool definitions, relevant inputs, expected result and current Pro output.
2. Run the same task against deepseek-flash, keeping unrelated application settings unchanged.
3. Check structured output parsing, tool arguments, multi-step execution, streaming completion and the final result.
4. Record elapsed time, token usage, errors and billed cost for both runs.

Include a long conversation and a tool failure that the agent must recover from. A successful greeting proves much less than a completed repository task or a correctly parsed business result. DeepSeek attributes the transition to its own favorable testing; that claim does not establish a performance improvement for every workload.

Check the bill at the transition

DeepSeek says Pro requests will be billed at Flash prices after the switch. Before it, the official table still lists separate Pro rates. Use the V4.1 Flash pricing guide to distinguish cache-hit input, cache-miss input, output and peak/off-peak periods.

Compare the provider’s usage records with the request time and endpoint. An unchanged model label alone is insufficient to explain a new bill. Lower unit prices also do not guarantee the same percentage reduction in task cost if token usage changes.

For Ofox or another gateway, confirm the catalog entry, protocol, routing and account price separately. You can inspect the Ofox model catalog before choosing a provider; this guide does not confirm an Ofox V4.1 Flash route or promise that registration enables it.