DeepSeek V4.1 Flash is easy to misread. The headline is that a 552B open-weight model is now available for $0.15 per million input tokens off-peak and $0.60 per million output tokens. The more useful news is operational: DeepSeek is changing the API underneath existing users, and it is betting that a smaller working cache can make long-running agents cheaper to serve.

DeepSeek V4.1 Flash off-peak API price comparison

If you use the DeepSeek API, the safe decision is to test deepseek-flash now, not to wait for a forced migration. If you run coding agents in automatic mode, keep a human approval boundary until you have tested how much reasoning the model spends and how it behaves around shell commands.

The cost model changes on September 14

V4.1 Flash launched on September 10. DeepSeek says the new API identifier is deepseek-flash. The older deepseek-v4-flash and deepseek-v4-flash-vision-exp identifiers temporarily route to the new model for compatibility. At 04:00 UTC on September 14, every request sent to deepseek-v4-pro will also route to V4.1 Flash and receive Flash pricing until V4.1 Pro arrives.

That is a product change, not a normal model upgrade. A pinned endpoint no longer guarantees a pinned model. If your evaluation, logging, or compliance process assumes that deepseek-v4-pro means the same weights tomorrow, that assumption is already wrong.

DeepSeek's off-peak rates are $0.003 per million tokens for a cache hit, $0.15 for a cache miss, and $0.60 for output. Peak rates are double those numbers. Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays, according to the pricing documentation.

Here is a simple workload calculation. Suppose a batch agent sends 100 million input tokens, with 70 percent served from cache, and generates 10 million output tokens. At the new off-peak rates, the bill is $0.21 for cache hits, $4.50 for cache misses, and $6 for output, or $10.71 total. At peak rates, the same run costs $21.42. The output bill dominates, so reducing needless reasoning and retries matters more than obsessing over the last fraction of a cent in cache reads.

The old V4 Flash off-peak rates in DeepSeek's pricing table were $0.007 for cache hits, $0.22 for cache misses, and $0.66 for output. The new prices cut those line items by about 57 percent, 32 percent, and 9 percent. That is a real reduction, but it is not a uniform discount. Teams with large repeated prompts get the biggest benefit from cache-hit pricing. Teams that make the model produce long reasoning traces will still pay for every generated token.

For a migration, log four values for a representative week: input tokens, cache-hit share, output tokens, and successful task count. Divide total spend by successful tasks. A cheaper token is useless if the new model creates enough retries to erase the saving.

Why the cache number matters more than 552B

The model has 552B backbone parameters and a Causal Encoder-Decoder design. DeepSeek reports 8B active parameters during prefill and 16B during decoding. That asymmetry fits agent workloads: the system reads a large history, then generates a smaller stream of actions and explanations.

The technical report gives the number that affects long sessions: 890 bytes of global KV cache per token. That is roughly one-quarter of V4 Flash's corresponding footprint. A separate SWA Bounded Replay system reduces the persistent cache footprint to roughly one-eighth of V4 Flash. The report attributes the reduction to Compressed Sparse Attention 2, cross-layer reuse, and FP4 KV caching.

This does not make the model a laptop model. The Hugging Face release is MIT licensed, but the checkpoint is still a large deployment. DeepSeek's own release page asks teams with 2,000 GPUs and a storage cluster to discuss large-scale deployment. Open weights are useful for control and future hosting options; they are not proof that a normal workstation can serve this checkpoint.

The cache design is aimed at the boring part of agent economics: the same repository context, tool history, and task state being read again and again. In that setting, memory traffic and cache storage can decide whether a system stays responsive. A small cache does not remove the cost of a long answer, but it gives the serving stack less state to move and retain.

The model card also makes the setup easy to overread. It documents vLLM and SGLang paths, but support for a new architecture can lag behind the weights. Before committing to self-hosting, confirm the exact engine version and run a full context-length test. The official release does not promise that every local inference stack is ready on day one.

Where the cheap route breaks

Community testing is more mixed than the release copy. A recent r/opencodeCLI discussion describes very fast coding work and good instruction following, but also says the model can overthink, work inline instead of delegating, and become unsafe when left in automatic mode. Another Reddit discussion in r/singularity praises the 8B prefill and 16B decode profile, while several comments question whether benchmark tables reflect messy real-world work. That skepticism is healthy. A benchmark result tells you what a harness measured, not whether your repository workflow will behave the same way.

The official model card reports 90.6 on Terminal-Bench 2.1 with the DSH Standard setup and 74.2 resolved on DeepSWE v1.1. Those numbers are useful for comparing agent scaffolds, but they are not a deployment guarantee. The evaluations use specific temperatures, context limits, sample counts, and harnesses. The model card says Terminal-Bench 2.1 runs without network access. Your production agent probably does not.

Artificial Analysis reports a score of 40 on its Intelligence Index for the max-reasoning configuration, 190.1 output tokens per second, and a 1.00 second time to first token based on DeepSeek API measurements. It also reports that the evaluation generated 250 million output tokens. That last number is the warning label. Strong capability at $1.20 per million peak output tokens can still become an expensive workflow when the model thinks for too long.

I would split the rollout by task. Move high-volume classification, extraction, repository search, test drafting, and repetitive code changes first. Keep security-sensitive changes, production shell access, migrations, and unfamiliar code behind approval. Give the agent a fixed budget and record retries. If the same task succeeds with less output and no extra repair loop, the savings are real. If it writes twice as much reasoning and needs a human to undo more mistakes, the price table is lying by omission.

A minimal migration test needs only a small fixture: ten normal tasks from your existing workload, two long-context tasks, one tool-calling task, and one task designed to fail safely. Run the old endpoint and deepseek-flash with the same prompts, tools, limits, and timeout. Compare successful completion, total output tokens, wall-clock time, and manual repair time. Do not replace your provider-wide default from a single impressive answer.

The strongest reason to switch is not that DeepSeek says Flash beats Pro. It is that the API is moving there anyway, and the new model gives you a cheaper baseline with native image input and a much smaller reported cache footprint. The strongest reason to wait is a workload that depends on predictable reasoning length or broad local-engine support. For most API users, the sensible move is a controlled migration. For unattended coding agents, cheap is not the same as safe.

Sources