DeepSeek V4 Flash review: one model, two personalities

What you are actually buying

The whole product is one row on a docs page. Two models, a spec table, three prices. Refreshingly honest, compared to most launch pages.

The build behind the alias is DeepSeek-V4-Flash-0731, which went public on 2026-07-31 as a re-post-train of the April release. Architecturally it is a sparse mixture of experts: 284B total parameters, 13B of them active on any given token. The weights are MIT-licensed at roughly 167GB. If you know the previous generation from DeepSeek V3.2, this is a different animal on agentic work.

Every figure there comes from DeepSeek's own price card. Two things on it are easy to skim past and worth pausing on. Thinking mode is the default on both tiers, and reasoning tokens bill at the output rate. And Flash, not Pro, is the only model the Responses API supports, which is unusual: the budget tier gets the newer surface.

The review problem: you are grading a setting

Here is the finding that reframed this whole piece for me. Artificial Analysis does not list one DeepSeek V4 Flash. It lists two, because the same weights behave like two different products depending on reasoning_effort.

Run it with thinking off and you get an Intelligence Index of 29, at a median 107 output tokens per second, 1.18s to the first chunk and 5.86s end to end. Now run it at max effort. The index goes to 50, and Artificial Analysis publishes no speed numbers at all for that variant. Output tokens per second, blank. Time to first token, blank. Total response time, blank, with the summary panel admitting "Unknown out of 4 units for Speed".

So the model topping the value charts is a model nobody has published a latency figure for. Not a scandal, just a measurement gap. It does mean that a plan built on "cheap and fast" is resting on two numbers which were never measured in the same run.

Two smaller quirks compound it. DeepSeek's own effort-mapping table serves an xhigh request on Flash at high, so a knob you thought you turned does nothing. And on Pro, a low request is served at high, meaning there is no cheap Pro run at all, which is a big part of why the Flash and Pro comparison goes the way it does.

If you are wiring this up yourself, the traps are all on the quiet side of the API, and I wrote them up separately in how to use the API. The short version is that almost every misconfiguration returns HTTP 200 and simply ignores you.

The two scoreboards disagree, and both are right

This is where most reviews pick the flattering number and move on. The honest position is that the automated index and the human vote board tell different stories about the same model.

On Artificial Analysis, the max-effort Flash run scores 50 and sits 21st out of 260 model rows, third of 101 in its own size class, and first of 101 on cache-hit price. Cost per task is $0.03, and running the entire index cost $72.02.

On the LMArena text board, the same model is 79th, with an Elo of 1436 plus or minus 4, on 48,667 votes. The -high-preview row is barely different at 1438. And V4 Pro, the model Flash beats on the automated index, sits above it here at 1458. Human preference and benchmark aggregate genuinely part ways on this one.

One bright spot in the human data, with a caveat attached: on the WebDev board, deepseek-v4-flash-high is 8th at 1577. That row carries LMArena's Preliminary tag on 1,319 votes with a plus-or-minus-18 interval, so it is a promising signal rather than a settled result.

My read on it: the automated index measures a maximally-configured run on tasks that reward tool use, while the arena measures how a reply feels to a person sitting in a chat box. Flash is built for the first thing. So buy it for the first thing.

What it is properly good at

The receipts here are the most convincing part of the whole reaction, because they are invoices rather than opinions. This is where the agentic framing earns its keep.

"I use deepseek for a lot of my personal day-to-day agent needs, and I will simply put this here and let this speak for itself, last 30 days:

Cost: $4.55USD

API requests: 3,467

Tokens: 323,183,886 And as an engineer who leads a small team, I have very high standards for quality, and these carry across to my personal projects where I use deepseek. It has not disappointed at all for coding or review tasks. For everything else, use another model."

lionkor, Hacker News

Note the last line, because it is the most useful sentence in the thread. The heaviest users are not claiming a general-purpose frontier model, they are claiming a very good, very cheap workhorse for a named set of jobs. Someone promptly turned up with a bigger bill and the same conclusion, at 2.1 billion tokens over 12 days for $19.27.

Agent harness users report the same shape:

"Essentially I'm running everything on flash now inside pi. With the correct set of MCP servers, context reducer tooling and skills it can implement any task I throw at it. Some sessions take 30+ turns, but it's fast and cheap; all this in an hour, with ~$0.5 cost. [...] I haven't used our slow opus subscription for weeks."

kmarc, Hacker News

