DeepSeek V4 goes GA: the endpoint rename that changes your agent's answers

DeepSeek V4 went GA on July 24, and the same day at 15:59 UTC the legacy model names deepseek-chat and deepseek-reasoner were permanently retired. That second event is the one that matters operationally. In the days before the cutoff those two names were already routing to deepseek-v4-flash, so anything that still worked was already running on a different model than the one it was evaluated against. After the cutoff it does not run at all. If you have DeepSeek anywhere in a production agent or an eval harness, the migration is not optional and the regression check is not either.

What changed on the wire

The migration itself is mechanical. Replace the model ID with deepseek-v4-pro or deepseek-v4-flash. The base URL does not change, and the API supports both the OpenAI ChatCompletions shape and the Anthropic-style API, so existing clients keep working after a one-line edit. Two things are not mechanical. V4 runs with a 1M token context by default across the service, and V4 has explicit thinking and non-thinking modes that you need to test separately, because the old deepseek-reasoner name implied a behavior that is now a mode switch. On August 13, V4-Pro-0813 left preview and became generally available on the app, web, API and third-party routers, so if you pinned an earlier V4-Pro build you have a second migration to plan.

The headline number DeepSeek quotes is 80.6% on SWE-bench Verified for V4-Pro at roughly one seventh of the output price. The brief does not say one seventh of what; I assume the frontier models it is benchmarked against. It is a vendor figure either way.

Why 1M context costs less than you expect

V4 is built on DSA, DeepSeek Sparse Attention, plus token-wise KV compression. At 1M tokens, V4-Pro needs roughly 27% of the single-token inference FLOPs and roughly 10% of the KV cache that V3.2 needed, which DeepSeek translates into about a 73% cost saving on long-context work. DSA gets there by keeping a fixed top-2048 tokens per query instead of attending to everything, which works out to about a 98% saving in attention compute at 128K.

There is a catch anyone doing KV cache math will recognize. The index step that selects those 2048 tokens is HBM-bandwidth-bound once you pass roughly 512K tokens. Beyond that point the ceiling is memory throughput, not compute, so the cost curve flattens rather than keeps dropping. If you serve V4 yourself, vLLM 0.21 stabilized it on Blackwell with a new TOKENSPEED_MLA backend and adjusted speculative decoding so the draft model respects the reasoning budget.

An endpoint that silently changes its target model is a breaking change with no version number, and your eval suite is the only thing that will notice.

The silent-migration playbook

Keep this for the next vendor that does the same thing.

• Pin explicit model IDs everywhere. Aliases like chat and reasoner are convenience names a vendor can repoint without telling you. Use deepseek-v4-pro or deepseek-v4-flash and nothing shorter.
• Freeze a golden set before you switch. Fifty to two hundred real prompts from production with the old outputs saved. Run them against the new ID and diff on task success, output length and latency, not just whether it returned.
• Test thinking and non-thinking as separate configs. They have different cost, latency and answer style. Decide per route, not globally.
• Re-check token counts. A different model under the same name changes token volume, which changes the bill even at the same per-token price.
• Alert on distribution shift. Median output length and tool-call rate per route are cheap to log and are the first things that move when a model changes underneath you.

For where V4-Pro and V4-Flash sit in a routing stack, see DeepSeek in 2026.

The honest gap

Every efficiency number above is DeepSeek's own, measured against its own V3.2. The 27% FLOPs and 10% KV cache figures describe the architecture at 1M tokens, not what you will see at the 30K to 100K contexts most agent loops actually run, and DSA's fixed top-2048 selection is a quality trade the vendor benchmarks do not isolate. I have not run a long-context recall test on V4-Pro myself. Until you have, the posture is: migrate today because you must, and treat the cost saving as unverified until your own eval says otherwise.