DeepSeek V4 Migration Checklist: Replace Deprecated Aliases Safely

DeepSeek V4 migration is no longer a generic "upgrade to V4" task. As of September 16, 2026, the migration risk is specific: DeepSeek says the legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted for compatibility, but those retired model names are served by DeepSeek-V4.1-Flash and billed at the Flash price. DeepSeek also says API service for deepseek-v4-pro continues after September 14, 2026, with the existing billing method unless DeepSeek gives further notice.

That means the safe path is not to chase every historical alias. The safe path is to standardize new work on deepseek-flash, document where deepseek-v4-pro is still intentionally used, and verify the exact route your product calls. If you route through Flatkey, the same principle applies: keep the OpenAI-compatible client pointed at https://router.flatkey.ai/v1, choose the current DeepSeek row from the live catalog, run a smoke test, and confirm usage logs before production traffic moves.

This DeepSeek V4 Migration Checklist: Replace Deprecated Aliases Safely guide gives indie hackers and small AI product teams a practical rollout: audit deprecated aliases, update model IDs, test thinking mode, validate Responses API and tool-call behavior, check pricing units, and keep rollback simple.

Quick Answer: What Should Change?

Use deepseek-flash as the current Flash model name. Treat deepseek-v4-flash and deepseek-v4-flash-vision-exp as compatibility aliases that should be removed from new code, routing policies, docs, and eval sheets. Keep deepseek-v4-pro only where you have a reason to test and monitor the Pro route directly.

String Found In Your Stack	Current Official Context	Recommended Action	Migration Risk To Test
deepseek-v4-flash	Legacy name; requests are served by DeepSeek-V4.1-Flash for compatibility.	Replace with deepseek-flash after a route smoke test.	Model-not-found errors in routers, dashboards, allowlists, or stale docs.
deepseek-v4-flash-vision-exp	Legacy name; requests are served by DeepSeek-V4.1-Flash for compatibility.	Replace with deepseek-flash, then test image-input paths explicitly.	Vision payload handling, tool output images, and parser expectations.
deepseek-flash	Current Flash model name in DeepSeek docs.	Use as the default target for Flash workloads after live route verification.	Thinking defaults, pricing window, output length, streaming, and tool calls.
deepseek-v4-pro	DeepSeek says API service continues after September 14, 2026 with the billing method unchanged unless further notice is given.	Keep only when the workload intentionally uses Pro and monitoring is current.	Provider lifecycle changes, higher cost profile, route policy drift, and fallback behavior.

The practical DeepSeek V4 migration rule is simple: aliases belong in an audit report, not in new production configuration.

Why This Migration Is Different From The June Checklist

The original version of this article focused on a July 2026 retirement of deepseek-chat and deepseek-reasoner. That is no longer the safest frame for this page. The current official DeepSeek docs emphasize the V4.1 Flash release, the deepseek-flash model name, the retired Flash and Flash Vision aliases, and the continued API service note for deepseek-v4-pro.

For a small team, this changes the migration plan. You do not need a frantic rewrite of every DeepSeek-related mention. You need a controlled alias cleanup with dated evidence:

• Which model strings still exist in code, environment variables, eval jobs, and docs?
• Which strings are compatibility aliases and which strings are current model IDs?
• Which routes are direct DeepSeek routes and which routes go through Flatkey or another gateway?
• Which workloads depend on vision, thinking, Responses API, tool calls, structured output, long context, or streaming?
• Which dashboards prove that the new model ID is actually handling traffic?

That is the difference between an alias replacement and a reliable DeepSeek V4 migration.

Source Facts To Lock Before You Edit Code

Before changing model strings, save a short migration note with the source date and the exact pages you checked. For this refresh, the source facts are:

Fact To Verify	What The Current Sources Say	How To Use It
Current Flash name	DeepSeek docs say to use deepseek-flash as the model name.	Make deepseek-flash the target model string for Flash routes.
Legacy Flash aliases	deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but their corresponding models are retired and served by V4.1 Flash.	Replace those aliases in new code and plan cleanup in existing configs.
Pro lifecycle	DeepSeek says deepseek-v4-pro API service continues after September 14, 2026 with the billing method unchanged, pending further notice.	Do not claim Pro is shut off; monitor it as an intentional route.
Direct DeepSeek base URL	DeepSeek documents https://api.deepseek.com for OpenAI-format calls and https://api.deepseek.com/anthropic for Anthropic-format calls.	Keep base URL changes separate from model-name changes.
Flatkey base URL	Flatkey docs show the OpenAI SDK pointed at https://router.flatkey.ai/v1.	Use one configurable base URL and one model field when testing Flatkey routes.

Do not paste pricing numbers into application docs without a timestamp. DeepSeek's current pricing page lists prices per 1M tokens, separates cache-hit input, cache-miss input, and output tokens, and notes peak/off-peak windows. That is enough reason to check live pricing at rollout time instead of relying on a static estimate inside the migration script.

