DeepSeek silently swapped the model behind its deepseek-flash API endpoint

DeepSeek swapped the model behind deepseek-flash without telling anyone

On October 17, DeepSeek replaced the model serving its deepseek-flash API endpoint. The endpoint name stayed the same, the price stayed the same, and no changelog entry or email announced the change, so a request on Friday and another on Saturday reached two different checkpoints. That is the account given in a developer analysis published on dev.to by user frankchu, which pulled the new model's public artifacts and worked through the cache arithmetic by hand. The release also became the top story on Hacker News, at 903 points when the author checked.

The replacement checkpoint

The new model is DeepSeek-V4.1-Flash-1017, published to Hugging Face under an MIT license, with a repository creation timestamp of October 17 at 02:40 UTC. It ships as 48 safetensors shards totalling 510,296,708,312 bytes, about 510.3 GB. DeepSeek has described the change as a minor update, but according to the dev.to post its own benchmark table disagrees with that framing: all 11 reported benchmarks improved, with Terminal-Bench 4.0 up 11.1 points and ProgramBench up 8.8. Those are DeepSeek's numbers on DeepSeek's own harnesses, and the post's author notes they cannot be independently reproduced from a desk.

What the config file says

Rather than rely on summaries, the author fetched the model's config.json directly. The notable fields: 40 hidden layers but 43 entries in compress_ratios (five layers at ratio 0, twenty at ratio 1, eighteen at ratio 2); 64 attention heads against a single shared key-value head with a head dimension of 512; a sliding window of 128 tokens; a maximum context of 1,048,576 positions; only four layers, with ids 2, 8, 14 and 20, sourcing long-range KV; a sparse attention index capped at 512 entries; and a mixture-of-experts layout of 384 routed experts with six active per token.

The KV cache math

Coverage of the release has circulated a figure of 890 bytes of KV cache per token, attached to a paper titled "Pushing the Limits of KV Cache Compression." The dev.to author computed bounds from the config instead: assuming every layer stores a 512-dimensional latent per token in bf16 gives 44,032 bytes per token, or 46.2 GB at a one-million-token context; a vanilla multi-head attention transformer of the same width would need 880,640 bytes per token, roughly 923 GB; assuming only the four source layers store ratio-2-compressed long-range KV gives 2,048 bytes per token, about 2.15 GB. The circulating 890 figure sits below even that most aggressive bound, which the author reads as quantization below bf16 plus the sparse index doing the remaining work.

The sharper observation is that bytes per token is not a constant for this architecture. A layer with a 128-token sliding window holds 128 positions whether the prompt is 8,000 tokens or a million. Amortized, the window-only cost falls from 688 bytes per token at an 8,192-token context to 43 at 131,072 and 5.4 at the full 1,048,576, a swing of two orders of magnitude within the same model. Whoever produced the 890 number measured at some specific length and layer mix, and the figure travels without either.

Pricing and the new Search and Fetch API

DeepSeek's published rates are $0.15 per million uncached input tokens, $0.60 per million output tokens, and $0.003 per million cached input reads, making cache hits 50 times cheaper than uncached input. The post reads that ratio as the compression work showing up in the rate card rather than the press release. DeepSeek's own DeepSWE chart, summarized by The Decoder, puts the new model at just under $0.20 per task against $2 to $10 for rivals; the author flags it as a vendor chart on a vendor harness, though directionally consistent with the public config. The release also includes a Search and Fetch API at $0.75 per 1,000 successful requests, free through server-side tools in DeepSeek Harness, Claude Code and Codex until billing starts on October 31 at 16:00 UTC.

Why it matters

By every published measure the new model is better than the one it replaced, so the model itself is not the issue. The delivery is: a silent swap under an unchanged alias means every evaluation run against deepseek-flash before October 17 now describes a checkpoint that no longer serves traffic. The weights are public and the checkpoint name is dated, so a pinned, self-hosted deployment remains reproducible; only the convenient API alias moved underneath users. Teams that pin database versions and container images but let model endpoints float saw this week exactly what that policy costs, not a worse model but a different one than the one they tested. The practical lesson from the post is to pin the checkpoint and verify vendor claims against the config file, which at least can be checked by hand.