DeepSeek V4.1 Flash 1017 Released: Weights Open, Search API Begins Billing
According to a Xinzhiyuan report on October 17, 2026, DeepSeek launched DeepSeek-V4.1-Flash-1017, centered on 'wish-style programming,' with web, app, and API updated in sync; the company said pricing is unchanged and weights are open. The source says the Search and Fetch APIs each charge 5 yuan per 1,000 calls, while server-side calls within Harness, Claude Code, and Codex begin billing on November 1.
What changed
According to a Xinzhiyuan report on October 17, 2026, DeepSeek announced a major V4.1 Flash upgrade, with DeepSeek-V4.1-Flash-1017 fully launched across web, app, and API. The report says the update centers on 'wish-style programming,' meaning the model can directly generate runnable full project prototypes; the source cites official demos including a Forbidden City 3D scene, a web racing game, a Godot-engine Portal 2 recreation, and a historical city evolution project, and the company attributes this capability gain to reinforcement learning training based on self-feedback. On benchmarks, the source cites an official comparison table saying Terminal-Bench 4.0 rose from 31.2 to 42.3, ProgramBench from 20.3 to 29.1, and DeepSWE v1.1 from 74.2 to 77.0; in the DeepSWE v1.1 performance-cost chart (test framework mini_swe_v2), the new max tier shows a 77% pass rate at 1 to 2 yuan per task on average, while the old max tier was 74.2% at 3 to 4 yuan on average. The source says the model's API calling method and unit price are unchanged, still invoked through deepseek-flash, with shorter outputs and faster task completion. On weights, the report says the 1017 version is already available on Hugging Face and ModelScope, and notes that the code repository and model weights use the MIT license. On search, the source says the in-house search API opens two endpoints, Search and Fetch, for retrieving web pages and fetching body text respectively; the two endpoints are billed separately at 5 yuan per 1,000 calls each, and only successful calls with results are billed; the source also notes that server-side Search/Fetch tool calls initiated through the DeepSeek API within DeepSeek Harness, Claude Code, and Codex are currently not billed, and will be charged per call starting from 00:00 Beijing time on November 1, 2026. All of the above are relays of the source and official statements; KimiSeek has not independently verified them.
What it means for developers
The direct impact on developers is concentrated in three points. First, the same call identifier remains usable, meaning existing code based on deepseek-flash theoretically needs no change to the integration layer to get the new version, but the source's claim that 'the calling method and unit price are unchanged' is an official statement; which version actually gets routed, the rollout scope, and the rollback strategy still need to be verified independently. Second, the source says both the code repository and weights use the MIT license, which is a substantive change for teams needing local deployment or redistribution, but one must distinguish 'weights are downloadable' from 'the rights granted by the license'; before implementation, the repository's actual LICENSE file and the model card's restriction terms should be checked. Third, search billing has two layers: the Search and Fetch endpoints themselves are billed per call, and failed, timed-out, or empty-result calls are not billed; while server-side tool calls initiated through the DeepSeek API within DeepSeek Harness, Claude Code, and Codex are currently not billed, and will begin to be charged per call from November 1. Any pipeline that puts an Agent through Search/Fetch will see its cost structure change with that date, and per-call billing for high-frequency retrieval Agents will scale linearly with call volume, which in turn affects the design of retry and caching strategies. On performance-cost, what the source published is official self-tested data and its own harness; cross-vendor comparison conclusions should not be directly extrapolated; if the new version indeed shortens both output length and task duration, in token-billed scenarios the total cost reduction may come from two sources—a higher pass rate and shorter outputs—and the two need to be evaluated separately.
Integration and evaluation
The following are conditional suggestions, not reported facts. Decision one: whether to switch an online coding Agent to the 1017 version. The basis is the source's claim that DeepSWE v1.1 rose from 74.2 to 77.0 and the max tier's per-task cost dropped from 3 to 4 yuan to 1 to 2 yuan (all official statements). The choice is to first run both versions in parallel on shadow traffic; the condition is that your tasks are mainly multi-step code modifications and terminal operations, and you care about task success rate rather than first-token latency. A measurable evaluation criterion: on 30 to 50 real issues in your own repository, compare Pass@1 and average per-task cost using the same harness, requiring the pass rate to be no lower than the old version and per-task cost not to rise, otherwise do not switch. Decision two: whether to deploy the 1017 weights locally. The basis is the source saying the weights are open and marked with the MIT license. The choice is to self-host only if you have GPU memory and operations budget, and data egress is restricted; the condition is that you have checked the repository's LICENSE text and can bear the inference cost of a model of this scale or are willing to quantize/compress. A measurable evaluation criterion: measure end-to-end P95 latency and per-task success rate on your local inference stack with real business prompts, and keep the self-hosted route only if the gap with the API version is within an acceptable range. Decision three: whether to restructure search tool calls before November 1. The basis is the source saying Search/Fetch cost 5 yuan per 1,000 calls each, failures and empty results are not billed, and server-side calls within Harness/Claude Code/Codex are free before then. The choice is to reduce retrieval counts and add result caching before the switch; the condition is that your retrieval Agent has high daily call volume and retrieval results are reusable. A measurable evaluation criterion: count billed successful calls and the empty-result ratio for one week before and after the switch; if empty results and failures make up a high share, prioritize fixing query construction rather than increasing call volume. For specific prices, refer to DeepSeek's official pricing page.
Limits and open questions
To be clear: KimiSeek's live catalog already contains an exact-match entry, DeepSeek V4.1 Flash 1017 (id deepseek-v4.1-flash-1017); the version described in this report's listing status and billing on the platform are subject to what KimiSeek's pricing page and catalog actually show. The source's claim that API unit prices are 'unchanged,' the billing arrangements for the search endpoints and tool calls, and all benchmark scores are DeepSeek's own statements; KimiSeek has not independently verified them. Second, the source's 'weights open, MIT license' is a relay of what the official repository states; we have not checked the license text, and downloadable weights do not mean the license automatically grants commercial use or redistribution rights—before deployment you must check the repository LICENSE and model card yourself. Third, all performance and cost data in the source are official self-tests, the test framework is mini_swe_v2, and the cross-vendor comparison table was compiled by the vendor itself; differences in evaluation sets, harness, and sampling configurations exist, and it should not be treated as an independent evaluation conclusion. Fourth, the comparison model names and scores mentioned in the source (such as GPT-5.6 Sol, Claude Opus 5, GPT-6 Astra) are all as stated in the original report; we have not verified the authenticity of these names or versions. Fifth, capabilities such as search filtering and multilingual indexing are official descriptions; actual recall quality, empty-result rate, and rate-limiting rules need to be tested yourself. Finally, the source does not state the 1017 version API's quotas, concurrency limits, and rollout scope, nor the hardware specifications required for local deployment; these unknowns will directly affect switching and self-hosting decisions.