DeepSeek V4.1 Flash 1017: API Pricing, Search API and My Test

👁 120 reads

DeepSeek V4.1 Flash 1017 combines an updated open-weight checkpoint with a new search offering as of October 2026. I tested the model via the API on October 19, and it completed all 12 tasks in my test in Polish. That result is separate from DeepSeek’s own coding benchmarks and from the Search API, which this test did not use.

What changed in DeepSeek V4.1 Flash 1017

DeepSeek describes V4.1 Flash 1017 as a minor update, but its published comparison reports improvements in reasoning, coding, and agent tasks. The name identifies the October 17 release. It is useful to preserve that suffix when recording results, because an API alias can keep its name while the model behind it changes. The architecture of the first release is described in my DeepSeek V4.1 Flash review, and the other open-weight releases from the same week are in my open-weight AI models overview.

In DeepSeek’s table, DeepSWE v1.1 rises from 74.2 to 77.0, Terminal-Bench 4.0 from 31.2 to 42.3, and Automation-Bench v1.0.6 from 54.8 to 60.5. These are developer-reported benchmark scores. I did not reproduce those evaluations, and they should not be combined with my short Polish test into a single ranking.

DeepSeek also says the update reduces output length and task execution time. That is relevant to agents, where a completed task can involve many model calls. It is not enough to promise a fixed percentage saving in a different application. A shorter answer helps only when it still contains the information or tool action the application needs.

Weights, licensing, and local deployment

The official repository lists the weights under MIT and advertises a one-million-token context. Hugging Face metadata reports 763 billion parameters. That is a repository size figure, not a verified active-parameter count. It also does not tell you how much memory a particular quantized deployment will require.

MIT provides broad permissions, including commercial use and modification, while retaining notice requirements. Calling it a license with “no conditions” would be inaccurate. Its practical appeal here is that the core permission structure is familiar and does not add the custom commercial thresholds used by some other releases in this group.

Running the full checkpoint requires a serious deployment plan. My test used remote inference, so there is no local hardware measurement to report. The repository’s deployment material is the starting point for checkpoint formats and runtime configuration. Buying hardware based only on the active work per token, or on the word “Flash,” would be a poor substitute for that check.

Official API prices in USD

DeepSeek’s official pricing page, checked October 20, 2026, identifies deepseek-flash with V4.1 Flash 1017. Rates below are per one million tokens. Cache status applies to input; generated output has its own rate.

The documented peak windows are 01:00-04:00 and 06:00-10:00 UTC on weekdays, excluding Chinese public holidays. Other times are off-peak. A cost estimate therefore needs the expected cache behavior, request schedule, and generated tokens. The upper input and output rates alone do not describe every request. For the free chat app and general API limits, see my DeepSeek costs and limits guide.

These list prices are distinct from the usage charges recorded in my test. A historical run via the API can involve different serving and billing conditions. Its measured cost should stay attached to that run, rather than being presented as a quote for a future direct deployment.

Search and Fetch are separate services

The Search API returns ranked web results, while Fetch retrieves a page as Markdown. DeepSeek documents up to 50 search results per request and prices each service at $0.75 per 1,000 successful requests. The billable unit is a successful request, not each returned result.

The search guide excludes failed requests, empty search results, and timeouts from billing. Its wording about introductory access differs from the pricing page, which explicitly dates billing for integrated server-side tool calls to November 1 at 00:00 Beijing time, or October 31 at 16:00 UTC. That dated statement should not be expanded into a blanket promise that every standalone request is free until then.

For an application, search and generation solve different problems. Search supplies current material; the language model must still select, interpret, and cite it correctly. Fetching a page does not establish that its claims are accurate, and a plausible generated answer does not prove that the sources support it.

• Keep retrieved URLs and source text available for checking.
• Track search and fetch requests separately from model tokens.
• Validate whether an answer is supported by the retrieved material.
• Test empty retrieval results as well as successful searches.

Those are evaluation steps for a future application. I did not run a search-quality benchmark or measure retrieval speed in this test, so there is no firsthand comparison with other search products here.

What the Polish test actually showed

My October 19 test contained 12 short Polish prompts, each submitted once at temperature 0 with a 6,000-token completion limit including reasoning. DeepSeek returned an accepted answer to every task (all four models compared: open models tested in Polish). The set covered arithmetic, inflection, letter counting, invoice extraction, a checksum, logic, a historical weekday, formatting, local knowledge, unit conversion, spelling, and a number sequence.

The median elapsed request time was 0.95 seconds, and the longest recorded request took 2.4 seconds. Recorded completion usage totaled 1,283 tokens. The summed cost was $0.00062014, or approximately $0.0006 for the set. These are observations from the saved results, not estimates calculated from today’s published rate table.

The final 12/12 score includes a correction to the spelling grader. DeepSeek used the valid imperative “Weź parasol” where the original rule expected an infinitive. Accepting the alternative repaired an overly narrow grading rule. No answer was regenerated to obtain the final score.

The result is encouraging for similar short tasks, but it does not measure long-form Polish, English quality, image interpretation, or repository-level coding. Requests could also reach different serving backends. The reported latency belongs to the observed API experience rather than an isolated measurement of inference speed.

FAQ

Do existing API users need a new model name?

The official pricing page maps deepseek-flash to the updated checkpoint. Record the checkpoint date in your evaluations even when an application keeps using the same alias.

Was Search API responsible for the perfect score?

No. The test sent text prompts without search tools. It cannot establish whether Search or Fetch would improve a different task.

Is this evidence that DeepSeek is the best open model?

It completed this small Polish set and had the lowest median time in the run. Broader claims need broader tests, especially for tasks involving tools, images, or extended conversations.