The rate card, as published
Here it is, taken straight off DeepSeek's pricing page, per million tokens. The column which matters most is the one that isn't there: there is no separate column for images.
| Meter | Off-peak | Peak |
|---|---|---|
| Input, cache hit | $0.007 | $0.014 |
| Input, cache miss | $0.22 | $0.44 |
| Output | $0.66 | $1.32 |
| Concurrency limit | 2,500 | 2,500 |
Some things worth to read off that table before anything else.
It is identical to text-only V4 Flash. Not close to. Identical. The DeepSeek V4 Flash rate card and this one is the same six numbers, so adding vision cost DeepSeek nothing on the invoice, and it costs you nothing either. Every other vendor, by comparison, treats multimodal input as a slope which rises along with pixel count.
Peak doubles everything, and peak is not your afternoon. The footnote puts peak at 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday to Friday. Which are Chinese business hours. So a support queue in Denver or Dublin spends most of its day on the cheap rate without doing anything clever at all, and that is a real piece of luck, also a slightly fragile one.
The cache-hit rate is 31x below the miss rate. That spread, $0.007 against $0.22, is bigger than the peak surcharge, and bigger than what most prompt engineering will ever get you. It is also the reason the effective price people pay looks nothing much like the list price.
What one image actually costs
The token usage rule is short enough to give in full effect. Images under roughly 384x384 total pixels get scaled up. Anything larger gets scaled down, until the total pixel count is about that of an 800x800 image. The result of it is a hard ceiling of 384 tokens per image. A 2000x2000 and a 5000x5000 image bill the same, because after the resize they are the same thing.
So the arithmetic comes out unusually boring, which is the whole point of it:
- 384 tokens at $0.22 per million = $0.00008448 per image off-peak
- That is 11,837 images per dollar off-peak, or 5,919 at peak
- Or, in the unit the docs think in, 2,604 images per million input tokens
That third number is worth to pin down, because the figure going around in the launch discussion is a different one. The most-upvoted cost comment on the Hacker News thread gets the token math right, then converts it at the wrong rate:
"400 tokens per image results in 2,500 images per dollar, if I'm not mistaken."
Round 384 up to 400 and yes, 2,500 images per million tokens is correct. Only a million input tokens costs $0.22 here, not $1. So the per-dollar figure is about 4.5x better than what the comment claims, and I have watched the 2,500 number get repeated as a per-dollar cost several times since. Build a budget off of it and you overstate your image spend by a factor of nearly five.
Cross-vendor: the flat line against five slopes
This is the table I actually wanted on the day the model shipped, so I built it out of each vendor's own published tokenization rule instead of from anybody's summary of it.
Two notes on the method, both important. The Claude figures come out of an implementation of Anthropic's documented ⌈width/28⌉ × ⌈height/28⌉ patch rule, plus its per-tier resize. I ran it against all twelve values in Anthropic's own published table and it reproduces every one of them exactly. The GPT-5.6 figures use detail: original, which on that family means no resize and no patch budget at all per OpenAI's images and vision guide. Large images therefore cost more on it than they did on the earlier models.
| Model | Input rate /1M | 1000x1000 tokens | Cost /1k images | 3840x2160 tokens | Cost /1k images |
|---|---|---|---|---|---|
| DeepSeek V4 Flash Vision Exp | $0.22 | 384 | $0.08 | 384 | $0.08 |
| GPT-5.6 Luna | $0.20 | 1,024 | $0.20 | 8,160 | $1.63 |
| Gemini 3.7 Flash | $0.75 | 1,032 | $0.77 | 1,548 | $1.16 |
| Claude Haiku 4.5 | $1.00 | 1,296 | $1.30 | 1,560 | $1.56 |
| GPT-5.6 Terra | $2.00 | 1,024 | $2.05 | 8,160 | $16.32 |
| Claude Opus 5 | $5.00 | 1,296 | $6.48 | 4,784 | $23.92 |
Read the DeepSeek row across and nothing changes on it. Read any other row across and it climbs. Which is the entire pricing thesis of this model, sitting in one visual: everyone else sells you resolution by the token, and DeepSeek sells you a fixed thumbnail.
The gaps at 4K are big enough that they are worth to state plainly. 19x on Luna, 14x on Gemini 3.7 Flash, 18x on Haiku 4.5, then 193x on Terra and 283x on Opus 5. Anthropic publishes its own per-thousand figures and they line up with mine down to the cent, so this is not a spread I have talked myself into.
Put your own screenshot size in:
Push the resolution up and only the one row holds still. Push it down instead and something more interesting starts happening. The advantage does not only narrow. It inverts.
By 800x600 the two are already level, DeepSeek on $0.084 per thousand against Luna's $0.095. Go smaller than that and DeepSeek loses. At 300x300 a thumbnail costs 4.2x more on DeepSeek than on GPT-5.6 Luna, so $0.084 against $0.020 per thousand. The reason for it is the other half of the resize rule, the half nobody ever quotes: images below roughly 384x384 get scaled up. That 384-token cap is also a 384-token floor. DeepSeek therefore charges you for detail which it invented, and not for detail you sent.
This sharpens the buying rule quite a lot. This model is cheap at high resolution and expensive at low resolution, so if the plan was to downsample your images before sending them anyway, then you are on the wrong model for it. The saving is real specifically for the people who want to throw big untouched screenshots at an API. Which is, admittedly, most people who have a screenshot problem.
Lever one: the clock
Peak doubles all three of the meters. A 2x swing across the entire bill, then, and it is available to anybody willing to care what the time is in UTC.
The windows run 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays. Note the gap in there: 04:00 to 06:00 UTC is off-peak, sat between two peak blocks, which is a slightly odd shape for scheduling around. Saturday and Sunday is all off-peak. No other major vendor prices by the clock in this way, which makes any cross-vendor comparison against a flat card such as Kimi K3 less like-for-like than it appears.
Two practical readings out of that. Running a live support queue in the Americas or Western Europe, you land off-peak nearly by default and there is nothing for you to do. Running scheduled batch work though, backfilling ticket attachments or re-tagging an archive, maybe an eval sweep, then time-shifting the job out of those peak windows is the highest-return change available to you, and it costs you one cron expression. The same window arithmetic applies right across the family, which we walked through on the DeepSeek V4 Flash pricing post and again in the V4 Flash versus V4 Pro comparison.
Worth to flag the fragility of it, though. Peak pricing did not exist on this card one month ago. It turned up with a baseline increase attached to it, and one commenter's reaction on that repricing was blunt:
"DS is dead to me after the pricing changes. Qwen 3.8 has replaced it entirely for me"
The counter-view, in the same thread, is just as direct. Both of them can be true at once:
"Even with the price hike, Deepseek V4 Flash still does this a lot better than any similarly priced model, in my experience."
Lever two: the cache
$0.007 against $0.22 is a 31x spread, and it is where the real money sits on the input side. DeepSeek does not publish aggregate hit rates, but OpenRouter does, and the telemetry there for this model shows an 88.9% weighted cache hit rate and an effective input price of $0.03073 against the $0.22 list. Output hardly budges at all: $0.6595 effective against $0.66 listed.
That asymmetry is the single most useful fact for building any cost model here. On the input side, the cache does nearly all of the work. On the output side it does none. So your bill is an output bill with a rounding error attached to it, and whatever effort you put into optimising input tokens is chasing about 4% of the total.
One caveat here which matters specifically for the images. Image tokens get billed as ordinary input tokens, so in principle they are cache-eligible. Only a screenshot that a customer has just pasted into a ticket has never been seen before, so it lands as a cache miss every single time. The cache pays off on your system prompt and your tool definitions, on retrieved knowledge, on all of the stable scaffolding. Not on the picture. If you do send the same image over and over, the Files API is free and it lets you upload once then reference a file_id afterwards, which trims upload overhead even where it cannot trim token cost. Call-level mechanics for that are in our DeepSeek V4 Flash API walkthrough.
Lever three: reasoning effort, which is the actual bill
Thinking mode is on by default on this model, and reasoning tokens bill at the output rate. Across the model's first three days on OpenRouter the traffic split came out as 25B prompt tokens, 69.6M completion tokens, and 139M reasoning tokens. So reasoning was running at roughly twice the visible answer.
Sit with that one for a second. If your cost model treats output as "how long is the reply", then you understate the output side by around 3x, and the output side is very nearly the whole bill. This is a far bigger error than anything the image cap does to your forecast in either direction. It is also the same trap we flagged on the DeepSeek V4 Flash review, and it keeps coming back in every cross-vendor comparison, including against OpenAI's API pricing and Anthropic's API pricing, where reasoning is metered differently again.
The interesting part of it is that turning thinking down might not cost you accuracy on image tasks at all. One commenter's read, which matches what I would expect from an attention budget:
"I find reasoning on any rag type request seems to increase hallucinations, probably due to the thinking tokens taking attention away from the, in this case, vision tokens."
Treat it as a hypothesis for testing and not as a finding, since it is one practitioner's impression rather than a measured result. It is cheap to test though, and if it holds on your workload then non-thinking mode becomes the rare change which cuts the bill and improves the output at once. For retrieval-shaped work, and that describes most support automation, it is the first thing I would try. Our notes on RAG versus a raw LLM and on support agent hallucinations get into why retrieval-heavy prompts behave differently to reasoning-heavy ones.
What week one actually billed for
Here is the detail which reframed the whole model for me. OpenRouter publishes the apps sending the most traffic to each model, and for the vision build that leaderboard reads:
| Rank | App | Tokens (first 3 days) |
|---|---|---|
| 1 | Claude Code | 9.58B |
| 2 | pi | 4.56B |
| 3 | Hermes Agent | 3.3B |
| 4 | DeepSeek Harness (multimodal-bridge) | 3.12B |
| 5 | omp | 1.8B |
Four out of the top five there are coding and general agent harnesses. The one explicitly multimodal client sits fourth on 3.12B tokens, so roughly 14% of the listed traffic. The money going through DeepSeek's first vision model is overwhelmingly being spent on text.
That is not any accident, and it explains a question which came up repeatedly on the launch thread:
"if this model can do everything the text-only version does (plus see images), why keep the text-only one around? Is it just cost/latency? Or is there something text-only does better?"
On price, the answer is that there is no reason. The two models cost exactly the same, and the vision build takes six of seven text agent benchmarks in DeepSeek's own table. So the pricing decision that most buyers are really making here is not "should I pay for vision", it is "should I move my text traffic onto the vision build for free". The trade gets covered in detail on the hub post on this release. Short version: you give up FIM completion, which the table lists as "Not supported" here against "Non-thinking mode only" on text V4 Flash, and you also give up any ability to pin a dated build.
On cost-per-performance instead of cost-per-token, the thread threw up a useful correction which is worth to carry:
"The DeepSWE benchmark they report (59.3%) overlaps with the confidence interval of 5.6-Sol Medium (61% +/- 2%), but likely at 1/18th the cost"
And the reply that sharpens it:
"The closer comparison would be 5.6-Luna. On DeepSWE at Xhigh it's 57% at 1/6 the cost of Sol M, on Max it's 67% at 1/3rd the cost."
1/6 is a smaller claim than 1/18, and a more honest one. Still a real advantage though, and it is the number I would take into a build-versus-buy conversation. Our DeepSeek V4 Flash versus GPT-5.6 and versus Kimi K3 comparisons run this same exercise over more benchmarks.
The cost the rate card doesn't show
If the 800x800 resize loses the detail you actually needed, then you pay twice over. Once for the failed read, then again for whatever you do about it. The obvious workaround is cropping the image into a grid and sending the pieces, and the thread priced that one honestly:
"That's going to be 2x token usage at minimum though."
2x of $0.000084 comes to $0.000169, so on pure token cost that workaround is free in any practical sense. Tiling is the same trick the open UI agents use for getting around a fixed visual budget. The cost of it is engineering. A tiling step, then a stitching step, coordinate bookkeeping, and more round trips through a model whose P99 end-to-end latency runs out to 99.94 seconds. That is the real bill for the cap, and it does not appear anywhere on the pricing page.
Which is also why no premium option exists for buying your way out of it. detail: low downsamples to 512x512, while high, original and auto all just mean "keep the original", and that then hits the same 800x800 resize anyway. There is no high-resolution mode at any price. On Claude you can pay 3x for the high-resolution tier, and on GPT-5.6 you can pay for original patches uncapped. Here, the ceiling is not a pricing tier. It is the product.
Where this lands for a support queue
I want to be concrete on the support case here, because the demand signal is on file for us rather than hypothetical. One customer, a vacation-rental support outsourcer running eesel as a Zendesk copilot, described exactly the thing which blocked them from letting the agent answer customers directly:
"Eesel is currently unable to analyze images, and our customers frequently share screenshots. Our agents are currently required to read these images and manually transfer the knowledge to Eesel."
That is a real cost today, only paid in agent minutes instead of tokens, and it is exactly the kind of manual step which quietly caps a team's ticket deflection rate.
At 11,800 images per dollar the token side of solving that rounds down to nothing. So on price alone, this model makes screenshot reading cheap enough that you stop thinking about it, whether the downstream job is ticket classification or straight first-response automation.
And the catch is the one specific thing which matters for support: the reason customers send screenshots is small text. A receipt total. An error dialog, a line inside a billing table, an order number. Those are the first casualties of any 800x800 downscale. So the cheapest vision model on the market turns out cheap precisely in the dimension a support queue needs least, and constrained in the dimension it needs most. This is not a knock on DeepSeek, who shipped an experimental build and documented the ceiling clearly. It is only a mismatch worth to name before you plan a rollout around the price.
The related buying question is that per-token model pricing is rarely the line item which decides a support budget at all, and that is the argument we ran through on AI customer service cost and again in cost per resolution.
One wrong answer, sent confidently to a customer, costs more than every image you are ever going to process. Which is the whole case for running an AI copilot first, before you let anything answer on its own.
Want the screenshot read without owning the plumbing?
If what you actually want is your helpdesk handling tickets with attachments on it, then the token rate is one line inside a much longer build. You still need retrieval over your own help centre. The escalation rules, the per-tag behaviour. And some way of knowing the thing is right before a customer ever sees it.
That last part is the one I would push on. eesel plugs into Zendesk, Freshdesk, Gorgias and the rest as an AI helpdesk agent, it trains on your past tickets and your knowledge base rather than on a generic crawl, and it lets you replay the agent over thousands of your own historical tickets and read back what it would have said, before it answers any live customer. Model prices move, as this rate card has just demonstrated twice inside one month. A dry run over your own ticket history is the part which keeps holding its value. Free to try, and pointing it at your real queue takes a few minutes.
The price-stability question
This is the part I would weigh above the sticker price, and it comes out of watching which objections actually kill deals. On sales calls the recurring one is never "that's expensive". It is "will that number still be true next year". One budget-conscious buyer we spoke with had watched a previous vendor's price more than double, and came in asking for contractual price locks, offering to pay annually just to get them.
Hold DeepSeek's card up against that standard and a few things stand out.
The rate card already moved this month. The peak surcharge is new and the baseline went up along with it. Off-peak output at $0.66 is 2.4x the $0.28 which was current before that. So any cost model built on pre-August numbers understates this model badly.
You cannot pin the build. The MODEL VERSION field reads a bare DeepSeek-V4-Flash-Vision-Exp with no date stamp on it, against DeepSeek-V4-Flash-0731 and DeepSeek-V4-Pro-0813 for the text models. On those you get to hold a known version. Here, the name you call is whatever happens to be behind it currently.
There is no self-hosted floor. Text-only V4 Flash carries MIT-licensed open weights, so any price rise there has a ceiling to it, because you can go run the thing yourself. No weights have shipped for the vision build. One commenter on the thread expects them inside a few weeks, which is plausible enough but it is not a plan. Until that happens this is a single-provider API with no failover, which OpenRouter's provider table confirms.
None of which makes the price wrong. It makes it a spot price instead of a commitment, and that is fine for experiments, awkward for anything that has a procurement cycle attached to it. If a pinnable rate is what you need, then the dated text builds, or the alternatives in our DeepSeek V4 Flash alternatives roundup, are the safer shelf.
Who should buy this at this price
Buy it if you are sending high volumes of large images where an approximate reading is enough. Document triage, chart-shaped questions, "which screen is this", visual QA over screenshots at page scale, plus agent loops which navigate by screenshot. At 11,800 images per dollar the vision cost stops being a line item at all, and nothing else on the market comes close at 4K.
Buy it for the text, honestly. Same price as V4 Flash, better on six of the seven text agent rows, and week-one traffic shows this is what people are already doing anyway. Just know that you trade away FIM and a pinnable version to get there. Our V4 Flash review covers how the text build behaves in practice.
Wait if your images carry small text which needs reading correctly, or if your workload needs a stable contracted rate, or if a single-provider dependency with no weights and no date stamp does not clear your bar. Support queues fail all three of those pretty often, which is the honest read for our own readership.
On the model-choice question sitting underneath all of this, the best model for support tickets post makes the case that retrieval quality decides the outcome far more than the model ever does. Our which LLM for support guide compares the current shortlist against that same yardstick.
If it is specifically vision that you are shopping for, the two I would look at next are Gemini's agentic vision and Qwen's UI agent. And for having this inside a helpdesk instead of at the API layer, Gorgias AI agent vision is the closest shipped equivalent to it.
The bottom line
DeepSeek V4 Flash Vision Exp is the cheapest way going to show a model a picture, by a margin which gets more absurd the bigger that picture gets. $0.08 per thousand images at any resolution, against $23.92 for the same 4K screenshot over on Claude Opus 5. The flat line is real, and the 384-token cap is documented honestly.
Only the flat line and the resolution ceiling are the same sentence read out twice, and once you accept that cap, images stop being any kind of cost lever. What is left for managing is the UTC clock, then a cache which only ever helps your prompt and never once your picture, plus a reasoning budget quietly running 2x your visible output and billing at the output rate. Get that last one wrong and you miss your forecast by more than every image you will ever send.
And I would hold the whole card fairly lightly. It changed once already this month, it names a build with no date on it, and there are no weights for falling back to. For a weekend project, that is a great deal. For a support queue that has a procurement process attached, the sticker price was never the hard part anyway, which is what our AI agent versus human cost comparison keeps finding.
Sources
Frequently Asked Questions
How much does DeepSeek V4 Flash Vision Exp cost?
How much does one image cost on DeepSeek V4 Flash Vision Exp?
Is DeepSeek V4 Flash Vision Exp cheaper than GPT-5.6 or Claude for images?
What are peak and off-peak hours for DeepSeek pricing?
Do reasoning tokens count toward DeepSeek V4 Flash Vision Exp pricing?
Does the cache discount apply to images?
Is DeepSeek V4 Flash Vision Exp pricing likely to stay the same?
DeepSeek-V4-Flash-Vision-Exp with no date stamp, unlike -0731 or -0813, so you cannot pin a build the way you can on the text models. For a production support workload that price-stability question usually matters more than the sticker, which is the argument in our AI customer service cost guide.Is DeepSeek V4 Flash Vision Exp free anywhere?
Article by
Kurnia Kharisma Agung Samiadjie
Kurnia is a software engineer and writer at eesel AI with two years of SEO experience, writing about AI tools, helpdesk software, and customer support. He pairs a developer's understanding of how these products are built with search-driven research into what actually ranks and resonates with the people searching for them.
