DeepSeek V4 Flash 0731: Cheap, Fast, and Hard to Steer

DeepSeek pushed V4 Flash 0731 to Hugging Face on July 31 and moved their API onto it the same day. The repo passed 156,000 downloads within days. We moved one of our own internal tools onto the dated slug over the weekend, so some of what follows is from our own logs and some is from other people's, clearly marked either way.

Two things are worth your time here. The first is the price, which is low enough to change what a feature costs to run rather than just trimming a line on an invoice. The second is a steering problem that shows up in real work and in none of the published benchmarks, and it's the reason we didn't put this model everywhere.

What DeepSeek V4 Flash 0731 is, in numbers

• 284B total parameters with 13B active per token — a sparse mixture-of-experts model with one shared expert and 256 routed experts per layer, six of which fire on any given token.
• Hugging Face reports 304B on the model card. The extra weights are the DSpark speculative decoding module, which ships inside the same checkpoint rather than as a separate draft model.
• A 1M-token context window and up to 384K output tokens per request.
• MIT licence on both the repository and the weights, so self-hosting and commercial use are unrestricted.
• Three reasoning effort levels: low, high and max. There's no medium, and the gap between the default and max is larger than the names suggest.
• DeepSeek's own API charges $0.14 per million input tokens on a cache miss, $0.28 on output, and $0.0028 on a cache hit.
• Third-party providers serving the same weights went lower within days: $0.09 in, $0.18 out through OpenRouter.
• No vision. If your pipeline handles screenshots or scanned documents, you need a second model for that leg.

That last price point is the open-weight effect working exactly as advertised. Forty-eight hours after release, DeepSeek was being undercut on their own model by people renting GPUs, and nobody had to negotiate anything.

The 0731 update is post-training, not a new model

This matters if you were tracking the preview. The architecture and parameter count are unchanged; the gains come from re-post-training on more than 32T tokens. The published deltas against the preview are large:

• Terminal Bench 2.1: 61.8 to 82.7
• DeepSWE: 7.3 to 54.4
• Cybergym: 38.7 to 76.7
• Toolathlon-Verified: 49.7 to 70.3
• NL2Repo: 39.4 to 54.2

Read the DeepSWE row sceptically. A model does not become seven times better at software engineering through post-training alone. A score of 7.3 is what a capable model looks like when it's failing at the format rather than the task, so a large part of that jump is the preview's agent scaffolding being fixed rather than the model getting smarter. The Terminal Bench and Cybergym moves are the ones that read as genuine capability.

The important caveat is in DeepSeek's own footnotes. Those results were produced with the minimal mode of DeepSeek Harness, which they describe as "to be released." Nobody outside DeepSeek can reproduce the table yet, and as we'll get to, the harness turns out to matter unusually much for this model.

On the headline comparison: Flash now clears V4 Pro (Preview) on every agent benchmark DeepSeek published, on roughly a third of Pro's output price. Against Opus-4.8 it trails on most rows and comes close on Agents' Last Exam, 25.2 against 25.7. That's a reasonable summary of where it sits — not frontier, close enough that price decides.

The price is the story, with two asterisks

Claude Opus 5 output costs $25 per million tokens. This costs $0.28. When we compared Opus 5, Grok 4.5 and GPT-5.6 Sol last week, the interesting question was whether a 2x price cut made a feature affordable. Here the ratio is closer to ninety, and that isn't a discount so much as a different category of decision. One developer reported burning 110 million tokens in a day for $0.77 and made the observation that follows from it: once tokens are that cheap you stop optimising prompts and just retry when the model is wrong.

The cache-hit rate deserves attention separately. At $0.0028 per million, cached input is fifty times cheaper than a miss. If you're running retrieval or agents with a stable system prompt and a fixed tool schema, the prefix in front of every request is most of your input volume, and that prefix is nearly free.

Asterisk one: it's verbose. Artificial Analysis scores it around 50 on their Intelligence Index, third among open-weight models, but they also note it emitted 210M output tokens running that index against a 100M median. At max reasoning effort this model thinks at length, and your bill is dominated by output. The rate card is not the cost.

Asterisk two: peak pricing is coming. DeepSeek has published a peak/off-peak policy that doubles every billing item between 09:00–12:00 and 14:00–18:00 Beijing time, with the effective date still to be announced. Users in Europe and the US already report the endpoint slowing during Chinese business hours. If your workload is latency-sensitive and runs in those windows, budget for both the delay and the eventual 2x.

