The deadline is 15:59 UTC on 24 July

DeepSeek's API documentation states it plainly: the model names deepseek-chat and deepseek-reasoner will be deprecated on 2026/07/24 at 15:59 UTC. After that moment, a request naming either string is a request for a model that does not exist. Anything you have in production that still sends those names stops working, and it stops working late on a Friday afternoon in European time.

That is the visible half of this. It is also the half that will get fixed, because a hard failure announces itself in an error log and someone gets paged. Nine days is enough time to change two strings, and most teams will.

Why it matters: the fix is trivial and the lesson is not. A vendor is about to demonstrate, at a specific timestamp, who in your organisation actually knows which models are running in production. For most companies the honest answer is that nobody has checked since the integration was built.

The alias already moved, and nobody logged it

Read the same documentation one line further. The legacy names are still served today because they are routed: deepseek-chat corresponds to the non-thinking mode of deepseek-v4-flash, and deepseek-reasoner corresponds to its thinking mode. The names survived. The model underneath them did not.

So if your team wrote deepseek-chat into a config file a year ago and never touched it again, your application has already been migrated onto a different model, by the vendor, without a deployment, without a changelog entry on your side, and without any of your evaluations being re-run. Nothing broke, which is precisely why nobody noticed. The outputs kept arriving in the right shape.

The distinction to keep: an alias is a convenience, not a version pin. It is a promise that something reasonable will answer, not a promise that the same thing will answer. Any model name that does not carry a version is a moving target, and that is true of every provider, not only this one.

What you are actually migrating to

The two current models are deepseek-v4-flash and deepseek-v4-pro. Both carry a context window of one million tokens and can return up to 384,000 tokens in a single response, which is a different operating envelope from the one most integrations were designed against.

They are not interchangeable on cost. Published prices per million tokens put Flash at 0.14 dollars for input on a cache miss and 0.28 dollars for output, while Pro runs 0.435 dollars for input and 0.87 dollars for output. Cached input is dramatically cheaper on both. Swapping deepseek-chat for the wrong one of these does not throw an error; it just changes your monthly bill by a factor of three, or quietly downgrades the reasoning behind a workflow you have already told customers about.

Yes, but: this is not an argument for panic-pinning to Pro. It is an argument for choosing deliberately, once, with your own evaluation set, rather than letting a routing table choose for you a second time.

A nine-day checklist

Search everything, not just the application repository. The legacy strings hide in SDK defaults, in gateway and proxy configurations, in notebooks, in scheduled jobs, and in any internal tool a colleague built quickly and never revisited. Grep for both names and treat every hit as production until proven otherwise.

Then re-run your evaluations against the specific V4 model you intend to name, and compare the results with what you believed you were getting. This is the only moment where the silent migration becomes measurable, because you can finally see what the routed model was already doing to your outputs.

Finally, write it down. The exact model identifier, the date you pinned it, who approved it, and what the evaluation showed. The European AI Act's enforcement powers over general-purpose models switch on from 2 August, and whatever your specific obligations turn out to be, a register that names a model retired nine days earlier is not evidence of control. It is evidence that you were not looking.