DeepSeek pushed out V4.1-Flash on 10 September 2026, and the headline number is the cache-hit input price: $0.003 per million tokens, off-peak. That's not a typo. If you're running any kind of high-volume AI chatbot, WhatsApp lead-response flow, or content pipeline where the same context gets reused across calls, this changes what that infrastructure costs you to run, though it also comes with a peak/off-peak pricing split that most people writing about the launch are skipping over.
At WebEpex we route every client chatbot and WhatsApp flow through a swappable model layer for exactly this reason: pricing like this moves margins, not just headlines, and we don't want a rebuild every time a lab reprices.
What did DeepSeek's V4.1-Flash pricing actually change?#
DeepSeek retired V4-Flash and V4-Flash-Vision-Exp and replaced both with a single model, deepseek-flash, built on a 552-billion-parameter mixture-of-experts architecture (up from V4-Flash's 284 billion). Off-peak, cache-hit input runs $0.003 per million tokens, cache-miss input is $0.15 per million, and output is $0.60 per million, per Dataconomy's breakdown of the release.
The company's own announcement confirms peak pricing runs double off-peak rates, and that from 14 September, deepseek-v4-pro traffic gets rerouted to V4.1-Flash entirely, billed at Flash rates. Old model IDs still work. They just point somewhere new now.
Does this affect your WhatsApp or lead-response automation?#
If you're sending under a few thousand AI-handled conversations a month, this doesn't move your bill enough to notice, and you can stop reading here. The interesting part is the peak window: Monday to Friday, 01:00–04:00 and 06:00–10:00 UTC. Convert that to Dubai time and it's 5–8am and, worse, 10am–2pm: right in the middle of a GCC working day.
That means if you're running high-volume automation (order confirmations, support triage, lead qualification) during normal UAE business hours, you're paying the peak rate by default. Running the same workload at 2am UTC instead would cost you half as much. That's a scheduling decision, not a model decision, and most teams aren't making it on purpose yet.
The honest trade-offs#
The cache-hit pricing is genuinely aggressive, and the 1M-token context plus native vision support is a real capability jump, not a marketing bump. DeepSeek says V4.1-Flash beats V4 Pro on cost, speed, and total time, and its own DeepSWE v1.1 benchmark score (74.2) edges past both Claude Opus 5 (74.0) and GPT-5.6 Sol (73.0) in their testing.
That last part is DeepSeek's own benchmark, on DeepSeek's own model. I'd treat it as a data point, not a verdict: benchmark numbers from the lab that built the model always deserve a squint. The bigger open question, honestly, is how the cache-hit discount holds up once you're not hand-tuning your prompt structure to maximize cache reuse. Most teams won't bother, and the real-world price will land somewhere between the headline number and the cache-miss rate.
It's worth putting this next to the GLM-5.3-Flash price increase we wrote about last week. One model got cheaper, one got pricier, in the same month, on the same kind of workload. That's the actual state of the market right now: not a steady march downward, just constant repricing you need to be watching.
| Rate type | Price (off-peak) | Price (peak) |
|---|---|---|
| Input, cache-hit | $0.003 / M tokens | $0.006 / M tokens |
| Input, cache-miss | $0.15 / M tokens | $0.30 / M tokens |
| Output | $0.60 / M tokens | $1.20 / M tokens |
How we're handling it at WebEpex#
We build WhatsApp and voice automation for GCC and Indian SMBs, and every flow we ship routes its model calls through a config node in the n8n workflows underneath, specifically so we can swap the backend without touching the automation logic itself, a decision that's paying off again this week. We pulled two live client flows and ran them against V4.1-Flash's off-peak window this week, comparing output quality against the model each was already running on.
We rebuilt the retry logic on one of them before we even touched the model swap, because timeout handling matters more than which LLM sits behind it. Learned that one the expensive way, on a different client, a different year. Once that held up, we shifted the client's nightly WhatsApp catalog-sync job, the one part of that flow that's genuinely high-volume and genuinely latency-tolerant, into the off-peak window. Everything customer-facing stays on whichever model tests best for response quality, peak pricing or not. My read: for anything a customer is waiting on, cost isn't the variable you optimize first.
What I'd tell a client asking about this#
If you're under a few thousand AI conversations a month, do nothing. Genuinely, this isn't your problem yet. If you're above that and you have any batch job (sync jobs, report generation, catalog updates, nightly summaries) that doesn't need to run during business hours, move it to the off-peak window this week. That's a config change, not a rebuild. Don't touch your customer-facing flows for pricing reasons alone; test them on quality first, and let cost be the tiebreaker.
If you're trying to work out whether any of this actually hits your setup, send me what you're running and I'll tell you straight: takes two minutes, no pitch attached. cal.com/webepex/growth-review
