Shorter outputs, same price: what DeepSeek V4.1-Flash-1017 changes in an agent's bill

TL;DR

DeepSeek released V4.1-Flash-1017 on 2026-10-17 as an MIT-licensed update to V4.1-Flash. The model card reports gains on all 11 listed benchmarks, between 2.0 and 11.1 points, and says the model also finishes tasks faster with shorter output. The API price did not change: $0.15 per million uncached input tokens, $0.003 per million cached input tokens and $0.60 per million output tokens off-peak, doubled during peak hours.

The interesting question is not the score table. It is what "shorter output at the same price" does to the cost of a whole agent task. My findings, using the model card, the live pricing page and a small cost model:

1. The score gains are real on the vendor's own table, but the vendor ran them. The model beats Claude Opus 5 on 4 of 11 listed benchmarks and trails it on 7.
2. A 30 percent cut in reply length saves about 22 percent on an illustrative 30-turn task, not 30 percent, because input tokens are billed too.
3. Turn count matters more than reply length. Context is re-read every turn, so cost grows faster than linearly with the number of turns. Finishing in fewer turns is where large savings come from.
4. Three billing details can quietly erase the savings: peak hours (35 of 168 hours each week), a cache that stops hitting (6 times the cost in my model) and old model names that now silently point at the new model.

What actually shipped in V4.1-Flash-1017?

The model card describes it as "a minor update" to V4.1-Flash, with improvements across reasoning, coding, agentic tasks and visual benchmarks, plus reduced task execution time and output length. The checkpoint is public on Hugging Face under the MIT license. At the time of writing the repository shows 42,122 downloads and 2,103 likes.

From the public config.json, the architecture is a mixture of experts with these numbers:

The API serves it as deepseek-flash. The pricing page also says the older names deepseek-v4-flash and deepseek-v4-flash-vision-exp are still accepted, but the models behind them are retired and their requests are served by V4.1-Flash-1017 at the Flash price. If you pinned one of those names and never re-ran your evaluation, you are already on the new model.

Did the benchmark gains hold up against other models?

All numbers below come from the model card table. They are vendor-reported, and the card names the harnesses it used: the Claude Code harness for Terminal-Bench 4.0 and the Mini-SWE-V2 harness for DeepSWE v1.1.

I counted wins from the card's own rows. The new model scores higher than the previous Flash build on all 11 benchmarks, with a mean gain of 5.2 points. Against the other models in the table:

The four benchmarks where it is ahead of Opus 5 are DeepSWE v1.1 (77.0 vs 74.0), Automation-Bench (60.5 vs 50.3), Agents' Last Exam (35.4 vs 28.6) and Apex Bench v1.1 (72.1 vs 65.8). That pattern is an agentic-coding and tool-use profile, not a general-knowledge one. On HLE the gap to Opus 5 is 13.7 points.

One row deserves a caution. Kimi K3 scores 12.6 on Terminal-Bench 4.0, while the other three comparison models land between 37.9 and 51.8. A spread that wide on one benchmark often points to harness sensitivity rather than a pure capability gap. That is my inference, not something the card says, but it is a reason not to read the Terminal-Bench column as a clean ranking.

What does "same price, shorter output" mean for one task?

Here is the published price list, per million tokens, from the DeepSeek pricing page:

Pro costs 7.3 times as much on cached input, 4.4 times on uncached input and 3.3 times on output, computed from the table. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday to Friday, excluding Chinese public holidays. That is 35 of the 168 hours in a week, or 20.8 percent. Everything else is half price.

To see how output length feeds into a bill, I built a deliberately simple agent loop. It is illustrative, not a measurement of any real workload:

• 30 turns per task
• an 8,000-token initial prompt
• 2,000 tokens of tool output appended each turn
• the whole conversation re-sent every turn, with the earlier part served from cache and only the newly appended tokens billed as uncached

def loop(turns, init, tool, out):
    ctx = init
    hit = 0
    miss = init
    for t in range(1, turns):
        hit += ctx            # prefix served from cache
        new = tool + out      # newly appended tokens, uncached
        miss += new
        ctx += new
    return hit, miss, out * turns

FLASH_OFFPEAK = dict(hit=0.003, miss=0.15, out=0.60)  # USD per 1M tokens

def cost(hit, miss, out, p):
    return (hit * p["hit"] + miss * p["miss"] + out * p["out"]) / 1e6

With replies averaging 1,500 tokens the task reads 1.65 million cached tokens, 109,500 uncached tokens and writes 45,000 tokens. At off-peak Flash prices that is $0.048, split roughly 10 percent cached input, 34 percent uncached input and 56 percent output. Cut the reply length by 30 percent to 1,050 tokens and the total falls to $0.038, a saving of 21.9 percent. The saving is smaller than the 30 percent reply cut because input tokens are still billed, and shorter replies shrink the context only a little.

At peak prices both numbers simply double ($0.097 and $0.076). The same token counts at Pro off-peak prices come to $0.198 for the longer replies, about 4.1 times the Flash figure. Real Pro runs would use different token counts, so treat that ratio as price-only.

Why does the number of turns matter more than reply length?

Every turn re-reads the whole conversation so far. Cached tokens are cheap, but there are many of them, and the cached part of the bill grows with the square of the turn count.

Using the same model, off-peak Flash:

Going from a 30-turn task with long replies to a 24-turn task with short replies costs 61 percent of the baseline. At 18 turns it is 45 percent, and at 12 turns it is 30 percent. This is a toy model, so the exact percentages will not transfer, but the direction does: a model that solves the same task in fewer tool calls saves more than one that merely writes less per call.