Direct DeepSeek Versus Flatkey Routing

A DeepSeek V4 migration can be direct, routed through Flatkey, or both during testing.

Path	Use It When	What Must Be Verified
Direct DeepSeek API	You want provider-direct access and direct DeepSeek account controls.	Base URL, API key, deepseek-flash, deepseek-v4-pro, thinking mode, Responses API, image input, tool calls, pricing units, and 429 handling.
Flatkey gateway route	You want one key, one OpenAI-compatible base URL, one model catalog, and shared usage review across providers.	Current Flatkey model row, route health, endpoint family, request logs, token and cost fields, fallback policy, quota, and rollback model.
Dual-route validation	You need confidence before moving production traffic or changing customer-facing workflows.	Same prompt set, same parser, same streaming mode, same tool-call test, same accepted-output metric, and same date-stamped source checklist.

Flatkey is useful when the operational problem is bigger than one DeepSeek route: scattered provider keys, repeated SDK edits, unclear request-level cost, and hard-to-audit fallback decisions. But a gateway does not remove the need to prove the model ID. Always test the exact model row your account will call.

DeepSeek V4 Migration Checklist

Use this checklist before replacing aliases in production.

1. Freeze the source date. Record the date you checked DeepSeek docs, Flatkey docs, Flatkey model directory, pricing, and route status. For this article refresh, that date is September 16, 2026.
2. Search the whole stack. Look for deepseek-v4-flash, deepseek-v4-flash-vision-exp, deepseek-flash, deepseek-v4-pro, and older docs that tell developers to copy a stale value.
3. Classify each match. Separate production code, staging configs, eval jobs, prompt-router policies, customer docs, support macros, notebooks, CI fixtures, and examples.
4. Replace deprecated Flash aliases. Move deepseek-v4-flash and deepseek-v4-flash-vision-exp to deepseek-flash only after you have a test route and rollback plan.
5. Keep Pro explicit. Do not silently move deepseek-v4-pro workloads to Flash. If Pro remains in use, mark the owner, reason, date checked, and fallback model.
6. Make thinking mode explicit. DeepSeek docs say thinking mode is enabled by default with default effort high. If you need non-thinking behavior, configure and test that deliberately.
7. Test image input if you used the vision alias. For workloads that used deepseek-v4-flash-vision-exp, run image-input tests through the route you will actually ship.
8. Test Responses API separately. DeepSeek's Responses API compatibility includes supported, partially supported, ignored, and unsupported fields. Do not infer behavior from Chat Completions alone.
9. Run tool-call and structured-output tests. Validate tool schemas, function arguments, JSON parsing, retries, and multi-turn behavior.
10. Check streaming and usage. Confirm chunk shape, timeout handling, final usage, token counts, and billing fields in direct provider logs or Flatkey Usage Logs.
11. Update docs and examples. Remove stale snippets that would reintroduce deprecated aliases during the next onboarding or bug fix.
12. Roll out behind configuration. Put the target model in an environment variable or routing table. Avoid hard-coded literals inside business logic.
13. Watch the first production slice. Start with low-risk traffic, compare accepted-output rate and cost per accepted response, then ramp only after logs are clean.

Copyable Alias Audit Template

Use this template as a short migration record. Keep it in your repo, issue tracker, or runbook so future fixes know why the alias changed.

deepseek_v4_migration:
  checked_at_utc: "2026-09-16T00:00:00Z"
  source_pages:
    - "https://api-docs.deepseek.com/"
    - "https://api-docs.deepseek.com/quick_start/pricing"
    - "https://api-docs.deepseek.com/news/news260910"
    - "https://api-docs.deepseek.com/guides/thinking_mode"
    - "https://api-docs.deepseek.com/guides/responses_api"
    - "https://docs.flatkey.ai/quickstart.md"
    - "https://docs.flatkey.ai/guides/openai-sdk.md"
  replacements:
    - from: "deepseek-v4-flash"
      to: "deepseek-flash"
      reason: "legacy Flash alias; route served by V4.1 Flash for compatibility"
      owner: "engineering"
      status: "test_before_merge"
    - from: "deepseek-v4-flash-vision-exp"
      to: "deepseek-flash"
      reason: "legacy vision experiment alias; verify image-input behavior"
      owner: "engineering"
      status: "test_before_merge"
  intentionally_kept:
    - model: "deepseek-v4-pro"
      reason: "Pro route still intentionally evaluated"
      next_review_date: "2026-09-30"
  required_tests:
    - plain_chat
    - thinking_enabled
    - thinking_disabled_if_used
    - responses_api
    - image_input_if_used
    - tool_calls
    - json_output
    - streaming
    - usage_log_readback
    - rollback

