DeepSeek New Version Hands-On: Same Price, Costs Slashed by 60%

Title

DeepSeek New Version Hands-On: Same Price, Costs Slashed by 60%

Meta Description

DeepSeek^Ad v4.1 Flash 1017 cuts DeepSWE task cost by ~2.5x with the same architecture and price. Overseas bloggers break down controllable reasoning effort, length-penalty RL, and token economics, revealing how shorter output tokens became the core cost driver, and analyze testing framework differences behind 11 benchmarks and local deployment implications.

Article Content

After the release of DeepSeek v4.1 Flash 1017, an overseas tech blogger dissected this "minor update" and found a detail most coverage missed: the architecture is unchanged, the price is unchanged, but completing the same DeepSWE task costs about 2.5x less. Where does the savings come from? The answer lies in post-training strategy and token economics.

Version Naming and Product Positioning: The Date Is the Version Number

1017 is just a date—October 17. DeepSeek's iteration cadence is quite clear: release a new architecture first, then spend the following months refining the same architecture with new post-training. v4 Flash preview launched in April, v4 Flash 0731 arrived in late July (same architecture and size, more thorough training), v4.1 Flash in September brought the causal encoder-decoder and NGRAD memory mechanism, and five weeks later 1017 appeared as a "sharper, more efficient" version of the same model.

DeepSeek calls it a "minor update that delivers substantial improvements." It sounds like PR speak, but the blogger considers it the most accurate description of this release. Weights are still released on Hugging Face under the MIT license, 48 files totaling about 510GB, consistent with before. On the API side, if you've been calling DeepSeek Flash, you've already been automatically switched to 1017; the old model name was retired and silently routed to 1017. Context window is 1M tokens, max output 384,000 tokens, the vision experimental model has been merged in, and images and code go through the same model.

Sweeping All 11 Benchmarks, but 4 Details Deserve Discounts

DeepSeek published 11 benchmarks, and 1017 surpasses its predecessor on all of them: Tools rose from 36.8 to 42.6, DeepSWE from 74.2 to 77.0, ProgramBench jumped from 20.3 to 29.1, and the largest single gain was TerminalBench 4.0 from 31.2 to 42.3—a full 11 points.

However, the blogger notes four details worth attention. First, testing frameworks differ: 1017's TerminalBench ran within the ClaudeCode framework, while the September baseline ran within the DeepSeek framework, and the same model once showed a near-9-point gap on DeepSWE (65.5 vs. 74.2) across different frameworks—so the largest gain carries the largest asterisk. Second, Artificial Analysis independently tested the old Flash on TerminalBench and got only 26.8%, not 31.2%, meaning the baseline may be even lower. Third, competitor comparisons used Opus 5 and GPT 5.6 Sol rather than the newest models; Opus 5.5 scores 66.4% on TerminalBench, 24 points above the new model, and GPT 6.1 Sol leads slightly on DeepSWE at 75.2%. Fourth, the old model's NL2 repo score was 64.0 on the September card but 65.4 in the new table, indicating not all columns were rerun under identical conditions.

In the technical report, DeepSeek acknowledges that benchmark alignment does not equal the model matching closed-source frontier on hardest edge cases, and the blogger expresses respect for that.

The Real Source of the Cost Drop: Output Tokens Got Shorter

Most videos say DeepSeek didn't give specific numbers on output shortening, but the blogger points out the data is hidden in a chart in the release post. The chart shows the log relationship between DeepSWE pass rate and average cost per task: the new model scores 77% at max effort at about 20 cents, 2.5x cheaper than the old model and with a higher score. More critically, the low tier—about 72.6% at about 11 cents—directly beats the old model's high tier at 70.2% and 29 cents. The new model's cheapest mode wins at less than half the price of the old model's mid tier.

What about input tokens? OpenRouter data over the past 30 days shows the old Flash processed about 122 trillion prompt tokens but only 2.2 trillion completion tokens, a ratio of about 55:1, and most prompts were cache hits. But once you price each token category, the picture completely changes: cache hits cost 0.3 cents per million tokens, output tokens cost 60 cents per million—a 200x difference. Calculating October 16 single-day traffic at DeepSeek's list prices, output tokens account for only about 2% of total volume but about 47% of the bill; uncached input accounts for about 42%; cache reads, which are 93% of input tokens, account for only about 11% of cost.