That is consistent with a secondary report. The Decoder wrote that the new model reaches its top DeepSWE score at "just under $0.20 per task", about $0.10 in a lower-cost setting that still clears 72 percent, and that the previous build cost "around $0.50 per run". It also says competing models land between $2 and over $10 per task. Those are the outlet's figures, the model card does not publish per-task cost, and I could not find token counts behind them. A drop from about $0.50 to about $0.20 is far larger than the 22 percent my reply-length model produces, which suggests most of the real saving comes from shorter trajectories rather than shorter sentences. It also suggests real benchmark runs are much bigger than my toy task, since $0.20 at these prices is about four times my 30-turn figure. Which of those is true for your workload is something only your logs can tell you.

What can quietly raise the bill?

Cache misses. My model assumes about 94 percent of input tokens hit the cache, which is what a clean append-only conversation gives. Forcing the hit rate down shows how sensitive the result is:

With no cache at all the same task costs about 6 times as much. Anything that edits the middle of the conversation, such as rewriting an earlier tool result, injecting a changing timestamp near the top of the prompt or reordering messages, can break the prefix and move you down this table.

Peak hours. If a nightly batch job runs at 08:00 UTC on a weekday, you pay double. Weekend and off-peak slots are half price, so a queue that can wait is a direct 50 percent discount. Check the Chinese public holiday calendar too, since those days are off-peak in full.

Thinking mode. The pricing page says the model supports thinking and non-thinking modes and that thinking is the default. Reasoning tokens are output tokens. The model card recommends max_tokens of at least 256K, and the API allows up to 384K output. A permissive limit is safe for quality but gives you no ceiling on a runaway generation, so set your own per-task budget.

Search and Fetch. DeepSeek's standalone Search and Fetch APIs are billed per request, with Search at $0.75 per 1,000 successful requests, and press reports say server-side tool use is free until the end of October. An agent that searches heavily will see a new line item in November.

Can you run it yourself?

The repository is 510.3 GB, so the weights alone are a multi-GPU job. Split evenly across 8 GPUs that is 63.8 GB per card, which leaves about 16.2 GB per 80 GB card for KV cache and activations before any replication overhead. On 141 GB cards the headroom is about 77 GB per card. That is a back-of-envelope figure, not a deployment guide, and real engines replicate some tensors.

One detail in the Hugging Face metadata is worth knowing. It lists 763.2 billion parameters, but 204.0 billion are FP8 (1 byte each) and 557.2 billion are labeled int8. If every one of those were one byte the files would total about 765 GB, yet the repository is 510.3 GB. Counting the int8 entries as packed 4-bit values, two per byte, gives about 487 GB for the weights, which fits the observed size once you add scales and auxiliary files. So the 763.2 billion headline is a count of values, and the on-disk footprint is closer to a 500 GB model. This matches the FP4 expert setting in the config, though the card does not spell out the packing.

The card also notes that there is no Jinja chat template. Prompt formatting comes from a reference encoding.py and the separate deepseek-recipe libraries, so a serving stack that expects a standard template needs that piece wired in. The API changelog recommends DeepSeek Harness 0.2.1-rc.1 or later.

How should you test it on your own workload?

1. Re-run your evaluation against deepseek-flash now, especially if you used a legacy model name.
2. Log, per task: turns, input tokens split into cache hit and miss, output tokens and wall-clock time. The API usage object reports cache hit and miss counts, so check the current field names in the docs.
3. Compare cost per solved task, not cost per token. A cheaper model that solves fewer tasks loses.
4. Put a hard budget on turns and on output tokens per task.
5. Schedule queue-tolerant work in off-peak hours.
6. Keep prompts append-only so the cache keeps hitting.

FAQ

Is DeepSeek V4.1-Flash-1017 open source? The weights and repository are under the MIT license, according to the model card. The card does not mention training data or training code.

Did the API price change with this update? No. The pricing page lists the same Flash rates, and press coverage confirms unchanged pricing. What changed is that peak hours cost double and off-peak hours cost half.

Does the model beat Claude Opus 5? On the model card it is ahead on 4 of 11 listed benchmarks, including DeepSWE v1.1 (77.0 vs 74.0), and behind on 7. These are vendor-reported numbers.

How much cheaper is a task than before? The model card does not give a per-task figure. A secondary report cites about $0.50 down to just under $0.20 on DeepSWE. My illustrative model shows 22 percent from shorter replies alone and larger gains only if the number of turns also drops.

Can I run it on a single GPU? No. The repository is 510.3 GB, so you need a multi-GPU node or a heavily quantized community build.

Method and caveats

• Benchmark numbers and harness names come from the model card. I did not run any benchmark.
• Prices come from the DeepSeek pricing page as fetched on 2026-10-22. Prices and peak windows can change.
• The agent-loop cost model is illustrative. Its turn count, prompt size, tool output size and reply length are my assumptions, not measurements. The per-turn accounting treats each turn's tool output and the previous reply as the new uncached tokens.
• Per-task dollar figures from The Decoder are secondary and unverified. The article gives no token counts.
• The "packed 4-bit" reading of the int8 count is my inference from file sizes.
• Memory headroom assumes an even split and ignores replicated tensors and engine overhead.

Sources

• Hugging Face: deepseek-ai/DeepSeek-V4.1-Flash-1017 model card
• Hugging Face: config.json for the same repository
• DeepSeek API docs: Models and Pricing
• DeepSeek API docs: Change Log
• The Decoder: Deepseek V4.1 Flash 1017 beats larger rivals in agentic tasks while once again massively cutting per-task costs
• TBreak: DeepSeek ships V4.1-Flash-1017, a faster update with shorter outputs

Further reading

• Default-to-Flagship Is Now a Cost Bug: Tiered Model Routing for Agentic Workloads
• Can two Mac Studios really run an 816B model? A bandwidth roofline check on Muse Spark Open