DeepSeek V4 Flash Vision Exp: same price, one big catch

What DeepSeek actually shipped

The release is three things at once, and only one of them really got the headlines.

A vision model. deepseek-v4-flash-vision-exp takes images in the same request as your text, through Chat Completions, the Anthropic-compatible /messages endpoint, or else the Responses API. Supported formats are JPEG, PNG, GIF and WebP, and per the vision guide the format gets sniffed from the file contents, not from the filename or the declared MIME type.

A free Files API. You upload an image once, then reference it by file_id across requests. It also lifts the per-image ceiling from 32 MiB up to 64 MiB, which matters more than it sounds like it should.

A harness release. DeepSeek Harness 0.1.1 landed on the same day, with support already built in.

In terms of architecture nothing changed from the model it forks, a sparse mixture-of-experts with 13B active parameters out of 284B total, per OpenRouter's model page. Context stays on 1M tokens, max output at 384K, and concurrency at 2,500. If you already built against DeepSeek V4 Flash, then swapping the model string is the entire migration.

One detail that reads like a footnote but is not: images are accepted in user messages only. Put one into a system or assistant message and you get back a 400. If your agent loop stuffs tool output into an assistant turn, that is a rewrite for you, not a config change.

The 384-token cap is the whole design

This is the part worth to understand before you plan anything around the model.

Before inference, DeepSeek resizes every image that comes in. Anything under roughly 384 by 384 pixels gets scaled up, aspect ratio preserved. Anything bigger goes down, aspect ratio preserved again, until the total pixel count sits roughly at what an 800 by 800 image would be. The result is a hard ceiling of 384 tokens per image, and the docs spell the consequence out plainly: a 2000 by 2000 image and a 5000 by 5000 image consume the same number of tokens.

So images come out almost free. On the off-peak rate of $0.22 per million input tokens, 384 tokens costs about $0.00008. A commenter on Hacker News did the arithmetic and arrived on roughly the same place:

"400 tokens per image results in 2,500 images per dollar, if I'm not mistaken."

ciberado, Hacker News

They were right, and the number is worth sitting with for a second. At that rate the cost of looking just rounds to nothing inside almost any agent budget.

But the price and the resolution here are one single decision, not two of them. It is cheap because it looks less closely. The sharpest reaction in that whole thread ran three words:

"Oof 800 by 800 kills a lot of use cases"

knollimar, Hacker News

That is fair, and the thread then spent a long while arguing over how much it actually matters. The workaround people settled on is a crop-and-zoom tool: you give the model an ability to request some sub-region of a high-resolution image, so it reads a 600 by 600 crop at native detail rather than the whole thing blurred. Several people reported this working well for them. Others pointed at the obvious limit, which is that stitching nine crops back into one spatial understanding is its own hard problem, and counting things or tracing relationships across a schematic is exactly where it breaks down.

Both camps are right, only about different workloads. Checking whether a button rendered in the right place survives a downscale to 800 by 800 easily enough. Reading 8pt text off a receipt does not.

There is also a detail parameter, worth knowing mostly for the thing it does not do. low downscales to 512 by 512 for the speed. high, original and auto all currently mean one same thing, which is keep the original and then apply the standard resize anyway. No high-resolution mode exists for you to reach for.

The benchmark table says more than the announcement

DeepSeek's release note describes the text side of the vision model with one word, it "matches" V4-Flash. The table they published alongside it does not quite say that.

Line them up across the text-based agent rows, and the vision build takes six of the seven:

DeepSWE moves 4.9 points and Toolathlon-Verified moves 5.6. Those are not rounding errors. On DeepSWE the vision variant also edges past Opus-4.8, 59.3 against 58.0. "Matches on text" undersells what DeepSeek's own harness measured here, and if you are picking a coding or tool-use model off these rows, the vision build is the better choice even when you never send it a single image.

Now the multimodal half, where the framing wants a second look:

*DeepSeek's own footnote: on ApexBench and Agents' Last Exam, the text-based V4-Flash ignores the multimodal elements in the task.

That footnote is doing a lot of the work. The "major leap over V4-Flash" on multimodal agent benchmarks is partly just measuring that one model can see and the other one cannot, which is true enough but is not the same thing as a capability gain. The honest comparison sits in the Opus-4.8 column, and there the picture is close: DeepSeek trails by 2.9 on ApexBench, 0.7 on Chartography, then edges ahead on Agents' Last Exam and on ZeroBench. "Close to Opus-4.8" is a fair claim, and for a model at a fraction of Anthropic's API pricing that is really the headline.

