DeepSeek Shipped a Vision Model at Flash Prices, Then Made Weekends Off-Peak Starting Today. Your Batch Jobs Have a New Schedule.
Two things happened at DeepSeek this week that only make sense together. On 21 August the company shipped deepseek-v4-flash-vision-exp, a multimodal model priced identically to its text-only sibling. And effective 00:00 Beijing time today, 23 August, off-peak rates apply for the whole of Saturday and Sunday.
Off-peak is half of peak. If you run image work in batches, your weekend just got 50% cheaper than a Tuesday morning, and the model that does the image work costs the same per token as the one that does the text.
The pricing table, because that is the actual story
Straight from DeepSeek's pricing page, per million tokens, off-peak then peak:
v4-flash-vision-exp | v4-flash | v4-pro | |
|---|---|---|---|
| Input, cache hit | $0.007 / $0.014 | $0.007 / $0.014 | $0.022 / $0.044 |
| Input, cache miss | $0.22 / $0.44 | $0.22 / $0.44 | $0.66 / $1.32 |
| Output | $0.66 / $1.32 | $0.66 / $1.32 | $1.98 / $3.96 |
The vision model and the text model are the same price to the cent. You are not paying a multimodal premium. Images are converted to tokens based on their dimensions and billed as input tokens alongside your text, so the cost of an image is the cost of however many tokens it resolves to, at the same rate as prose.
Peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC. Everything else is off-peak, and as of today that includes all of Saturday and Sunday in Beijing time regardless of hour.
Where the weekend rule actually helps
Beijing time is UTC+8, so the weekend off-peak window runs from 16:00 UTC Friday to 16:00 UTC Sunday. That is a 48-hour block at half price, every week, and it maps almost perfectly onto the hours a solo operator is not shipping features.
The jobs that can move into it have a specific shape. They are not latency-sensitive, the input is already sitting somewhere, and nobody is waiting on the output. Concretely: backfilling alt text across an image library, OCR on a document archive, screenshot triage in a support queue that gets read on Monday anyway, generating thumbnails or descriptions for a catalogue, re-tagging assets after a taxonomy change.
The jobs that cannot move are equally specific. Anything a user triggers and waits for. Anything on a signup path. Anything where a two-day delay changes what the answer means.
If your workload is genuinely half deferrable, the weekend rule is worth more than most model-switching decisions you will make this quarter, and it costs you a cron expression rather than a rewrite.
What the model can do
DeepSeek published benchmark numbers with the release. Terminal Bench 2.1 at 83.9, NL2Repo 57.7, DeepSWE 59.3, DSBench-Hard 63.6, AutomationBench public at 25.7, ApexBench Pass@1 36.5, Agents' Last Exam 27.3, Chartography 64.3, ZeroBench Pass@5 35.0.
DeepSeek's own summary: pure-text capability is on par with the official V4-Flash, and on agent benchmarks requiring visual understanding it is "a significant leap" over V4-Flash, bringing multimodal agent capability "close to Opus-4.8."
Treat that comparison with the usual caution. These are self-reported numbers, run with DeepSeek's own harness in minimal mode at max effort with topp 0.95 and temperature 1.0. Vendor benchmarks are a claim about a configuration, not a result you will reproduce on your data. The specification is less arguable: 1M context, 384K maximum output, tool calls, JSON output, Responses API and Anthropic-format endpoints, and a concurrency limit of 2500. FIM completion is not supported on the vision model, which will matter if you were using V4-Flash for fill-in-the-middle and were planning to consolidate on one model name.
The word "exp" is doing real work
The model ID ends in -exp. DeepSeek calls it experimental in the changelog. Their own history says what that means: deepseek-chat and deepseek-reasoner were given a three-month deprecation window when V4 landed in April and were retired on schedule in July. DeepSeek-V3.2-Speciale shipped on a temporary endpoint with an expiry date literally in the hostname.
This company retires things. Not maliciously, and usually with notice, but an experimental model is not a foundation. Put it behind whatever indirection you already use for model selection so that swapping it is a config change, and do not let a customer-facing feature depend on it existing next quarter.
The part that annoys me
Time-of-day pricing is a real cost lever and I like having it. It is also a cost lever that quietly moves work onto whoever is willing to restructure their pipeline around a foreign timezone's off-peak window.
DeepSeek's peak block of 01:00 to 04:00 and 06:00 to 10:00 UTC is not aimed at me. It is aimed at demand patterns in a market I am not in. I get the discount by accident of geography for most of my working day, which is fine, and I notice that I have no visibility into whether those windows will move. They already changed once this month. The changelog on 13 August announced peak and off-peak billing effective 16:00 UTC on 16 August, and the weekend rule arrived ten days later.
Pricing that changes twice in two weeks is pricing you should not build a unit-economics model on. Use the discount, do not depend on it.
What I would actually do
Split your image jobs into two lists on paper first: triggered by a user, and not triggered by a user. Do this before touching any code, because the split is usually less even than people expect and if 90% of your volume is interactive, none of the rest matters.
For the deferrable list, move the schedule to land inside 16:00 UTC Friday to 16:00 UTC Sunday. If your queue does not support scheduled draining, a cron job that flips a flag is enough.
Then instrument the spend by window before you claim a saving. DeepSeek bills against your topped-up balance and does not break out peak versus off-peak on the invoice in a way that will tell you whether the move worked. If you cannot measure it, you have done an optimisation on faith.
And keep the model name in config. It ends in -exp.
Where this could be wrong
The strongest objection is that this is a rounding error for most people. At $0.22 per million input tokens off-peak, halving your bill saves real money only if your bill is already meaningful. If you are spending $40 a month on vision calls, restructuring a pipeline to save $20 is a bad trade against the time it costs, and the correct response to this post is to note the weekend rule and do nothing.
The second objection is on the benchmark framing. I am reporting "close to Opus-4.8" as DeepSeek's claim rather than as a finding, but even quoting it gives it more weight than a self-reported agentic score deserves. The honest version is that nobody outside DeepSeek has independently reproduced these numbers yet, and the ones that will matter to you are the ones you generate on your own inputs.
Author
Lukas
@lukcombinator