The problem the benchmarks don't measure

A developer running the weights locally at full precision posted that the model ignores rules files, skills and system prompts, that the 0731 release didn't fix what the preview did, and that first person, second person, English and Chinese all made no difference. The thread is worth reading in full because the replies disagree with each other in a useful way.

Several people running the same weights through vLLM on their own hardware, and others on the hosted API, report no such problem and describe it as their workhorse for long-horizon agent work. So this is not a simple "the model is bad" finding. But the complaint is specific and it recurs, and a second commenter in the same thread described having to write firmer skills for DeepSeek than for anything else they run — no hedging verbs, explicit ordered steps, and positive instructions instead of prohibitions.

There's a plausible architectural explanation, and it's worth understanding even though DeepSeek hasn't confirmed it. V4's attention is hybrid: Compressed Sparse Attention compresses the KV cache 4:1 along the sequence dimension, then a lightning indexer selects the top 512 compressed entries per query, with only the most recent tokens held at full resolution. Under that scheme a rules file sitting 40,000 tokens back is present, but as a compressed summary. The instruction survives. The exact wording may not. That is precisely the failure people describe: the model knows roughly what you wanted and does something adjacent.

The community fix circulating for vLLM is to raise the indexer's top-k with --hf-overrides '{"index_topk": 1024}', doubling the fine-detail budget. Treat it as an experiment rather than a solution.

Two other things were genuinely broken in the first week, and both are being fixed. DeepSeek shipped no Jinja chat template, providing a Python encoding folder instead, so the quantisers each wrote their own and they don't match — Unsloth says theirs was validated across 4,000 conversations against the official encoder. llama.cpp was still landing tool calls inside thinking blocks and a dedicated 0731 template days after launch. If you tried this locally on day one and it was bad, retry it now.

Simon Willison's test is the smallest useful demonstration of the effort dial. His SVG pelican came out malformed at the default reasoning level and much better at reasoning_effort high. Whatever you benchmarked at default, benchmark again at max before you conclude anything.

A model that ignores your instructions isn't cheap at any price. It's an unpredictable per-task cost, paid in the reviewer's time instead of on the API bill.

How to actually prompt it

From the reports above plus our own use, the practices that make a difference are consistent and slightly unfashionable:

• Write absolute instructions. "Must", "always", "only" hold their weight through compression in a way that "if appropriate" and "a reasonable amount" do not.
• State the desired behaviour instead of the forbidden one. A stack of "do not" rules gives the model no target, and this model in particular drifts toward whatever the nearest plausible action is.
• Give ordered, numbered steps for anything workflow-shaped, and cover every allowed output in your examples. Partial examples get treated as the full specification.
• Replace vague scope words with numbers. "Nearby", "briefly" and "a short summary" are interpreted differently on every call.
• Keep the prompt short. Padding a system prompt with background the model doesn't need is expensive here specifically, because it pushes your real instructions further from the dense window.
• Run max reasoning effort for agentic work, with temperature 1.0 and top_p 0.95, which is what DeepSeek recommends on the model card.
• Read the reasoning trace when something goes wrong. DeepSeek exposes the full trace, and it usually shows the exact point where an instruction got dropped or reinterpreted.

That last one is a real advantage over the closed models. When Opus or GPT silently does the wrong thing, you're guessing. Here you can see it decide.

What it takes to run yourself

The MIT licence makes self-hosting a genuine option rather than a talking point, and 13B active parameters means the compute per token is modest even though the weights aren't. Unsloth's GGUF ladder runs from 162GB at 8-bit down to about 82GB at 1-bit, with the 3-bit builds at 103–129GB the practical floor for real work. Around 110GB of combined RAM and VRAM gets you there, which is a 128GB Mac or a small cluster of DGX Sparks rather than a spare GPU.

DSpark is what makes the self-hosted version fast. It's a speculative decoding scheme with a semi-autoregressive block drafter and a per-request verify length driven by the drafter's own confidence, and because acceptance uses rejection sampling that preserves the target distribution, the speedup is free of quality loss. DeepSeek reports 60–85% faster per-user generation against their MTP-1 baseline at matched throughput. Turning it on is one flag in vLLM (--speculative-config '{"method":"dspark",...}') or --speculative-algorithm DSPARK in SGLang, with no separate draft model path because the draft weights are in the same checkpoint.