Flatkey Configuration Pattern

The safest Flatkey setup keeps provider-specific model selection in configuration while the OpenAI-compatible client surface stays stable.

FLATKEY_API_KEY="sk-your-flatkey-key"
OPENAI_BASE_URL="https://router.flatkey.ai/v1"
FLATKEY_DEEPSEEK_MODEL="deepseek-flash"

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-flash"),
    messages=[
        {
            "role": "user",
            "content": "Return one sentence confirming the DeepSeek route is alive.",
        }
    ],
    stream=False,
)

print(response.choices[0].message.content)
print(response.usage)

After the request, open Flatkey Usage Logs and verify model name, token counts, latency, cost, key, timestamp, and error state. If the log does not match the request you sent, the migration is not done.

Testing Matrix Before Cutover

Test	Why It Matters	Pass Signal
Plain chat	Confirms auth, base URL, model ID, and basic parser compatibility.	Request returns expected content and logs the target model.
Thinking mode	DeepSeek thinking behavior can change output shape and token usage.	Your app intentionally handles or disables reasoning output.
Responses API	Some parameters are partially supported, ignored, or not supported.	Your client does not rely on ignored fields for correctness.
Vision input	The old vision alias implies image-input use cases that need a real test.	Image inputs are processed through the actual route you will ship.
Tool calls	Agents fail when tool arguments, IDs, or multi-turn messages drift.	Tool call generation and tool result continuation both pass.
Structured output	A normal answer can still break a JSON validator.	Validator pass rate stays within your launch threshold.
Streaming	Streaming errors often appear only after the first chunk.	Chunks, final message, timeout handling, and usage accounting pass.
Cost and quota	Cache-hit, cache-miss, output, peak/off-peak, retry, and fallback behavior affect real cost.	Finance and engineering can explain cost per accepted response.
Rollback	Alias migrations should be reversible without a rushed deploy.	Traffic can move back to a known route through configuration.

Common Mistakes

• Treating DeepSeek V4 migration as a blind text replacement without checking the current DeepSeek docs.
• Replacing deepseek-v4-flash-vision-exp with deepseek-flash but never testing image input.
• Assuming deepseek-v4-pro was shut off after September 14, 2026 when current docs say service continues.
• Updating app code but leaving stale aliases in eval jobs, notebooks, customer snippets, or fallback policies.
• Comparing only headline token prices instead of cost per accepted response.
• Assuming direct DeepSeek behavior and Flatkey-routed behavior are identical without checking the live route and logs.
• Letting unsupported Responses API parameters silently change product behavior.

Internal Links For The Next Step

If you are still choosing DeepSeek routes, pair this checklist with DeepSeek V4 Pro vs Flash and DeepSeek vs Qwen API routing checks. If the bigger project is gateway standardization, read the Flatkey API quickstart, the AI model catalog guide, and AI routing API metrics. For region-sensitive provider decisions, use regional LLM provider routing.

FAQ

What is the current DeepSeek Flash model name?

The current Flash model name in DeepSeek docs is deepseek-flash. A safe DeepSeek V4 migration should move deprecated Flash aliases toward that model string after route testing.

Are deepseek-v4-flash and deepseek-v4-flash-vision-exp broken?

DeepSeek says those legacy names are still accepted, but their corresponding models have been retired and requests are served by DeepSeek-V4.1-Flash. That compatibility is useful during migration, but new code should avoid relying on retired aliases.

Did deepseek-v4-pro stop working after September 14, 2026?

No. Current DeepSeek docs say API service for deepseek-v4-pro continues after September 14, 2026, with the billing method unchanged unless DeepSeek provides further notice. Keep it explicit and monitored if you use it.

Do I need to change the DeepSeek base URL?

Not for a direct OpenAI-format DeepSeek call. DeepSeek documents https://api.deepseek.com as the OpenAI-format base URL. For Flatkey, use https://router.flatkey.ai/v1 with a Flatkey API key.

Does Flatkey replace provider-specific route testing?

No. Flatkey can centralize the key, base URL, catalog, and usage review, but your team still needs to verify the exact model row, feature behavior, cost fields, route health, and fallback plan.

Should every workload move to deepseek-flash?

No. deepseek-flash is the current Flash target, but workloads that intentionally use deepseek-v4-pro should be tested and tracked separately. Choose by workload, not by a global replacement rule.

Final Rollout Advice

DeepSeek V4 Migration Checklist: Replace Deprecated Aliases Safely should end with evidence, not only a merged diff. Replace retired Flash aliases, keep Pro routes intentional, test the features your product actually uses, and verify the request in logs. Then check the current Flatkey model directory and Flatkey pricing page before you move production traffic.

After migrating, check current rates in DeepSeek V4 Flash pricing (October 2026), which also explains the move to V4.1 Flash.