So once cache reads are nearly free, the biggest lever on the bill is how long the model talks. There's also a second-order effect: shorter outputs usually mean fewer agent loop turns, and each turn rereads the entire context from cache, so short outputs further compress the input loop.

The pricing difference between cache hits and uncached input is key to understanding token economics. LLM APIs typically distinguish "cache hits" from "uncached" input tokens: the former refers to prefixes repeated from previous requests (such as system prompts, long contexts, tool definitions), which providers can reuse from KV Cache without recomputation, hence very low pricing; the latter requires full forward computation and is priced higher. In DeepSeek's pricing, cache hits cost only 1/200 of output tokens, making the cost of repeatedly rereading the same context in agent scenarios almost negligible. But cache has a lifecycle (usually minutes to hours), and only strict prefix matches hit, so keeping context stable and avoiding frequent changes to system prompts in multi-turn agent loops is a practical technique for lowering the bill.

Controllable Reasoning Effort: Using Length Penalties to Make the Model Talk Less

With not a single architecture parameter changed, how does the model learn to talk less? The answer is in the "Controllable Reasoning Effort" section of the technical report. During reinforcement learning, DeepSeek writes an effort level from 1 to 100 into the system prompt, and the reward includes a length penalty—the more reasoning tokens generated, the more points are deducted, but the penalty shrinks exponentially with effort level. At low effort, every extra token is penalized; at high effort, it's much more lenient. Analogy: short-answer questions lose points for exceeding the word limit, while essays are allowed to be long.

More cleverly, rewards are only compared within the same effort level, so a short, low-effort answer is never compared against a max-effort answer that thinks ten times as long. The API maps directly onto this scale: low corresponds to 50, high to 75, max to 100. For 1017, DeepSeek only says it used RL with self-feedback and doesn't detail what changed in the reward. The blogger's speculation is that length pressure was increased, perhaps rewarding the model for "checking once instead of five times," precisely targeting the overthinking habit criticized in September.

Length penalties in reinforcement learning are a reward-shaping technique: in policy gradient or preference optimization objectives, a negative term is applied to the number of tokens in the generated sequence, guiding the model to compress its reasoning chain while maintaining accuracy. Common forms include linear penalties on total length, truncation-style penalties on portions exceeding budget, or—as DeepSeek does—letting the penalty coefficient decay exponentially with effort level, thereby strongly suppressing verbosity at low tiers while preserving space for long chains of thought at high tiers. The difficulty is that too strong a penalty causes the model to skip necessary steps and suffer a sharp drop in accuracy, so it usually requires multi-objective balancing with correctness rewards and relative comparison within the same effort bucket (similar to group normalization) to avoid reward scale mismatch caused by short answers competing directly with long answers.

Hands-On Feedback and Local Deployment Implications

Early feedback is mixed. Teotaxes, who tests DeepSeek models on day one every release, says 1017 is much faster for the first 90% of a task but tends to get stuck polishing details near the finish line, requiring human oversight to wrap up. The length penalty worked, but didn't fully cure it.

The bigger picture: this release isn't really targeting API cost, but the time problem. Bartz Lodiczka compared the old Flash and GPT-6 Astra on the same batch of builds—DeepSeek was far cheaper, but took 4 hours 14 minutes for 47 tests. World of AI thinks the biggest problem is overthinking and running unnecessary tests. Tokens per second didn't change because neither the architecture nor speculative decoding changed; to go faster, you can only spend fewer tokens.

Token efficiency matters more in local deployment. The architecture is exactly the same as September's v4.1 Flash—51B activated, 552B backbone parameters, 40 layers, 384 experts—the config file is unchanged word for word, so hardware that runs the old version runs the new one. Experts are already FP4 (4 bits per parameter), so conventional 4-bit quantization doesn't help much; the Engram memory table can be placed on SSD (only about 12KB read per token), but experts cannot—the router selects 6 of 384 experts per layer, and each token selects a different set, so they must reside in high-speed memory. A single DGX Spark with 128GB unified memory and 273GB/s bandwidth can't fit the experts; the community typically clusters 4 units for 512GB, and the price has risen from $3,999 to about $6,950, so four units cost about $27,800 excluding networking.

On the API, Artificial Analysis measured the old Flash at about 176 tokens/sec, and the 88,000 output tokens used by Intelligence Index tasks take about 8 minutes; at 40 tokens/sec at home, it would take 37 minutes. If 1017 really uses half the output, that saves about 18 minutes per task—only a few cents on the API, but hours saved per day of agent runs at home. Completely different economics.