Two caveats, to keep the reading straight. All the DeepSeek-series numbers come out of DeepSeek Harness Minimal Mode at top_p=0.95 and temperature=1.0, which is the vendor's own scaffolding. Also these are launch-day figures from the vendor and not an independent replication. Treat them how you would treat any first-party table, ours included.

What it actually costs

The rate card is identical to plain V4-Flash, which is probably the single most useful fact in the whole release. Off-peak, per million tokens: $0.007 on a cache hit, $0.22 on a cache miss, and $0.66 out. Peak doubles all of the three. Peak hours run 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, which means a US or EU workload mostly bills on the cheaper rate by pure accident of geography.

The sticker price is also not the thing most people actually pay. OpenRouter's own telemetry puts the effective input price at $0.03073 per million against a listed $0.22, because the observed cache hit rate is running up at 88.9%. Output barely moves at all, $0.6595 effective against the $0.66 listed. So in terms of where the money goes, the cache does nearly all the work on the input side and none whatsoever on the output side, which makes your bill an output-token bill with a rounding error attached.

Plug your own numbers into it:

Run a realistic screenshot-driven agent through that and the shape holds up: images barely register, the bill is output tokens. Which brings up one number worth to flag. Across its first three days on OpenRouter the model burned 25B prompt tokens, 69.6M completion tokens, and 139M reasoning tokens, so reasoning is running at roughly twice the completion. Thinking mode is on by default and reasoning tokens bill at the output rate. So if your cost model treats output as "the length of the answer", it is off by something like 3x. The same trap shows up in our DeepSeek V4 Flash pricing breakdown, and it is a fair chunk of why comparing raw rate cards across vendors misleads so badly. Anyone who priced OpenAI's API against a per-resolution support tool has met the same problem coming from the other direction.

The limits that will actually bite you

Most of these are generous ones. Two of them are not.

Six hundred images inside one request is a lot of headroom. But notice the dimension rule quietly halving itself once a request carries fifteen or more images, which is exactly the shape of a batch document-processing job. And that 60-second download window on external URLs is the kind of thing which works perfectly in testing, then starts throwing intermittent failures the first time you point it at some slow customer CDN. If images matter for your pipeline, the Files API is the safer default and not the optimisation you get around to later.

What you give up

Two things, and neither of them sits in the announcement's bullet list.

FIM completion is not supported. Plain V4-Flash and V4-Pro both offer fill-in-the-middle in non-thinking mode, while the pricing page marks it "Not supported" for the vision build. So if you use FIM for inline code completion, this model cannot be a drop-in replacement for you, and that is the one hard blocker in the release.

There is no build date. This one is subtler, and it is the reason I would not be moving production traffic across yet. Look at how the price card names its versions: plain Flash is DeepSeek-V4-Flash-0731, Pro is DeepSeek-V4-Pro-0813, and then the vision build is just DeepSeek-V4-Flash-Vision-Exp. A dated build is a build which you can reason about. An exp label carrying no stamp is a moving target, and one Hacker News commenter read the roadmap in the same way:

"most likely a preview. they often release the preview via API, get more training data, post train some more then release the weight. i would expect to see it perform better in a few weeks or a month."

segmondy, Hacker News

If that is right then the numbers in this post carry a shelf life, and so does whatever eval you run this week. Which is a normal cost of using experimental endpoints. It only becomes a problem if you forget that you accepted it.

What the first 72 hours of real traffic show

Vendor benchmarks are one thing. Here is what the routing layer itself measured, per OpenRouter, across the model's first three days.

• 85 tokens/second at P50 throughput, with a P50 latency of 1.11 seconds.
• 1.27% tool-call error rate. For a model whose entire pitch is multimodal agent work, this is the number I would check first, and it is fine.
• 100% uptime, 99.93% availability, out of a single provider. DeepSeek serves it directly, so no failover exists to route around.
• 90.4% cache hit rate, which is the thing dragging effective input pricing down to about a seventh of list.

The tail is worth a glance, though. P99 latency comes in at 18.34 seconds, and P99 end-to-end at 99.94 seconds. Which is a fine distribution for a batch job, and a rough one for anything a person sits waiting on, the same tradeoff you weigh up with any AI agent placed in front of a customer.

The traffic mix is the most interesting part of it. The top consumers are all coding harnesses: Claude Code on 9.58B tokens, pi on 4.56B, Hermes Agent on 3.3B, plus DeepSeek's own multimodal-bridge harness at 3.12B. Nobody is running this as a chat model. They point it at codebases and at screens, which lines up neatly with those six-of-seven text benchmark wins.

One more piece of context on why a cheap vision model landed so hard here. Plain V4-Flash apparently spent months pretending that it could see:

"It tried to recreate vision by analyzing pixels on 3 separate projects I had it working on."

