DeepSeek V4.1-Flash-1017: tokens, search and the real cost per task

The cost per task gained a line that the cache does not discount
On October 17 DeepSeek published V4.1-Flash-1017, with MIT weights and the Search and Fetch APIs at US$ 0.75 per 1,000 successful requests per endpoint (official announcement, consulted on 2026-10-20). The fee starts on October 31, at 16:00 UTC. Until then, only whoever calls Search and Fetch through server-side tools fails to see the second line in the statement.
The cutoff falls on a Saturday, at 13:00 in Brasília. It is the kind of date that goes unnoticed: whoever runs a coding agent in production is not reading a statement at the weekend, and the November invoice arrives with a line nobody budgeted for. DeepSeek did not launch the model as the cheapest on the market. It launched it as a simultaneous improvement in performance and cost, and put its own search inside the same invoice.
The question that matters to the CTO is not what a token costs. It is what the task costs. And how many lines it has.
What DeepSeek published on October 17
The announcement describes the 1017 as a simultaneous improvement in performance and cost over the September V4.1-Flash: weights open under the MIT license, 1M tokens of context, a recommended output of at least 256K, and the Search and Fetch APIs (search and page extraction) from DeepSeek's own search engine.
The weights are in the deepseek-ai/DeepSeek-V4.1-Flash-1017 repository on Hugging Face, with the field license: mit, and the release is mirrored on ModelScope. The repository ships reference inference: checkpoint conversion, torchrun with tensor parallel 8 and fp4 dtype for the experts. It is enough to run on your own hardware, and it is far from a production recipe.
The recommended context window is 1M tokens. For output, the model card recommends max_tokens of at least 256K, and the word matters: it is a floor, not a ceiling.
In the API the name is deepseek-flash, and it is already served by the 1017 with no change to the call. The earlier names, deepseek-v4-flash and deepseek-v4-flash-vision-exp, are still accepted, routed to the 1017 and billed as Flash. For the Harness, the announcement recommends version v0.2.1-rc.1 or later. The rc.2 came out the same day, at 08:16 UTC, 2h54 later, and it is the one that adds support for the 1017 and for the Search and Fetch APIs.
The benchmark block belongs to the vendor, and the harness travels with the number
On DeepSWE v1.1, the 1017 scores 77.0 against 74.2 for the September V4.1-Flash, 74.0 for Opus 5, 73.0 for GPT-5.6 Sol and 67.5 for K3, all running on the Mini-SWE-V2 declared by the card. On Terminal-Bench 4.0, with the Claude Code harness, the 1017 scores 42.3 and Opus 5, 51.8. On NL2Repo-Bench, 68.2 against 75.3 for Opus 5, the two comparisons in the card where the 1017 loses. On Automation-Bench v1.0.6, 60.5.
The caveat is not a formality. The V4.1-Flash technical report states that RL training with self-feedback ran on heterogeneous scaffolds, including Claude Code, Pi and DeepSeek Harness itself in two modes. A model trained inside a harness and measured inside a harness carries the harness in the number: comparing it with another model requires that the other model was measured with the same step and token-budget configuration, and the card does not claim that.
Why this changes the cost per task
Because the billing unit is no longer only the token. With Search and Fetch in the same provider, an agent task now has two lines with opposite dynamics: tokens fall with caching and shorter output, a tool call is a fixed price per request. In the task modelled in this analysis, the 14 requests add up to 36% of the bill. The search engine weighs in before the model enters the bill, as the comparison of web search by engine and depth already showed.
The token bill has three behaviours that the fee does not share. Cached input costs 2% of the full price, the 98% discount that Artificial Analysis records for this model. Output is billed per token generated. A tool call has no cache. It gets no volume discount and the price per request does not fall when the model becomes more efficient: it costs US$ 0.75 per 1,000 successful requests, per endpoint, and the count parameter does not change the price.
With the number of calls per task constant, every efficiency gain from the model pushes the token bill down and leaves the tool line standing in the same place. The condition is not rhetorical: part of the gain of an agentic model shows up precisely as fewer calls per task, with fewer search rounds, less reformulation and fewer retries, and then the tool line falls with them. What decides the tool share is calls per task, not the quality of the model. With 14 fixed calls, the announced gain acts on the 64% that comes from tokens, the largest and only part of the bill with a cache discount, and it does not touch the 36% that comes from tools. The 1017 card publishes neither calls per task nor a tool-calling success rate, so the count of 14 is an assumption, not a measurement.
The external anchor for cost per task is Artificial Analysis, read on 2026-10-20: Intelligence Index 45, second place among 121 models, 216.5 output tokens per second, US$ 0.30 per 1M input and US$ 1.20 per 1M output, and an average cost of US$ 0.26 per task from the index itself.
That US$ 0.26 is not the number of this analysis, and confusing the two is the easiest mistake to make. It is calculated on tokens only, without the tool fee, and so it underestimates exactly the line this analysis says nobody budgets for: the only independent cost-per-task number available in the market cannot see the second line. It also measures the average task of the Intelligence Index, with another length and another tool density, and it serves as an order of magnitude for what a third party measured. The methodology of cost per task in the routing decision already separated these two uses of the number.
The position of this analysis is direct: budgeting an agent by token is not a conservative estimate, it is structural underestimation, and the error grows in the flows that depend most on search. Whoever has already measured the real cost of an AI application beyond the price per token recognises the pattern: the line that decides is not in the provider's table.
The bill, line by line
The bill has three named assumptions and a table. With the token price from Artificial Analysis and the official tool fee, the reference task costs US$ 0.0291 after October 31 and US$ 0.0186 in the free window. The 56% increase does not come from tokens.
The exemption that produces this before and after has a scope, and the scope decides who sees the difference. It covers Search and Fetch calls made through server-side tools in DeepSeek Harness, in Claude Code and in Codex until October 31, at 16:00 UTC. Whoever calls the Search and Fetch APIs directly already pays US$ 0.75 per successful request today, and for that flow there is no window: the bill starts at US$ 0.0291.
All three have a name so that they can be swapped.
P1, shape of the task. 8 turns, 120K input tokens accumulated, 90% cache hit, 12K output tokens and 14 tool calls, 8 of them Search and 6 Fetch. It is modelling, not a customer measurement.
P2, token price. US$ 0.30 per 1M input and US$ 1.20 per 1M output, with a 98% cache discount, which gives US$ 0.006 per 1M input on a cache hit. Source: Artificial Analysis, read on 2026-10-20.
P3, tool price. US$ 0.75 per 1,000 successful requests, each endpoint. Source: official announcement and Search guide, consulted on 2026-10-20. A request with an error, an empty result or a timeout is not billed.
| Line | Calculation | Cost |
|---|---|---|
| Uncached input (12K tokens) | 0.012M × US$ 0.30 | US$ 0.0036 |
| Cached input (108K tokens) | 0.108M × US$ 0.006 | US$ 0.000648 |
| Output (12K tokens) | 0.012M × US$ 1.20 | US$ 0.0144 |
| Token subtotal | sum of the three lines | US$ 0.0186 |
| Search and Fetch (8 and 6, 14 requests) | 14 × US$ 0.75 ÷ 1,000 | US$ 0.0105 |
| Total with the fee | tokens plus tools | US$ 0.0291 |
| Total in the free window | tokens only | US$ 0.0186 |
The difference between the last two lines is the before and after of October 31, and it applies to whoever uses Search and Fetch through server-side tools in the Harness, in Claude Code or in Codex. That agent, with the same code and the same volume, goes from US$ 0.0186 to US$ 0.0291 per task, a 56% increase. At 100,000 tasks per month, the new line adds up to US$ 1,050.
The tool line in the table is a floor, not the cost of the tool. Every Search or Fetch result comes back into the context and is billed as new input token, without cache, and the bill above treats the call as US$ 0.00075 and ignores what it brings back. With an explicit assumption of 40K tokens of return spread across the 14 calls, the return costs 0.040M × US$ 0.30, or US$ 0.012, more than the US$ 0.0105 fee itself, and the total goes to US$ 0.0411, 41% above the headline number. There is no need to fix the size of the return to close the argument: the line has a third component, the ingested token, and that is why the 36% share is a floor, not a ceiling.
The unit a buyer uses is also not the attempt, it is the resolved task. With a 70% success rate, a named and illustrative assumption because the card publishes DeepSWE, Terminal-Bench and NL2Repo on another task distribution, the cost per successful task goes from US$ 0.0291 to US$ 0.0416, and the tool fee is paid on the attempts that fail as well. Dividing both sides by the same rate does not move the self-host crossing, which is counterintuitive and worth recording: if both routes fail in the same proportion, the ratio between them stays the same. The crossing moves when the rate differs between the routes, and the difference is not neutral: a node without high availability and without on-call has a lower success rate, and each extra failure reduces the resolved tasks per hour.
| Route | What goes into the bill | Cost per task | 1,000 tasks |
|---|---|---|---|
| Hosted API with the tool fee | tokens plus 14 calls | US$ 0.0291 | US$ 29.15 |
| Hosted API in the free window | tokens, with Search and Fetch exempt through server-side tools until 10/31 16:00 UTC | US$ 0.0186 | US$ 18.65 |
| Self-host, 1,200 tasks per hour, search in the API | US$ 0.0167 of node plus US$ 0.0105 of fee | US$ 0.0272 | US$ 27.17 |
| Self-host, 300 tasks per hour, search in the API | US$ 0.0667 of node plus US$ 0.0105 of fee | US$ 0.0772 | US$ 77.17 |
| Self-host indifference point, 1,073 tasks per hour | US$ 0.0186 of node plus US$ 0.0105 of fee | US$ 0.0291 | US$ 29.15 |
In the two self-host lines, the column carries the total cost of the route, with the fee included when search stays in the API, and not the operational cost of the node: they are numbers for a saturated node, without idleness, without redundancy and without on-call. At 1,200 tasks per hour, the best case in the table, self-host beats the API by 7%. The last line is not a route and should not be read as one: it marks the point where the node cost ties the total API cost, which is where the decision to migrate begins to exist.
Three assumptions move the result more than the others.
If the cache hit falls from 90% to zero, input starts to cost US$ 0.036 and the total goes to US$ 0.0609, a little more than double. The cache hit is the most fragile assumption in the bill: it depends on the agent reusing context between turns, and a flow that rewrites the prompt at every step does not reuse it.
Two things sit outside P2 and push the cost up. If the provider charges a premium to write the cache, the first turn of each prefix costs more than the full input price; and the cache has a TTL, which this analysis does not model. With 8 turns and long pauses between them, part of the prefix may expire and go back to full price. The cache read price is also a third-party reading: the US$ 0.006 per 1M come from Artificial Analysis, not from an official DeepSeek table confirmed up to 2026-10-20.
If output doubles to 24K tokens, the total goes to US$ 0.0435. If the tool calls double to 28, the total goes to US$ 0.0396. A task with no tool call costs US$ 0.0186, the same number as the free Search and Fetch window. The new fee does not change the bill of whoever does not use search, and most code flows do.
When self-host closes the bill
The bill for your own node only closes with the search fee added, because the API does not stop charging for the tool when the model leaves it. Ignoring that share gives 687 tasks per hour. Adding the US$ 0.0105 of Search and Fetch, at US$ 20 per hour of node, the crossing sits at about 1,073 tasks per hour.
The formula has two terms, and the second is the one that usually disappears from the bill. Cost per task on your own node is the node cost per hour divided by the tasks it delivers per hour, plus the Search and Fetch fee when search stays in the DeepSeek API. The balance against the US$ 0.0291 of the API appears when US$ 0.018648 are left for the node after paying US$ 0.0105 of fee, and at US$ 20 per hour that requires 1,072.5 tasks per hour.
The comparison that ignores the fee finds a point where the node, alone, costs the same as the whole API. That is not the point where self-host ties with the API, because search keeps being charged on both sides. The bar rises 56%. If self-host also replaces search, the cost of an own search stack enters, today zero in this bill, and the crossing rises further.
The US$ 20 per hour are for a node of 8 GPUs, and the assumption comes from the repository: the reference inference runs torchrun with tensor parallel 8, which spreads the model across eight accelerators. It is a node price in an aggressive band, plausible for this class of hardware, and not a GPU-hour price. If the reader reads the US$ 20 as a GPU-hour price, the 8-GPU node costs US$ 160 per hour and the crossing leaves the low thousands for the high thousands: 8.6 thousand tasks per hour when the fee enters the bill, 5.5 thousand in the generous reading that ignores it. It is the same calculation in different units, and this analysis fixes its own. A node of 8 GPUs at US$ 20 per hour, with the price as the reader's variable.
Sustaining 1,072.5 tasks per hour, 24 hours a day, is the problem. At 12K output tokens per task, a saturated stream delivers about 65 tasks per hour, so the balance asks for some 17 streams in parallel, with no pause for prefill, no tool wait and no overnight valley.
The 216.5 tokens per second from Artificial Analysis are single-stream, and single-stream tok/s is not capacity in either direction. Under continuous batching, the per-stream rate falls and the aggregate rate of the node can be several times higher, so 17 streams never reach 216.5 tokens per second each on the same node. Capacity is measured with a concurrency sweep, looking at aggregate throughput and p95 TTFT at the target concurrency, and none of the sources consulted publishes that sweep. Latency is the other side the price table does not show: a large API absorbs queue and manages prefix cache, while a saturated own node with 17 concurrent streams has no such slack.
Real load arrives in peaks, waits for a search return and sits idle at night, and each of those slack points pushes tasks per hour below what the hardware would deliver in theory. At 300 tasks per hour, the node delivers US$ 0.0667 and the bill closes at US$ 0.0772 with the fee, two and a half times the US$ 0.0291 of the API, and the node has become the expensive option.
Operations are missing, and the GPU does not cover them. A single node has no high availability, and real availability asks for two, which doubles the cost per task or halves the balance point. Add weight storage, egress, SRE on-call, which costs more per month than the node, and the update cycle: every new snapshot requires revalidating the inference, running a regression eval and swapping the serving, work that repeats at every release, and the Harness published two on the same day. The node cost per hour is the floor of the operational cost, not the operational cost.
There is also the serving work. The repository brings checkpoint conversion and reference inference with torchrun in tensor parallel 8, and the September announcement says that DeepSeek will work with the community on deployment options. There is no official vLLM or SGLang recipe for the 1017 in the primary sources consulted on 2026-10-20. The path exists, and it goes through inference engineering.
Sizing starts from a question the repository does not close: the metadata carries 763B parameters, and Artificial Analysis and the September announcement report 552B total with 16B active. The divergence is not reconciled in a public source, and that is why this analysis uses no parameter count in any bill. The decision to run it is one of capacity and governance before it is one of price.
What to do before October 31
Two measurements, one decision and two adjustments, all executable in one week. The goal is not to predict the November invoice, it is to know how many tool calls each of your tasks consumes today, because that number decides the order of magnitude of the increase.
- Count tool calls per task in your trace, separating Search from Fetch and counting only those that returned a result.
- Recalculate the cost per task with and without the fee using your token price and your cache hit rate, not the ones in this analysis.
- Decide whether search is in-house or third-party. High-volume public data turns the cost per call into an architecture decision, and there is a method to measure a web search benchmark for agents before signing.
- Review budget per key and per project to include the tool line, with a ceiling separate from the token one: the two grow for different reasons.
- Mark October 31, 2026, 16:00 UTC, in the price review calendar. Not November 1. And not in Brasília time without converting.
Frequently asked questions
Is the V4.1-Flash-1017 open source? The weights are published under the MIT license, on Hugging Face and on ModelScope, and MIT is an approved open-source license. What the repository does not bring is the training data.
How much does search cost after October 31? US$ 0.75 per 1,000 successful requests, billed per endpoint, with Search and Fetch counted separately. The exemption runs until October 31, at 16:00 UTC, and only for calls through server-side tools in DeepSeek Harness, in Claude Code and in Codex: a direct call to the Search and Fetch APIs is already billed per successful request. The count parameter, which defines how many results come back, does not change the price, and a request with an error is not billed.
Can I run the model in vLLM or SGLang? There is no official recipe for the 1017 in those two stacks in the primary sources consulted on 2026-10-20. The repository publishes reference inference with torchrun in tensor parallel 8, and the September announcement says that DeepSeek intends to work with the community on inference support. Self-host with those stacks is engineering work, not configuration.
Does 77.0 on DeepSWE mean the model is better than Opus 5? Not as a general claim. The number is the vendor's, measured on Mini-SWE-V2, and the technical report states RL training on heterogeneous scaffolds. On NL2Repo-Bench the same card gives 75.3 to Opus 5 against 68.2 for the 1017, the opposite direction. A single benchmark with a declared harness measures that harness.
References
- DeepSeek V4.1-Flash-1017 announcement, consulted on 2026-10-20.
- DeepSeek-V4.1-Flash-1017 repository on Hugging Face, consulted on 2026-10-20.
- Search and Fetch API guide, consulted on 2026-10-20.
- DeepSeek Harness releases, consulted on 2026-10-20.
- Artificial Analysis, DeepSeek V4.1-Flash-1017, read on 2026-10-20.
What to watch in the coming weeks
Three things: the volume of calls after October 31, whether DeepSeek publishes a serving recipe for the 1017, and whether a community-validated inference configuration appears that changes the cost of self-host.
The token price of this model is already low enough for the tool line to stop being noise. Nexforce Router does not see the 14 individual Search and Fetch calls, because a server-side tool runs inside the provider's API: the gateway sees a chat completions request and, at most, the usage the provider returns, and itemising a tool call requires that this usage carry the count, or that the client uses tool calling on its side. What the Router guarantees is control around the model call: one API and one key for several models, routing by cost, performance, latency and context, failover between providers, budget per key and per project, and a trace of every model call. Counting 14 requests per task remains the work of your own trace, on the client side. Without that control, the 36% share shows up for the first time in the closed invoice, when there is nothing left to decide.
Published on 2026-10-20. Prices, benchmarks and latencies with a reading date of 2026-10-20, subject to change by the vendor.

Accelerate your company'sbusiness and operational efficiency
We design the technology of tomorrow to boost your business operational scale
Talk to a SpecialistRelated articles

LiquidAI LFM2.5-24B-A2B: on-device reasoning with 2B active params
Liquid AI has opened the weights of LFM2.5-24B-A2B, a MoE reasoning model with 24B total parameters, 2B active per token and a 131K context. The piece analyzes what the combination of open weights with efficient reasoning changes in the economics of agent routing and in the role of owned hardware.
Read more
Gemini 4 Argon: 1M Token Output Window Shifts Model Routing
Gemini 4 Argon arrives with a 1M token output window, $2/M input pricing, and a 95% cache discount. See how cost and routing change per task.
Read more
Meta launches Muse Wonder: what it means for LLM routing
Meta launched Muse Wonder with a 1M window. At $4.52 per task, see how dynamic routing uses its frontier coding and reasoning without wasting margin on tokens.
Read more