The local deployment bottleneck for MoE models lies mainly not in compute but in memory bandwidth and capacity. Take the sparse structure of 40 layers, 384 experts per layer, and 6 activated per token: routing is dynamic per token per layer, and the expert sets hit by different tokens almost never overlap, so unlike dense models you can't just load some layers; all expert weights that might be selected must reside in high-speed memory (HBM or unified memory), otherwise each swap in and out will crush throughput. FP4 quantization has already compressed each parameter to 4 bits, so the marginal gain of further 4-bit quantization is small—the real constraint is capacity. Engram-style memory tables can be streamed from SSD per token because access patterns are predictable and per-token data volume is small; experts are the opposite—highly random, large per-read volume—so SSD latency can't be hidden. That's why clustering multiple large-memory devices has become the consumer-grade solution.

A New Signal for Model + Framework Co-Design

1017 is optimized for DeepSeek Harness 0.1+ and Tencent CodeBuddy. On the same day, DeepSeek opened its search and crawl API at $0.75 per thousand calls, free through DeepSeek Harness, Cloud Code, and Codex until October 31. The technical report states outright that the model and framework will co-evolve—the capability unit is no longer just the model, but the model plus the framework. Skeptics will point out that a model that only performs well in its own framework is hard to rely on; the September model already swung 9 points across frameworks, and if the new version is tuned harder for its own scaffolding, the swing could be larger—which is exactly why the TerminalBench framework switch deserves attention.

On the Artificial Analysis Intelligence Index, the old Flash scores 39.5, GPT 6.1 Sol 51.8, and Opus 5.5 57.6; the new version has no independent data yet. DeepSeek doesn't claim to have caught up, but offers a narrower, more honest promise: 1017 does the same work with fewer tokens.

There's also a geopolitical timing point: the day before the release, China's Ministry of Commerce and Ministry of Science and Technology proposed adding 23 AI technologies to the export restriction list, including large models, agents, and computing clusters; already-open-source technologies are exempt, and open source can quickly obtain licenses, so 1017 is already out the door, but whether the next major version can pass as smoothly is an open question.

The blogger concludes: last month I said cost efficiency alone can't stand; 1017 is the first time DeepSeek has propped up that leg with token efficiency without touching architecture or price, and the mechanism is elegant. But intelligence is still the missing leg. Historical experience is that cheaper tasks don't make us spend less—they make us run more tasks. What's really worth waiting for is a V4.1 Pro that brings this efficiency to a model that actually thinks better, and whether an industry happy to charge for long chains of thought will be forced to make models talk less.

Model-framework co-design refers to joint optimization of model training and inference scaffolding: the framework determines tool-call formats, context organization, retry and validation logic, and the model is post-trained for these patterns, thereby achieving the best results within its own framework. The benefit is high end-to-end efficiency and improved agent task completion rates; the risk is reduced evaluation transferability—when the same model is moved to third-party frameworks like ClaudeCode or Codex, prompt formats and tool schemas don't match, and scores may fluctuate noticeably. The industry is therefore increasingly emphasizing reporting benchmarks across multiple neutral frameworks and distinguishing "model capability" from "model + framework system capability." For users, when selecting a model, priority should be given to measured data within the target framework rather than leaderboards under a vendor's single framework.

One-line Summary

DeepSeek v4.1 Flash 1017 keeps the same architecture and price while cutting task cost by ~2.5x by shortening output tokens.

Paragraph Summary

DeepSeek v4.1 Flash 1017 is a "minor update": architecture, weight size, and price are identical to the September version, but completing the same DeepSWE task costs about 2.5x less, with the low tier beating the old high tier at about 11 cents vs. 29 cents. The core cost driver isn't input but output—output tokens are only about 2% of total token volume yet about 47% of the bill, while cache reads are 93% of input but only about 11% of cost, so making the model "talk less" becomes the biggest lever. Mechanically, DeepSeek introduced effort levels from 1 to 100 and an exponentially decaying length penalty in RL, with rewards compared only within the same level, and the API maps low/high/max to 50/75/100. All 11 benchmarks are swept, but there are discounts for inconsistent testing frameworks, baseline bias, and competitors not being the newest models. For local deployers, token efficiency matters more than API savings, saving hours; but MoE experts must reside in high-speed memory, and four DGX Sparks cost about $27,800.