The most interesting explanation of why the cheap tier wins on this class of work came from a team that had to go and figure it out:

"DeepSeek V4 Flash is the most cost effective model we've tested. We had to really understand why it outperformed DeepSeek V4 Pro (although even on unreliable model cards, Flash was very close to Pro). Pro is slower and smarter in one-shot reasoning problems, but less effective with tools and therefore less performant in long horizon agentic tasks (especially with custom tools it was not trained on)."

gertlabs, Hacker News

That maps neatly onto the summarise-and-review use case too. One user reported four dollars across two months on reviewing and summarising work, with "no dramatic drop in performance against other US models". For batch jobs that were previously too expensive to bother automating, the price genuinely changes what is worth building, which is the same argument I make about AI support costs in a different domain.

Should you use it for this job?

Where it falls down

A review that only lists strengths is a press release. The complaints below are specific and they repeat across threads, and a couple of them are the whole reason I would not put this model in front of a customer.

It hallucinates, and the published number is ugly. Artificial Analysis puts the AA-Omniscience hallucination rate at 84%, and its own note is that the generational improvement came from "fewer hallucinations, rather than higher accuracy". That is a 12-point improvement on a number that started worse. Users describe the same thing without the metric:

"DeepSeek V4 hallucinates like crazy and often forgets explicitly mentioned parts of the context. I guess compressing tokens and cherry-picking attention comes at a cost."

storus, Hacker News

To be fair, the heaviest user in the thread calibrated it against peers rather than treating it as disqualifying, saying it hallucinates "about the same as Codex models and all other LLMs" and that he reviews everything it writes and has other models cross-check the work. That is the right posture, and it is also a real cost that never shows up on the price card.

Long-horizon work in a big codebase is the soft spot, which is awkward given the vendor's agentic pitch.

"If you believe the benchmarks Deepseek v4 is pretty shitty at long running work in large codebases, but really really good at self contained algorithmic/math reasoning - which is basically ideal for a compiler for a language with a relatively complex type system. And with its cache pricing it's very cheap."

p1necone, Hacker News

It is a wordy model, and the words are billed. Artificial Analysis flags it explicitly on verbosity.

It burned 210M output tokens to complete the index against a class median of 100M, described on the model page as "very verbose in comparison". The whole run still only cost $72.02, which is the point, but 2.1 times the median output volume is the mechanism that quietly separates the sticker price from your invoice. I unpack that gap properly in the pricing breakdown.

Capabilities that are simply absent. There is no documented image input: no vision row on the price card, no vision encoder in the config, and DeepSeek's multimodal work lives in separate model lines. Teams route around it, as one user described, by keeping a second model on hand for vision.

Worth correcting a claim that has spread with that one, though. The same report says DeepSeek "doesn't support web search", and that is only true on the older chat-completions path. The Flash-only Responses API does ship a server-side web_search built-in tool, alongside apply_patch. File search, code interpreter, computer use and MCP tool types are all ignored there, so the capability set is narrow, but web search is on the list.

One real billing blowout is on record, and it is worth knowing about before you point an agent at this:

"I bought it through OpenRouter and used it with Pi agent. The model was good, but there appeared to be a pricing glitch or something, because it burned through $50 in under an hour on pretty trivial stuff. Pi agent claimed it only used like $1. OpenRouter claimed differently and said I used all $50."

onlyrealcuzzo, Hacker News

DeepSeek also publishes no requests-per-minute or tokens-per-minute limit at all, only a concurrency ceiling that is account-level rather than key-level. Combined with a prepaid balance that can return a 402 in the middle of a run, that is a monitoring problem more than a pricing one, and a good argument for a proper tracking setup.

A versioning gripe that will bite anyone citing benchmarks. One user put it well: on DeepSeek it is now just deepseek-v4-flash, while OpenRouter calls it deepseek/deepseek-v4-flash-0731, so when a benchmark says "DeepSeek V4 Flash" you cannot always tell which build ran. Pin the dated name when you write anything down.

Running the weights yourself

The MIT licence is doing real work here, and the local reports are the best-documented part of the reaction. This is genuinely a foundation model you can host, not a hosted-only LLM.

One local runner captured why people bother, and it is not the arithmetic:

"2 sparks currently run this model at 60 t/s single session, up to just over 100 t/s aggregate with concurrency of 4. Going local has as opened up a world of use-cases I never would have entertained the idea of on metered/cloud usage. Privacy is a large part of it but, I also no longer think twice about whether to send a prompt or not based on the psychology of it costing money."

