DeepSeek V4 migration is now a deadline-driven cleanup task, not just a model upgrade. DeepSeek's official API docs say the older deepseek-chat and deepseek-reasoner aliases will be fully retired and inaccessible after July 24, 2026 at 15:59 UTC. The supported V4 model IDs are deepseek-v4-flash and deepseek-v4-pro.
The good news is that this should be a controlled configuration change for many teams. DeepSeek says to keep the same direct base_url and update the model name. If you route models through Flatkey, use the same idea: keep your app pointed at https://router.flatkey.ai/v1, replace the alias with a current Flatkey DeepSeek V4 model row, and verify response behavior, thinking mode, usage logs, pricing, and rollback before production traffic moves.
This DeepSeek V4 migration checklist gives you the concrete steps: map old aliases, choose deepseek-v4-flash or deepseek-v4-pro, test thinking and non-thinking behavior, update SDK configuration, and avoid an unreviewed model switch near the cutoff date.
Quick Answer: What Changes In A DeepSeek V4 Migration?
The urgent change is the model string. Do not leave production code, environment variables, prompt routers, eval jobs, or fallback policies hard-coded to deepseek-chat or deepseek-reasoner.
| Old Alias | Current Official Behavior | Migration Target To Test | Risk To Verify |
|---|---|---|---|
deepseek-chat |
Currently routes to deepseek-v4-flash non-thinking mode |
deepseek-v4-flash with thinking disabled, unless you intentionally choose another V4 mode |
Output style, latency, cost, parser compatibility, and any ignored parameters |
deepseek-reasoner |
Currently routes to deepseek-v4-flash thinking mode |
deepseek-v4-flash or deepseek-v4-pro with thinking explicitly tested |
reasoning_content, token usage, multi-turn handling, and SDK support |
| Claude-style model names in DeepSeek Anthropic API | DeepSeek maps Claude Opus names to V4 Pro and Claude Haiku/Sonnet names to V4 Flash | Prefer explicit DeepSeek V4 model IDs where your routing layer allows it | Unsupported Anthropic fields, image/document content support, and tool-call behavior |
For a direct DeepSeek call, the official OpenAI-format base URL remains https://api.deepseek.com. For Flatkey, the router base URL remains https://router.flatkey.ai/v1. In either path, the DeepSeek V4 migration should be tested as a model and behavior change, not only as a search-and-replace.
Why The Alias Deadline Matters
DeepSeek's V4 preview page says the API is available now, both deepseek-v4-pro and deepseek-v4-flash support 1M context and both thinking and non-thinking modes, and the older aliases will be retired after July 24, 2026 at 15:59 UTC. That means a stale alias can move from "works today" to "hard failure" after the retirement window.
The homepage quick-start table also lists deepseek-chat and deepseek-reasoner as aliases that will be deprecated on 2026/07/24. It notes that, for compatibility, those aliases correspond to the non-thinking and thinking modes of deepseek-v4-flash.
That compatibility detail is useful, but it is not a reason to wait. A clean DeepSeek V4 migration gives you time to compare outputs, update runbooks, train support teams, and make sure production dashboards show the new model IDs before the deadline.
Direct DeepSeek Versus Flatkey Routing
There are two common migration paths.
| Decision | Direct DeepSeek API | DeepSeek Through Flatkey |
|---|---|---|
| Base URL | https://api.deepseek.com |
https://router.flatkey.ai/v1 |
| API key | DeepSeek API key | Flatkey API key |
| Model selection | Official DeepSeek model ID | Current Flatkey DeepSeek model row |
| Primary benefit | Provider-direct setup | One key, one router, shared usage logs, quotas, and billing visibility across providers |
| Production check | DeepSeek response, thinking mode, pricing, and errors | Response, route status, selected model row, usage log, pricing unit, quota, and rollback |
Flatkey's public product copy positions the platform around one API key, an OpenAI-compatible base URL, clear pricing, unified billing, and one dashboard for keys, usage, and routing. For teams already moving GPT, Claude, Gemini, Qwen, MiniMax, and DeepSeek traffic through one gateway, a DeepSeek V4 migration is a good moment to standardize model IDs and logging across the stack.
Flatkey Catalog Check For DeepSeek V4
For this article, I checked Flatkey's public pricing API on June 16, 2026. The snapshot returned 638 total model rows and 19 DeepSeek-named rows. It listed both deepseek-v4-pro and deepseek-v4-flash in the Standard group with openai endpoint support.
Treat that as dated catalog proof, not as a promise that your account and route are ready. In the same snapshot, both V4 rows had unknown_failure availability status, meaning availability should be confirmed in the current Flatkey pricing view or dashboard before real traffic depends on the route. A careful DeepSeek V4 migration should include a live smoke test and usage-log check on the day you switch.
DeepSeek V4 Migration Checklist
Use this checklist before you replace aliases in production.
- Inventory every alias. Search application code, environment variables, prompt-router rules, eval configs, background jobs, notebooks, docs, and support runbooks for
deepseek-chatanddeepseek-reasoner. - Classify each workload. Mark each route as chat, reasoning, agent tool use, structured output, long context, batch eval, or fallback-only. Do not assume every route should move to the same V4 mode.
- Choose the target model. Start with
deepseek-v4-flashwhen you want the closest replacement for the current aliases. Evaluatedeepseek-v4-prowhen the workload needs stronger capability and you can accept the cost and latency profile after testing. - Make thinking explicit. For old
deepseek-chatbehavior, test non-thinking mode. For olddeepseek-reasonerbehavior, test thinking mode and confirm how your SDK handlesreasoning_content. - Keep model IDs in configuration. Put the target model in an environment variable or routing table, not inline in application logic.
- Run paired output tests. Compare old alias responses with new V4 responses on representative prompts, parsers, JSON-mode tasks, tool calls, and refusal/error cases.
- Verify streaming and usage accounting. Check whether final usage appears where your billing or observability code expects it, especially for streaming responses.
- Check cost and quotas. Confirm provider pricing or Flatkey pricing, then set a low quota or test budget before production traffic ramps.
- Log the new model ID. Make sure traces, alerts, and billing exports show
deepseek-v4-flashordeepseek-v4-pro, not only a generic provider label. - Prepare rollback. Keep a prior provider or fallback model configured until the V4 route has passed real workload tests.
- Remove stale docs. Update internal setup guides so new developers do not copy deprecated aliases back into production.
Configuration Template For Flatkey
Template only: run this with a valid Flatkey key and a confirmed Flatkey DeepSeek V4 model ID from the current catalog. The shape is ordinary OpenAI SDK usage, but the route, model status, thinking behavior, and usage log still need to be tested.
FLATKEY_API_KEY="sk-fk-your-key"
OPENAI_BASE_URL="https://router.flatkey.ai/v1"
FLATKEY_DEEPSEEK_MODEL="deepseek-v4-flash"
# Keep the target easy to change during rollout.
# For direct DeepSeek comparison:
DEEPSEEK_BASE_URL="https://api.deepseek.com"import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["FLATKEY_API_KEY"],
base_url=os.environ.get("OPENAI_BASE_URL", "https://router.flatkey.ai/v1"),
)
response = client.chat.completions.create(
model=os.environ.get("FLATKEY_DEEPSEEK_MODEL", "deepseek-v4-flash"),
messages=[
{
"role": "user",
"content": "Reply with one sentence confirming the DeepSeek V4 route is configured.",
}
],
)
print(response.choices[0].message.content)
print(response.usage)For direct DeepSeek testing, follow DeepSeek's official OpenAI SDK examples for thinking mode. The thinking guide says the thinking toggle defaults to enabled, the OpenAI-format effort parameter supports high and max, and lower effort labels map upward for compatibility. If your app depends on non-thinking responses, make that choice explicit and test it instead of relying on an alias.
Testing Matrix Before Cutover
A DeepSeek V4 migration should be accepted only after you test the behavior your product actually uses.
| Test | What To Check | Pass Signal |
|---|---|---|
| Basic chat | Simple prompt, response shape, parser behavior | App receives expected content without schema or role errors |
| Thinking mode | thinking, reasoning_effort, and reasoning_content |
Reasoning output is handled or intentionally suppressed according to your product policy |
| Streaming | Chunk format, final usage, timeout behavior | Client parser and billing hooks still work |
| Tool calls | Tool schema, arguments, multi-step agent turns | Tool calls are generated and consumed without malformed JSON or missing IDs |
| Structured output | JSON-mode prompts and validation | Validator pass rate stays within your launch threshold |
| Long context | Large prompts, truncation, cache assumptions | Context handling is predictable and cost is acceptable |
| Flatkey observability | Route status, model ID, token usage, cost, and error logs | Dashboard entries match the request you sent |
| Rollback | Previous provider or fallback model | Traffic can move back by configuration without a deploy |
Common Mistakes
- Treating DeepSeek V4 migration as a global search-and-replace without output evaluation.
- Replacing
deepseek-reasonerbut forgetting to testreasoning_contentin multi-turn conversations. - Leaving aliases in eval jobs, support examples, or fallback rules while production code uses V4 IDs.
- Assuming direct DeepSeek and routed Flatkey behavior are identical without checking route status and usage logs.
- Copying a model ID from an old article instead of the current Flatkey pricing page or dashboard.
- Skipping cost checks because the first smoke test returns a normal answer.
- Waiting until July 24, 2026, then discovering that a scheduled job or background worker still uses an inaccessible alias.
How This Fits With Other Flatkey Migration Guides
If you have not centralized provider configuration yet, start with the broader OpenAI-compatible API migration guide. It covers base URL changes, smoke tests, and rollback patterns that apply beyond DeepSeek.
If you are still deciding whether to route DeepSeek directly or through one gateway, compare this page with the existing DeepSeek API access guide. For budgeting and model-row checks, use the AI model pricing comparison workflow and the current Flatkey pricing page.
FAQ
When are deepseek-chat and deepseek-reasoner deprecated?
DeepSeek's official docs list July 24, 2026 at 15:59 UTC as the retirement time after which deepseek-chat and deepseek-reasoner will be inaccessible. Plan your DeepSeek V4 migration before that date.
What should replace deepseek-chat?
For the closest behavior, test deepseek-v4-flash with non-thinking behavior. DeepSeek says deepseek-chat currently routes to deepseek-v4-flash non-thinking mode.
What should replace deepseek-reasoner?
Test deepseek-v4-flash or deepseek-v4-pro with thinking enabled, depending on your quality, cost, and latency needs. DeepSeek says deepseek-reasoner currently routes to deepseek-v4-flash thinking mode.
Do I need to change the DeepSeek base URL?
For direct DeepSeek OpenAI-format calls, the official base URL remains https://api.deepseek.com. For Flatkey calls, use https://router.flatkey.ai/v1 and a Flatkey API key.
Does Flatkey support DeepSeek V4?
The June 16, 2026 Flatkey pricing API snapshot listed deepseek-v4-pro and deepseek-v4-flash with openai endpoint support. The same snapshot showed unknown_failure availability status for those rows, so verify the current pricing page, dashboard route status, and a live smoke test before production traffic.
Should I choose deepseek-v4-flash or deepseek-v4-pro?
Use deepseek-v4-flash as the first replacement candidate for old alias compatibility. Test deepseek-v4-pro when the workload needs stronger reasoning or agent capability and your latency and cost checks pass.
View Pricing Before You Switch Production Traffic
DeepSeek V4 migration is the right time to remove deprecated aliases, make thinking behavior explicit, and put model selection behind configuration. Before rollout, confirm the current Flatkey model row, route status, usage logs, and pricing for deepseek-v4-flash or deepseek-v4-pro.
View Pricing to check the current Flatkey DeepSeek V4 rows before you move production traffic.