VulgarExigency, Hacker News

Another commenter described how they had to tell 0731 to stop opening screenshots, because the attempts kept breaking sessions. Against that baseline a model which simply looks at the image is a real upgrade, even a blurry one.

Who should use it, and who should wait

Use it now if you run agent loops over screens and codebases, you were already sitting on V4-Flash, and you do not depend on FIM. The text benchmarks on their own justify the model-string swap, and then the vision is upside. Batch document work fits too, so long as you checked your own documents against the resize first.

Wait if you need a pinned build, or you need FIM, or your images depend on fine detail. Analog dials, dense schematics, small print sitting on receipts: test all of those before planning around them. The clock-reading argument that ran through the Hacker News thread illustrates well how noisy single-shot vision judgments really are, since one commenter's failure turned into 9-out-of-10 correct once somebody else ran it ten times, which prompted a line every one of us should tape onto a monitor:

"Lesson learned to double check what I read on the internet."

bel8, Hacker News

Think harder if you are pointing this at a support queue. Customer screenshots are among the highest-value inputs in support, and also the worst possible fit for an 800 by 800 ceiling, because the whole reason a customer sends a screenshot is the small text inside it. Read our notes on choosing a support model and on which LLM fits support before wiring a raw model into any live queue.

eesel for support queues that are full of screenshots

I want to be precise on what this model solves for a support team, because we have the demand signal sitting on file. One customer, a vacation-rental support outsourcer running eesel as a Zendesk copilot, told us plainly what blocked them from going fully autonomous:

"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 unmet need, and a model like this one is what eventually closes it. But it is worth to be clear on which half a vision model actually closes. Reading the pixels is the easy half. Producing a correct, in-policy answer off the back of them is the hard half, and it is also the half which has burned everyone who ever shipped AI support.

We have watched a confident-sounding bot quietly tell customers that we supported car models which we did not, because the knowledge base said "we support all models" and the bot took that literally. This was a telematics team on Zendesk, running around 200 tickets a month. Nothing about a vision encoder fixes that particular failure. What fixes it is grounding the agent in your real history, then proving the behaviour out before any customer meets it, which is why every eesel rollout gets replayed against past tickets first and scoped down to one ticket type at a time.

So if you are evaluating DeepSeek's vision model because your queue is full of screenshots, then run the two tests in the right order. First, whether the model can read your actual images once they are resized. Second, and this one matters more, whether the answer it gives back is one you would have sent yourself. eesel handles that second test by simulating on your ticket history before go-live, billing per ticket instead of per seat, and routing anything under your confidence bar over to a human. Try eesel free, or book a walkthrough on your own tickets.

Where this sits in the DeepSeek lineup

If you are mapping out the family, the short version is this: deepseek-v4-flash-vision-exp is a fork of the 0731 Flash build, with a vision encoder bolted on and FIM taken out. It is not a Pro-tier model, and it does not replace anything.

• DeepSeek V4 Flash is the text baseline and still the pinned build to use in production.
• Flash versus Pro covers the odd situation where the cheaper tier currently outscores the expensive one.
• Flash versus Kimi K3 and Flash versus GPT-5.6 handle the cross-vendor comparisons.
• Qwen 3.8 Max versus Flash is the closest open-weights fight, and Kimi K3 is the other one to watch.
• DeepSeek V3.2 is the previous generation, if you are still running it.
• Our V4-Flash review and alternatives roundup cover the wider picture.

And if you arrived here from a support-automation angle rather than a model-selection one, then the more useful reading sits further down the stack:

• Where a model actually sits: AI-powered ticketing and AI helpdesk agents.
• The retrieval question, which usually matters more than the model: RAG versus an LLM.
• What the queue work looks like: ticket deflection and ticket classification.
• Triage order and volume: ticket prioritisation, first-response automation and ticket reduction.
• The human-in-the-loop pattern: AI copilots for support.
• Terminology, if the vendor pitches blur together: agents versus chatbots.
• The two comparisons that decide budgets: cost per resolution and AI versus human agent cost, against a baseline of AI customer service cost.

The bottom line

DeepSeek shipped a model which reads images for essentially nothing, and along the way shipped a better text model than the one it forked from. Both of those things are real, and both of them are cheap.

The two things to weigh up are the ones the announcement does not lead with. Every image gets flattened down to roughly 800 by 800 before the model looks at it, so the vision here is a glance and not an inspection. And the build carries no date, so anything you measure this week is a measurement taken off a moving target.

For agent loops over screens and over code, that is a good trade at $0.22 in and $0.66 out. For a support queue where the screenshot is the ticket, test the resize before you plan around it, and keep in mind that reading the image was never the part which was going to go wrong.