DeepSeek V4 Is Now the Only Option: The Legacy API Cutoff and What Actually Changed

If you woke up to failed DeepSeek API calls yesterday, you’re not alone, and the fix is smaller than the panic. DeepSeek retired the deepseek-chat and deepseek-reasoner model names on July 24, 2026, at 15:59 UTC. Both names had already been silently pointing at V4-Flash for months during the grace period, so functionally you were already running on the new model. What changed is that the safety net, the old name quietly resolving to a new model, is gone. Use the old name now and you get an error, not a response.

We covered V4’s architecture back in February when it was a preview release with a lot of promise and an Apache 2.0 license attached. This is the part that matters five months later: what the general-availability build actually looks like in production, what broke for teams that didn’t update in time, and the pricing change that nobody scheduled around.

The one-line fix

For most integrations, this is genuinely a small change:

# Before (now returns an error)
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=messages
)

# After
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=messages
)

For anything that was calling deepseek-reasoner, the swap needs one more piece. Thinking mode used to be baked into the model name. Now it’s a request parameter that applies to both V4-Pro and V4-Flash:

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}}
)

The chain-of-thought output moves too. It now comes back in a reasoning_content field alongside content, rather than embedded in the response body the way deepseek-reasoner used to return it. If your parsing logic was pulling reasoning text out of the main content field with a regex or a string split, that logic needs to change even though the model swap itself is trivial. This is the part of the migration that actually breaks silently instead of loudly: your calls will succeed, but the reasoning trace you were displaying or logging will show up empty.

Why “reasoner equals thinking” stopped being a safe assumption

The bigger structural change is that thinking is no longer tied to a specific model. Both V4-Pro and V4-Flash can run with thinking on or off, which means the old mental shortcut, use the reasoner model when you want reasoning, doesn’t map cleanly anymore. You now make two separate decisions: which model size fits the task, and whether you want the latency and cost hit of thinking mode on top of it. It’s more flexible, but it’s also one more place a lazy migration (swap the model name, ignore the parameter) produces a model that runs but doesn’t reason the way your old deepseek-reasoner calls did.

The model split, and what it’s for

V4-Pro carries 1.6 trillion total parameters with 49 billion active per token, positioned for complex reasoning, coding, and multi-step agentic work. V4-Flash is smaller, 284 billion total parameters with 13 billion active, and is where you want to be for high-volume, latency-sensitive requests that don’t need the heaviest reasoning. Both ship with a 1-million-token context window, a real jump from the preview generation and enough to hold a large codebase or a long document set in a single call without chunking.

The practical rule of thumb: default to V4-Flash for anything user-facing where latency matters, and reach for V4-Pro with thinking enabled specifically when the task benefits from multi-step reasoning, not by default. Running V4-Pro with thinking on for every request is the single fastest way to turn a cheap API into an expensive one.

Peak-hour pricing is new, and it’s a real lever

Alongside the GA release, DeepSeek introduced time-of-day pricing for the first time in its API history. Rates roughly double during two daily windows, 01:00-04:00 UTC and 06:00-10:00 UTC, and return to standard rates outside those windows.

For latency-sensitive, user-facing traffic, this is mostly a cost you need to account for in your budget rather than something you can route around. But for anything with flexible timing, nightly batch jobs, bulk summarization, dataset labeling, offline evaluation runs, shifting the schedule outside those two windows is a straightforward way to cut the bill without touching a line of model logic. If your team is already thinking about reducing LLM API costs in production, time-of-day scheduling is now a lever worth adding to that list specifically for DeepSeek traffic.

What to actually do this week

Grep your codebase for deepseek-chat and deepseek-reasoner as literal strings, not just in obvious client initialization code. They tend to hide in config files, environment variable defaults, and fallback logic that only runs when a primary provider fails. Update the model names, add the explicit thinking parameter anywhere you relied on deepseek-reasoner’s implicit behavior, and check any code that parsed reasoning text out of the response body. Then look at your request volume by time of day. If a meaningful chunk of it is batch or non-interactive, moving it outside the two peak windows is free money you’re currently leaving on the table.