One field report is worth more than the documentation here. Someone running 1M context across two DGX Sparks with an NVFP4 KV cache found vLLM's DSpark loader was renaming one shared-expert tensor and silently skipping two others, leaving twelve tensors uninitialised. The server started. Generation worked. Draft acceptance was 25.7%. After mapping the weights correctly, acceptance went to 60.2% and mean throughput from 32.7 to 55.4 tokens per second.

The lesson generalises past this bug: a speculative decoding setup will happily run at half speed without erroring, so monitor draft acceptance rather than tokens per second, and benchmark with streaming off so you aren't measuring steps and calling them tokens. The same forum has people running UD-IQ2_M through llama-server at 256K context without trouble, so the GGUF path works if you'd rather not deal with vLLM at all.

Whether it's worth it is a separate question. Two DGX Sparks are about $9,400 before power and your time. At $0.28 per million output tokens, that's a lot of API calls. The cases where self-hosting wins are the ones where data can't leave, where you need a version pinned indefinitely, or where volume is genuinely enormous — not where you're trying to save money on a moderate workload.

Pin the version, because the endpoint moved under people

This is the most practical thing in this post and it's had almost no coverage. DeepSeek's API model name is deepseek-v4-flash. There is no dated snapshot on their endpoint — they repointed the same name from the preview to 0731 without renaming it. Their own published table moved DeepSWE from 7.3 to 54.4 across that switch.

So any evaluation you ran against that endpoint before July 31 is not a baseline you can compare against, and "works on the API, broken locally" isn't automatically a local bug, because the hosted side moved too. If the model has shell or repository access in your system, re-run your evals rather than assuming continuity.

OpenRouter does expose the dated slug, deepseek/deepseek-v4-flash-0731. Use it. If you self-host, pin the Hugging Face revision hash, not the branch.

Where we're using it, and where we're not

It has been the default model in one of our own internal tools since the weekend — a retrieval-grounded assistant answering questions over a corpus of public web pages. Model choice there is a config value rather than an SDK dependency, so a swap is an UPDATE statement. We moved that default from the undated deepseek/deepseek-v4-flash alias to the dated 0731 slug for exactly the pinning reason above: we would rather know which weights answered a given question.

That shape of workload suits a cheap model. The source material is already public, the system prompt is short and fixed, retrieval does most of the work, and the hard requirement is refusal — the assistant must never invent a price, a timeline or a person's name. What makes that safe to rely on is an adversarial test suite that has to pass before anything ships. A model that's occasionally loose with instruction wording is survivable when the guardrail is a test rather than a sentence in the prompt, and that's true of every cheap model, not this one specifically.

We're less relaxed elsewhere. On a consumer health app we're building, the questions we're working through first are about what may appear in a prompt at all, where inference runs, and what's logged — not benchmark scores. That ordering isn't specific to DeepSeek. It applies to every hosted model we consider, and it's the reason our client systems keep model choice behind a config value: where the weights run and who can see the prompt is a decision to make with the client, in writing, before anyone argues about price per token. Open weights genuinely help here, because the same model can run on your hardware or through a provider in your jurisdiction.

Where it fits

• Good fit: high-volume agentic work where cost per call decides whether the feature ships at all, long-document processing that needs the 1M window, and anything with a large stable cached prefix.
• Good fit: deployments where the licence matters more than the last few benchmark points, since MIT weights remove the vendor from your roadmap.
• Poor fit: workflows built on a long rules or skills file that has to be followed literally. Fix the prompts first, then re-test, and keep a fallback.
• Poor fit: anything involving images, and any single-model stack with no escalation path.

The shape most of our systems end up in is a cheap default with a quality gate and an escalation to something stronger when the gate fails. V4 Flash 0731 is currently the best candidate we've seen for the default slot. It isn't a candidate for the escalation.

How we'd test it on your workload

Same method as every release. Take one real task from a live project, run it against your incumbent and against Flash with the same harness at max reasoning effort, and count three things: cost per completed task, how often a person had to step in, and how many failures were recoverable without a human. Cost per token is an input to that, not an answer.

If you're weighing an AI feature and want to know whether this pricing changes what's affordable — or whether it should touch your data at all — that's a scoping conversation we're glad to have. Send us the constraint you're stuck on and you'll get a written scope and a fixed quote before any commitment.