wolttam, Hacker News

On pure cost, the threads are close to unanimous the other way. One estimate put a dual-Spark box at eight to nine thousand dollars and concluded it "makes little to no sense as long as API prices are what they are. Except for maybe privacy reasons." Another user did the electricity maths and found hitting DeepSeek's cache rate cheaper than running a 36B model at home. So: host it for control and privacy, not to save money.

My verdict, by job

Against the field, three models are worth putting next to it. At roughly the same intelligence, GPT-5.6 Luna runs two to three times the price and is the one people pair with Flash for vision, worked through in Flash vs GPT-5.6. If accuracy matters more than price, Kimi K3 hallucinates far less and costs far more.

For the multimodal option in the same open-weights bracket, Qwen 3.8 Max is the one to read next. There are hands-on takes on each of those in the Qwen review and the Kimi review.

Two further reference points if you are drawing a price axis. Claude Opus 5 pricing marks the frontier end of it. Mistral alternatives covers the European open-weight family, and the GPT-5.6 review has the verdict on the model most teams are actually switching from.

Should it ever answer a customer?

This is the section I actually care about, because it is my job. And the honest answer is that the model is the wrong place to be looking.

Start with where the tokens go. DeepSeek's paid Open Platform terms are silent on training use, which is not the same as permissive and not the same as safe. The consumer terms carry an explicit clause at section 4.3 with an "Improve the model for everyone" opt-out; the API document's equivalent section stops before it. There is no published data-processing agreement or zero-retention option either way, and the privacy policy states data is processed and stored in the People's Republic of China under PRC law. Zero-retention hosts exist, and one user reported them at three to five times the first-party price, which erases most of the discount.

If any of that is new to you, the Slack policy episode is the precedent readers already lived through. SOC 2 and GDPR is the checklist to run before you connect anything customer-facing.

Then there is the 84% figure. Every support team I talk to hears a number like that and asks the wrong question, which is "how accurate is your model". Here is a customer of ours putting the right question much better than I could. Their bot had been confidently confirming that the company supported car models that were not in their database, because a knowledge-base line said they supported all models. The model was fine. The grounding was not.

The team's summary of getting it right was "trial and error in the beginning."

A Danish B2B vehicle-telematics support team on Zendesk, doing around 200 tickets a month and scaling toward 2,000 plus, who worried the AI would over-confidently confirm unsupported car models.

That is the whole lesson. Hallucination in support is usually a grounding and permissions problem wearing a model costume, and every real fix lives above the model rather than inside it.

The stack that makes a shaky model survivable is not exotic. Retrieval over sources you have actually verified. Guardrails on what it is allowed to assert. A confidence score with a threshold somebody chose on purpose, and a human on everything below it.

Our own worst observed failure, watched in production, was an AI agent narrating "executing Zendesk searches" for about ten turns without ever hitting the API, then reporting files saved that did not exist. Nothing kills trust in a teammate faster than lying about what it did, and no benchmark score would have caught it. What catches it is containment measurement after the fact and human review before it.

So if you are evaluating raw models for a support queue, the practical order is roughly this. Test adversarially before you trust anything. Build an evaluation habit instead of a launch date. Set confidence thresholds deliberately.

Then read hallucination prevention before you connect a single ticket, and ask yourself the build versus buy question honestly, because assembling that whole stack yourself is the actual project. The model is the cheap part.

Try eesel

If you got here from a spreadsheet comparing per-token rates for a support use case, the thing I would tell you over coffee is that the token price was never the hard part. Wiring a model to your helpdesk, grounding it in your real macros and past tickets, and knowing what it will say before a customer sees it is the hard part, and that is the product.

That is what eesel is: an AI support agent that plugs into Zendesk or your existing helpdesk, grounds every reply in your verified knowledge, and lets you run simulations on your own historical tickets so you can see exactly where it would have been wrong before you go live. You watch the task volume, the triggers, and every approval or rejection per tool, so "is it hallucinating" becomes a number you can look at instead of a worry.

Pricing is per resolved conversation rather than per seat, which means a gradual rollout is a real option: route 200 of your 1,000 monthly tickets and pay for 200. There is $50 of free usage to start, no card required, and the pricing page has the numbers. Run a simulation on last month's tickets and you will know within an hour whether any of this is worth your time. That is a much better use of an afternoon than benchmarking a knob.