Migrating Off deepseek-chat and deepseek-reasoner Before July 24, 2026

On July 24, 2026 at 15:59 UTC, DeepSeek permanently retires the legacy model aliases deepseek-chat and deepseek-reasoner. After the cutoff, every API request that sends either name in the model field will return an error. There is no grace period and no rollback — this is a hard shutdown. The fix is a one-line model name swap, but the real work is auditing every place those names hide in your stack. This guide gives you the replacement mapping, before/after code diffs, a production audit checklist, and TheRouter routing configuration updates.

Source: DeepSeek V4 Preview Release announcement (retrieved 2026-07-17) and DeepSeek Models & Pricing (retrieved 2026-07-17).

What Is Changing and Why

When DeepSeek launched the V4 model family in April 2026, they introduced two new model IDs: deepseek-v4-flash and deepseek-v4-pro. During the transition window (April–July 2026), the old names were silently routed:

Both legacy aliases resolve to the same underlying model (deepseek-v4-flash), just with different thinking-mode defaults. After the cutoff, you must use the explicit V4 model IDs.

1. Swap three values, not three SDKs. Change api_key, base_url, and model in the existing OpenAI client. Keep your request/response code unchanged.
2. Map model IDs explicitly. The target provider's model id is almost never identical to the OpenAI id. Keep a single dict of { openai_id: target_id } outside business logic.
3. Verify streaming format. SSE chunks must follow the OpenAI data: {...} + data: [DONE] contract. Test one streaming call before moving production traffic.
4. Check rate-limit headers. Some providers omit x-ratelimit-* headers. Add a wrapper that defaults safely when headers are absent.
5. Keep a rollback path. Ship the swap behind a feature flag, run both endpoints in shadow for 24 hours, then cut over.

Replacement Mapping

Here is the exact mapping from old names to new:

deepseek-chat → deepseek-v4-flash (non-thinking)

If you were using deepseek-chat for general conversation, code generation, or non-reasoning tasks, switch to deepseek-v4-flash with thinking disabled:

# Before (breaks after July 24)
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "Explain TCP/IP in one paragraph."}]
)

# After
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Explain TCP/IP in one paragraph."}],
    extra_body={"thinking": {"type": "disabled"}}
)

Why the thinking parameter? DeepSeek V4 models default to thinking mode enabled. If you were using deepseek-chat for fast, non-reasoning responses, you need to explicitly disable thinking to preserve the same behavior and cost profile.

deepseek-reasoner → deepseek-v4-flash (thinking)

If you were using deepseek-reasoner for chain-of-thought reasoning tasks, the migration is even simpler — deepseek-v4-flash defaults to thinking mode:

# Before (breaks after July 24)
response = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=[{"role": "user", "content": "Prove that √2 is irrational."}]
)

# After
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Prove that √2 is irrational."}]
)

Since thinking mode is the default for deepseek-v4-flash, the only change is the model name. The reasoning_content field in the response works identically.

Choosing deepseek-v4-pro Instead

If you want stronger reasoning capabilities and are willing to pay more, consider deepseek-v4-pro instead of deepseek-v4-flash. Both support thinking and non-thinking modes, 1M context, tool calls, and JSON output.

Source: DeepSeek Models & Pricing (retrieved 2026-07-17).

Production Audit Checklist

The model name swap is trivial. Finding every instance of deepseek-chat and deepseek-reasoner in a production stack is not. Run through this checklist:

1. Application code

# Search your codebase
grep -rn "deepseek-chat\|deepseek-reasoner" --include="*.py" --include="*.ts" --include="*.js" --include="*.go" --include="*.rs" --include="*.java" .

Check for string literals, constants, config objects, and enum values.

2. Environment variables

# Common patterns
env | grep -i "deepseek\|MODEL"
# Check .env, .env.local, .env.production files
grep -rn "deepseek-chat\|deepseek-reasoner" .env* 2>/dev/null

3. Configuration files

Search YAML, JSON, TOML, and INI configs:

find . -name "*.yaml" -o -name "*.yml" -o -name "*.json" -o -name "*.toml" -o -name "*.ini" | \
  xargs grep -l "deepseek-chat\|deepseek-reasoner" 2>/dev/null

4. Infrastructure as Code

