Same DeepSeek API call, a different model than yesterday
If you were calling DeepSeek Pro through the API yesterday, the 12th of August, then today the same API call is serving you a different model. The identifier deepseek-v4-pro now resolves to deepseek-v4-pro-0813, where yesterday it did not. You probably did not realise you were on a pre-GA build, because nothing on the pricing page tells you. The only clues sit in blog posts and a footnote deep in the API docs.
The same thing happened with DeepSeek Flash on the 31st of July, when deepseek-v4-flash quietly became deepseek-v4-flash-0731. The confirmation of this in Deepseek's updates - "same architecture and size, only re-post-trained".
The mechanism is simple once you see it. DeepSeek serves the latest build under a fixed model name. You ask for deepseek-v4-pro and you receive whatever that name currently points at. There is no way to pin a dated version, the docs are explicit that you set the model name to the base string and take the current build. This is convenient until the current build changes, at which point your production behaviour moves without a single line of your code changing.
What makes it unusual is that the pricing page labeled neither model as preview. Both deepseek-v4-flash-0731 and deepseek-v4-pro-0813 appear as ordinary version strings with no status marker. The one hint that Pro was behind was a footnote noting that the Responses API supported only Flash, with Pro support arriving later. You have to go looking to learn that you were running pre-GA software.
There is a second, quieter version of the same problem. DeepSeek is introducing peak and off-peak pricing, so the same API call will cost a different amount depending on the time of day it runs. The model identity moves without a line of your code changing, and now the economics move too. A job that was cheap to run overnight is dearer in peak hours, and nothing in your code says so.
What will be interesting is what happens now they are GA. Will the next version let you stay on the build you have, or just silently replace it? Only time will tell. You can almost forgive a preview model being replaced. Google withdraws theirs often, with short notice, and sometimes with no replacement when a newer major or minor version is imminent. That doubt makes the first party API a risk, which is a shame, as it is so inexpensive compared to models of similar capability.
There is a way around it. These are open source models, so you can pin a version through a third party inference provider and hold it steady for as long as you need. The first party API remains the robust, fast and cheap option compared to running DeepSeek elsewhere, so the trade is convenience and price against control over exactly which build you run.
The interesting question is why DeepSeek is different here. The answer is that they are a research lab scaling into production infrastructure, and versioning conventions are exactly the sort of thing that lags when a lab grows into a service. The versioning aside, they do a good job. Their KV cache is very effective and elegant, and the first party API is fast and cheap in a way that reflects real engineering care. The rough edge is the part that is still catching up with the research.
Deepseek's KV cache
When using Deepseek I noticed that I hit the KV cache for much more often and much longer, even after editing earlier context in a dialog. The docs describe each request creating two cache prefix units, one at the end of your input and one at the end of the model's response. Every call leaves reusable cache entries behind.
DeepSeek also does common prefix detection. Across multiple requests it persists a shared prefix as an independent cache prefix unit. If you edit a message part way through a long conversation, the history is still reused from the cache up to the point you changed. The docs put the cache lifetime at a few hours to a few days. Working within one long conversation and editing the context often, each message can cost fractions of a cent.
This works because the prefix units are stored on SSD rather than in memory. Multi-head Latent Attention compresses each token's KV entries down to a fraction of their normal size, which is what makes keeping so many prefix units on disk cost effective.