DeepSeek V4 Pro to V4.1 Flash: Checks Before September 14
Understand the planned Pro rerouting, check your existing clients and bills, and prepare a fallback independent of the old Pro alias.
Contents
DeepSeek plans to retire V4 Pro on September 14, 2026, at 12:00 Beijing time: 04:00 UTC, or 07:00 Moscow time. A notice in the official platform, accessible after sign-in, says V4 Pro requests will be routed to V4.1 Flash and billed at V4.1 Flash rates.
For the official API, the plan redirects existing requests. The announcement alone does not require urgently replacing deepseek-v4-pro in every configuration. However, a different model will answer behind the old name. Test your workload before the switch and prepare a fallback that does not depend on that name.
A separate platform notice schedules Flash price changes for September 10 at 12:00 Beijing time. That is a different event. The Pro retirement notice checked on September 10 specifies September 14. This guide prepares for the planned change; it does not claim migration has already happened.
Identify the provider receiving your requests
| Connection | What to check |
|---|---|
| Direct DeepSeek API | Your account notice, Pro switch date, and current replacement rates |
| Third-party API provider, including BetterToken | Its own catalog, Model ID, schedule, routing, and price; DeepSeek’s announcement does not establish a reseller’s terms |
| Coding agent with a selected provider | Actual Base URL and submitted Model ID, separately for the main agent and auxiliary tasks |
A client menu label does not reveal the whole route. Main conversations, subtasks, and fallbacks may use separate model settings. Check project settings as well as global settings.
Make a short inventory: application, provider, protocol, current Model ID, configuration location, and person responsible for verification. Do not copy API Keys into it.
For a local project with ripgrep installed, this command lists only filenames directly mentioning Pro:
rg -l --hidden -g '!.git' -g '!node_modules' -g '!.venv' \
'deepseek-v4-pro' .Run it from the project directory. No matches do not prove the absence of dependencies: also check CI variables, hosted-service settings, and client aliases. The command neither changes configuration nor tests the API.
Do you need a new Model ID?
The official Pro notice provides for rerouting. Do not guess the replacement name or treat removing a temporary ID’s suffix as migration. To select V4.1 Flash explicitly, copy an available ID from your actual provider’s current catalog and test it in a separate client profile first.
The temporary deepseek-v4.1-flash-expires-on-0910 is a different entry. Its expiry is not the Pro retirement date, and an old trial profile is not automatically a permanent replacement.
Check implicit names too. The current DeepSeek Anthropic API guide maps claude-opus prefixes to Pro, and claude-haiku or claude-sonnet to Flash. Unsupported names are documented as falling back to deepseek-v4-flash. A successful reply after a typo does not prove the intended model was selected. These are official DeepSeek adapter rules; other providers may differ.
After switching, compare the submitted ID, provider record, and its declared model mapping. Neither a model’s self-description nor a single model response field independently proves which weights served the request.
Keep the protocol and test complete tasks
DeepSeek’s official Anthropic-compatible Base URL is https://api.deepseek.com/anthropic. Do not put it into a Chat Completions client merely because the model changes. Third parties have their own addresses and authentication rules.
Keep the working protocol initially. Copy settings into a separate test profile, change only to a confirmed available model, and make a short request. If the new model is not yet listed, prepare tests and a fallback in advance; do not claim compatibility is verified.
HTTP 200 and a text reply establish only that request’s success. A working agent needs checks on its existing tasks:
| Scenario | Observable acceptance signal |
|---|---|
| Bug fix | The original test fails before the change and passes afterward, without breaking related checks |
| Tool call | Correct name and arguments, proper tool-result handling, and a completed response after the result is returned |
| Streaming | The client receives and terminates the stream and handles the final result and usage without parser errors |
| Long conversation | Task constraints and necessary earlier facts remain intact |
| Rate limit or temporary error | Bounded retries and total time; retrying does not create an extra external action |
Use test data or disable actual sending when checking email, CRM, or other external operations. Correctly generated arguments do not establish that repeating an operation is safe.
Check reasoning controls for your protocol. For example, DeepSeek’s official Anthropic adapter ignores thinking.budget_tokens and supports only effort within output_config. A field remaining in a config file does not prove the old budget applies. See the Thinking Mode mapping.
These are acceptance checks for your environment, not a claim that V4.1 Flash has passed them in every client. For a fuller dependency inventory and cutover checks, see the AI API migration audit.
Check billing separately from quality
The notice assigns V4.1 Flash billing to redirected Pro requests. It neither fixes third-party prices nor promises identical token usage for the same task.
Record the test time, provider, submitted ID, input and output tokens, available cache details, and final charge. Match these against that provider’s rate at that time. If rates distinguish peak and off-peak periods, use the correct window. Recheck official API prices after changes rather than inserting an old Pro rate.
For BetterToken calls, check these usage fields in the Dashboard and model availability and rates in the BetterToken catalog. This verifies your connection; it does not establish that BetterToken changes routing simultaneously with the official API.
Include failed attempts when comparing expense per accepted task. Lower token prices can coincide with more requests or longer answers.
Your fallback must survive Pro retirement
Returning to deepseek-v4-pro after the announced rerouting will not restore Pro-0813. If the primary and backup profiles use the same official API name, both may reach V4.1 Flash.
Choose another available Model ID or service, confirm its actual model, and test a critical task beforehand. If the fallback fails acceptance, keep the affected process under manual control or pause it; an unverified replacement is not a ready rollback.
Before cutover, the application owner should have test results, a verified fallback, and stop conditions such as incorrect tool calls, broken streaming, or expense above their own limit. After the announced time, run another small control task and check routing against the provider’s current notice before increasing load.