Terraform variables, Kubernetes ConfigMaps, Docker Compose environment sections, and CI/CD pipeline variables (GitHub Actions secrets, GitLab CI variables) all need checking.

5. SDK default overrides

Some wrappers (LangChain, LlamaIndex, AutoGen) accept model names in constructor kwargs or config files. Search for model= and model_name= patterns.

6. Database and key-value stores

If you store model preferences per-user or per-tenant in a database, run a query:

SELECT DISTINCT model_name FROM api_configs
WHERE model_name IN ('deepseek-chat', 'deepseek-reasoner');

7. Third-party integrations

If you route DeepSeek through a gateway, proxy, or routing layer (like TheRouter), update the model mapping in your routing configuration.

Thinking Mode: What Changes

DeepSeek V4 unifies thinking and non-thinking under a single model ID with an explicit toggle. This is a behavioral change from the old split:

The thinking toggle uses the extra_body parameter in the OpenAI SDK:

# Explicit non-thinking (equivalent to old deepseek-chat behavior)
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
    extra_body={"thinking": {"type": "disabled"}}
)

# Explicit thinking with effort control
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages,
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}}
)

Effort levels: In thinking mode, reasoning_effort accepts high (default) or max. For compatibility, low and medium are silently mapped to high.

Source: DeepSeek Thinking Mode docs (retrieved 2026-07-17).

Response Format Differences

If your code parses the response, note these changes when migrating from deepseek-reasoner:

1. reasoning_content field — Still returned at the same level as content in thinking mode. No change needed for parsing.
2. Tool calls with thinking — When using tool calls in thinking mode, reasoning_content from intermediate steps must be passed back in subsequent API calls. This was also true with deepseek-reasoner, but if you are newly enabling thinking mode on what was a deepseek-chat workflow, your tool call loop needs updating.
3. Multi-turn context — In non-tool-call turns, reasoning_content from previous turns is ignored by the API if passed. In tool-call turns, it is required.

Cost Impact

If you were using deepseek-chat (non-thinking), switching to deepseek-v4-flash with thinking disabled should produce the same cost profile — input and output token pricing is identical.

If you were using deepseek-reasoner (thinking), the V4-Flash thinking mode pricing is the same — reasoning tokens are billed as output tokens.

In practice, V4-Flash may be slightly cheaper per-task because the underlying model is more efficient than the pre-V4 generation. We have not observed price increases from this migration.

TheRouter Routing Configuration

If you route DeepSeek through TheRouter, update your model aliases in your routing rules. TheRouter already supports both deepseek-v4-flash and deepseek-v4-pro as first-class model targets.

For fallback configuration during the transition window, you can set up a model mapping that handles both old and new names:

// Example: route legacy names to V4 equivalents
const modelMapping = {
  "deepseek-chat": "deepseek-v4-flash",
  "deepseek-reasoner": "deepseek-v4-flash",
};

After July 24, requests using the legacy names will fail at the DeepSeek API level regardless of your routing configuration, so updating the source of truth (your application code or client SDK calls) is essential.

For more on DeepSeek integration, see our DeepSeek API Complete Guide.

Timeline and Action Items

FAQ

Q: Will deepseek-chat return a helpful error message or just fail silently? DeepSeek has not documented the specific error response. Expect a standard API error (likely 400 or 404) indicating an invalid model name.

Q: Can I use deepseek-v4-pro as a drop-in replacement instead of deepseek-v4-flash? Yes. Both support the same API surface (thinking mode, tool calls, JSON output, 1M context). The difference is capability and cost — V4-Pro is ~3× more expensive but stronger on reasoning benchmarks.

Q: What about deepseek-r1 and deepseek-v3 model names? These are separate model IDs for older model generations. They are not mentioned in the July 24 deprecation notice and remain available as of this writing. However, we recommend using the V4 family for new work.

Q: Does this affect DeepSeek models hosted on other platforms (DashScope, SiliconFlow, etc.)? No. This deprecation applies only to the DeepSeek direct API (api.deepseek.com). Third-party platforms use their own model naming conventions. Check each platform's docs separately.

---

Last updated: 2026-07-17. Sources: DeepSeek V4 Release Notes, DeepSeek Models & Pricing, DeepSeek Thinking Mode.